There's real time GTFS and static GTFS files. The static files have the current schedule, routes, bus stops, etc contained in files. The files can be downloaded, but each transit agency has its own location.
GO-Sync, from University of Southern Florida synchronizes some static GTFS data with openstreetmamp, route and stop info. This is info which is useful in openstreetmap since it is a natural part of a map. https://github.com/CUTR-at-USF/gtfs-osm-sync While static GTFS files contain schedule information GO-Sync does not handle this information. OSM might include information which GTFS does not include, such as the existence of a bench at a stop. The schedule might have frequency, but it often has the expected times at each bus stop for a given run. That's a lot of information, and would take some work to match up to OSM. It isn't impossible, but it is more information than in the proposal. There might be advantages to having this information in OSM. It's nice to look up the expected schedule even when you don't have a network connection. And you might not have a connection when you're underground waiting for the next bus. Real time GTFS has current, more or less real time, information on the location of the bus, including expected arrival time. You could find out about the 10 minute delay in your bus. This couldn't be in the static OSM map, though the location of the information could in OSM. On 11/8/18 10:20 AM, Mike N wrote: > On 11/8/2018 12:06 PM, Leif Rasmussen wrote: >> >> I think that creating a new GTFS server would be better than using >> transit land or transitfeeds.com <http://transitfeeds.com>, because >> OSM would have full control over what happened to the servers and >> which licencing was used. >> >> Does anyone with experience in GTFS know how an integration like that >> could work? Also, is what I am imagining even possible? > > > I would tend to think that using the GTFS standard would be the best > approach. The only "duplication of effort" is that there is an > optional? inclusion of the route geometries in the GTFS feed. > > In the one case I am familiar with - OpenTripPlanner, the local > network build process could always download the GTFS from any source as > part of the build process. The only advantage I see for adding another > feed source is to add the capability of publishing a GTFS from other > than an official source. This allows a public GTFS feed for a city > which is otherwise too small to maintain an electronic schedule. > > > _______________________________________________ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
