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) | [email protected]
<mailto:[email protected]> | 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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________
Talk-transit mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit
