GO-Sync - a GTFS and OpenStreetMap data synchronization tool

[Sean Barbeau]

Hi transit developers,
At USF we've been working on an open-source tool, GO-Sync (http://
code.google.com/p/gtfs-osm-sync/), that can synchronize General
Transit Feed Specification (GTFS) datasets with OpenStreetMap (OSM).
The goal of GO-Sync is to allow agencies to quickly upload their GTFS
datasets to help fill out multimodal OpenStreetMap data (vs. requiring
OSM users, who often aren't coordinating with agencies, spend time
manually coding these stops), and also allow transit agencies to pull
down crowd-sourced modifications (e.g., corrections in stop location,
additions of amenities, etc.) by OSM users for integration back into
the transit agency's bus stop inventory (and therefore into their GTFS
dataset for OpenTripPlanner and other transit apps).

We hope that GO-Sync will allow OSM users to focus on improving
existing GTFS bus stop inventories, rather than starting from
scratch. Incorrect bus stop positions in GTFS datasets have been one
of the biggest challenges we've seen in the testing of our Travel
Assistance Device mobile app for GPS-enabled mobile phones (http://
www.locationaware.usf.edu/ongoing-research/ travel-assistance-
device/), which alerts travelers to exit the bus at the proper time.
GO-Sync is our attempt to help address this problem on a systematic
basis, and we hope that this tool is a starting point that the
community can build on.

We would like your feedback on GO-Sync, although please understand
that the tool is a work in progress. We also understand that the
ultimate success of this tool from a transit developer's perspective
will require
willingness and effort (although hopefully not much) at transit
agencies to integrate data improvements back into their inventories,
so we would also welcome advice as to how to overcome this obstacle.
We've gotten feedback from one of our local transit agencies here
(HART) that has a GIS analyst, but given that agencies come in all
shapes and sizes having feedback from others would be good.

If others would like to contribute code/effort/wisdom to the project,
please let us know, as we would welcome collaboration. We strongly
suggest reading the instructions on the GO-Sync Google Code site
before performing any bulk uploads of data into OSM, and please
remember that you must have the permission of owner of the data (e.g.,
transit agency) before uploading that data into OSM. And, as always,
please respect other users work/data in OSM.

GO-Sync on Google Code:
http://code.google.com/p/gtfs-osm-sync/

Thanks,

Sean J. Barbeau, M.S. Comp.Sci.
Research Associate
Center for Urban Transportation Research
University of South Florida

[Joe Hughes]

Very cool, Sean! I'd also recommend posting this to the OSM talk-
transit list:
http://lists.openstreetmap.org/listinfo/talk-transit

Cheers,
Joe

[Peter Miller]

On 31 January 2011 17:52, Joe Hughes <joe.hug...@gmail.com> wrote:

Very cool, Sean!  I'd also recommend posting this to the OSM talk-
transit list:
http://lists.openstreetmap.org/listinfo/talk-transit

+1

Also... it would be useful if there was a way to deal with multiple instances of the same bus stop appearing in different gtfs files. For example on the junction of Market Street and Castro and 17th St. There are a bunch of stop duplicates there and it would be great to be able to alias them across based on their name/location. Alternatively one would build the alias into the OSM feature for the correct stop location, as in 'this is also detail for the stop called 'xxx' and lat/long'.


Peter
 

 

Cheers,
Joe

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To post to this group, send email to transit-d...@googlegroups.com.
To unsubscribe from this group, send email to transit-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/transit-developers?hl=en.

[ktran9]

Hi Peter,

I'm one of the member of the CUTR crew working on this project. I
agree with you that we need a way to deal with multiple operators on
the same stops. Two obstacles that need to overcome are:

1) The discrepancies of different GTFS data. Well, this is the main
goal of our project. Many people believe that transit agency must have
its up-to-date dataset, especially its bus stop locations. That's not
totally true and we were hoping to have a cheap, easy solution through
OSM. Suppose we have all the 'accurate' bus stop locations, meaning
two bus stops of two different agencies overlap each other (or in an
acceptable range <5m). We still have another problem.

2) Difficulties of representing the data. Specifically, some OSM users
tag stops with multiple operators as 2 tags [operator1=ABC] and
[operator2=XYZ] while others prefer tagging with only one tag with a
delimiter [operator=ABC;XYZ]. The problem is even worse when
considering route and gtfs_id for multiple operators.

These problems are not only for OSM particularly but transit agencies
need to involve in the process of solving these problems since they're
the ones who're mainly responsible for the bus stops/data

On Feb 1, 11:44 am, Peter Miller <peter.mil...@itoworld.com> wrote:

> > transit-develop...@googlegroups.com<transit-developers%2Bunsubs cr...@googlegroups.com>
> > .

[Craig Nelson]

Hi

We (Steer Davies Gleave) are working on similar OSM projects to crowd source cycling information and then present on printed and electronic maps. Your Nepal project sounds very interesting and something that could be very useful for other developing countries - could you provide us with more information? I'm currently writing an article on crowd sourced transit info and this would be a great case study.

Best

Craig

[Sean Barbeau]

The GO-Sync tool has the code to go both ways (OSM->GTFS and GTFS->OSM), although the current UI is built around the business process of an agency producing a GTFS feed and then using that as a starting point for the sync process.

So, I'd suggest checking out the source code for the tool (http://code.google.com/p/gtfs-osm-sync/), as I believe it could be modified to give you the OSM->GTFS one-way tool that you're looking for without too much effort.

I think your biggest challenge will be the time/schedule portion of GTFS.  OSM really isn't built to hold this type of information, so you might need to have a separate process to establish the time/schedule data.

Sean