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. Michael <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging