[Talk-transit] GTFS and the like

[Patrick Brosi | geOps]

Sean, it would be interesting to know whether GO-Sync's processing 
includes the GTFS route shapes (the exact vehicle paths stored in 
shapes.txt) in any way. For example: if the GTFS feed only covers the 
location / attributes of stations and is missing shapes.txt information, 
does GO-Sync try to extract these shapes from OSM data? If so, what 
approach do you use? How are existing shapes compared to data already 
existent in OSM?

Many public transport companies have very good data regarding the 
position of their stops, but lack the exact paths vehicles take between 
succeeding stations. In my opinion, providing not only the possibility 
to extract these shapes from existing OSM data but also the tools to 
edit them via OSM would dramatically increase the geospatial quality of 
many GTFS feeds.

I just browsed GO-Sync's paper and couldn't find anything relating to 
this problem. Are there any future plans to include the functionality 
described above?

Thank you!

Best regards

Patrick Brosi

-- 
geOps e.K.
--------------------------------
Commercial Registry A 702785, Freiburg
Kaiser-Joseph-Strasse 263
D-79098 Freiburg
--------------------------------
direct  +49 (0)761 458925 10
free    +800 436 436 436
--------------------------------
web www.geops.de
rss www.geops.de/blog/feed
follow www.twitter.com/geops
--------------------------------


On 03/04/14 16:47, Barbeau, Sean wrote:
> As part of a research project
> <http://www.locationaware.usf.edu/ongoing-research/projects/open-transit-data/>
> in 2011, we developed GO-Sync an open-source tool to synchronize bus
> stop data between a GTFS dataset and OSM:
>
> https://code.google.com/p/gtfs-osm-sync/
>
> The main idea was to help the transit agency improve the accuracy of bus
> stop geocoding, and amenity catalog, by crowdsourcing this information.
> So, the tool has the ability to diff a GTFS dataset and OSM, and produce
> a new GTFS dataset with the merged attributes.  Please feel free to try
> it out, and additional contributions would be welcome.
>
> We determined that timetable information wasn’t really well-suited for
> storage in OSM directly due to OSM’s lack of relational data support.
> Additionally, the information changes fairly frequently (usually at
> least quarterly), which means the data would need to be updated
> frequently.  If you also try attaching transit service to roads in OSM,
> this would mean programmatically updating OSM relations, which seemed
> far too error prone.
>
> GTFS is a widely-accepted format for transit data at this point, and in
> our opinion relying directly on the GTFS dataset produced by the agency
> for timetable and other transit information is the best practice.  This
> also implies that any improvements to the information need to be fed
> back to the agency for integration into the GTFS dataset, hence the
> creation of the GO-Sync tool.
>
> Sean
>
> *Sean J. Barbeau, Ph.D.*
>
> Principal Mobile Software Architect for R&D
>
> Center for Urban Transportation Research
>
> University of South Florida
>
> 4202 E. Fowler Avenue, CUT100 | Tampa, FL 33620-5375
>
> 813.974.7208 | 813.974.5168 (fax) | barbeau at cutr.usf.edu
> <mailto:barbeau at cutr.usf.edu> | QR Code
> <http://chart.apis.google.com/chart?cht=qr&chs=350x350&chld=L&choe=UTF-8&chl=MECARD%3AN%3ASean+J.+Barbeau+Ph.D.%3BORG%3AUniversity+of+South+Florida%3BTEL%3A8139747208%3BURL%3Ahttp%5C%3A%2F%2Fwww.locationaware.usf.edu%2F%3BEMAIL%3Abarbeau%40cutr.usf.edu%3BNOTE%3APrincipal+Mobile+Software+Architect+for+R%26D%3B%3B>
>
> http://www.locationaware.usf.edu/
>
> *Subscribe
> <http://lists.cutr.usf.edu/read/all_forums/subscribe?name=locationaware>
> to USF's Location-Aware Information Systems listserve to be notified by
> email of new research reports, industry news, etc. and to discuss
> location-aware technology issues and experiences.*
>
>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>