[Tagging] Public Transport Timetables Proposal RFC

Michael Patrick geodesy99 at gmail.com
Wed Oct 31 22:45:01 UTC 2018

 Globally, US DOT, the World Bank, ASFAIK all EU countries, have settled on
GTFS, or eventually will on some future version.

So there are two cases:
1. Transit Services that use GTFS
2. Transit Services that do not use GTFS

For Case 1, the General Transit Feed Specification Reference declares that
the geographical elements ( which correspond to OSM geometry types ) are to
be declared and maintained on the GTFS side, and since OSM doesn't have any
sort of permanent / persistent element ID to bind that fact, the robust
technical solution especially for complex transit system would be a
automated CRUD
<https://en.wikipedia.org/wiki/Create,_read,_update_and_delete> refresh of
the geometry. You're still at the mercy of OSM side latency to some extent,
but doable.

OSM would be useful in Case 2, to initially provide the geometries to a
GTFS feed not maintained by an agency - it is simply a set of .txt files,
this has been done for small local routes on GitHub. Then the technical
solution above applies. Ongoing, maintain your GTFS feed to whatever level
you feel suffices. And you could publish your feed to the registry, to
everyone's benefit.

( ... this is overly simplistic, and invokes the ball of snakes of opinions
and philosophies on automated imports, so your pretty much back to some
sort of parallel OSM implementation with the main OSM as essentially a
background layer. ).

BTW, Google Transit ( or any of the others ) do not store the data, they
rely of the GTFS feed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181031/b140ec6c/attachment.html>

More information about the Tagging mailing list