Hi Aenet, My first general question is: what are you trying to achieve, what are your goals in adding this bus to OSM?
Support for transit routing using data purely from OSM is very limited. To my knowledge, currently among mainstream/worldwide apps only OsmAnd does so. To my knowledge; it does not look at opening_hours at all. In practice, basically all general-purpose transit apps use GTFS feeds based on a list which they compile more or less manually based on catalog sites like https://mobilitydatabase.org/ (previously transitfeeds.com). I have made some PTv2 relations with branches/variants, including some best-effort information for interval=* and opening_hours=*, but I don't try to get it perfect - since I'm not encoding the entire schedule, there's no point of to-the-minute accuracy. (For an example of level of accuracy I go for, see members of https://osm.org/relation/72291 <https://www.openstreetmap.org/relation/72291> ). In your specific situation I personally would tag the variant bus as opening_hours="05:25-08:37, 15:46-17:40" and the main route as opening_hours="08:10-23:35". This does cause overlap, but I would say that it gives the main gist of the idea without trying to encode every single detail. To me knowledge, fully encoding an entire bus schedule in OSM has never been attempted for any route longer than two stops, so we anyway decide how much detail to include. Another thing that could potentially be useful is adding GTFS information to stops (gtfs:stop_id:*) and/or route relations (likely gtfs:trip_id:sample:*) - see https://wiki.openstreetmap.org/wiki/GTFS#Linking_to_a_GTFS_object . This would let apps see a stop in OSM and be able to pull up actual schedules based on data from the transit agency. I will note that as of now I am unaware of any end-user apps actually implementing this, and it appears to mostly be used as a QA tool: comparing GTFS data with OSM data and flagging any discrepancies for something that might need updating in OSM. However, it _is_ a fairly newly defined feature, so perhaps use by apps will happen one day. Regarding licensing: the majority of GTFS feeds I have seen are under non-free licenses. Linking to non-free content is allowed, both in wiki and in OSM itself. Including _facts_ like bus stop names and IDs assigned by a transit agency is generally allowed. Things get a bit more complicated if an entire dataset was to be added to OSM (e.g. taking bus stops from a GTFS feed and adding all of them to OSM in one go), for one thing because of possible database rights (less so for USA sources), for another because that's considered an "import" in OSM and has to be announced and discussed. If no key-less GTFS download link is available, I would duplicate how Austrian feeds are listed in https://wiki.openstreetmap.org/wiki/List_of_GTFS_feeds . Cheers, --Jarek On Mon, Dec 9, 2024, at 21:48, Aenet Anthony wrote: > Should I just include it even though there is no canonical link (because any > user's link with differ depending on their key [one such URL is listed at the > bottom])? I found one listed here > <https://www.transit.land/feeds/f-dpeg-capitalareatransportationauthority> > but that seems to be one that someone got a licensed key for and shared > (which I'm not sure is even allowed under the license > <https://www.cata.org/Portals/0/CATAGTFSLicenseAgreement20150323.pdf> (3), > along with (an)other apparent violation(s) of the license by not including > "CATA information provided on this site is subject to change..." in close > proximity to the data links (6)), so I don't necessarily think it would be > appropriate to use it for OSM. After all, the other entries on List of GTFS > feeds <https://wiki.openstreetmap.org/wiki/List_of_GTFS_feeds> all seem to > either have a freely available license and link or otherwise have specific > permission from the transit agency to include it. > > I could just add GTFS tags without adding an entry to the list of GTFS feeds > on the wiki, but I'm not sure if that's kosher. > > I also can't really tell how I'm supposed to use OpenTripPlanner. > > Aenet > > Example URL: > http://developers.cata.org/gtfsdownload.ashx?key=5b4690ed-0a69-4320-897b-7d92def4b96f&data=base > > On Mon, Dec 9, 2024 at 3:50 PM Shaun McDonald <[email protected]> > wrote: >> I would directly include the GTFS data in OpenStreetMap. Best to use it as a >> combined dataset in a journey planner such as OpenTripPlanner. >> >> Shaun >> >> >> On 9 December 2024 20:38:51 GMT, Aenet Anthony <[email protected]> >> wrote: >>> Thanks Shaun. >>> >>> I just checked and CATA (Lansing, MI) does have a GTFS feed. It’s available >>> <https://www.cata.org/About-Contact/Doing-Business-with-CATA/Developer-Resources> >>> with a not fully open license >>> <https://www.cata.org/Portals/0/CATAGTFSLicenseAgreement20150323.pdf> that >>> allows credentials to access the GTFS feed. I’m not sure whether that would >>> be appropriate to use for OSM. I’m wondering what advice would be for use >>> of that. I’ll request a license and ask CATA what their opinion is. >>> >>> >>> Aenet >>> >>> p.s. Sorry about the ugly links, I couldn’t get them to work properly on >>> mobile. >>> >>> On Mon, Dec 9, 2024 at 2:45 PM Shaun McDonald <[email protected]> >>> wrote: >>>> I'd use GTFS to define the schedule as that is far better suited to this, >>>> especially considering that the timetable can frequently change. >>>> >>>> Having just the shape in OpenStreetMap is probably good enough. >>>> >>>> >>>> Shaun >>>> >>>> >>>> On 9 December 2024 18:20:33 GMT, Aenet Anthony <[email protected]> >>>> wrote: >>>>> Hi all, >>>>> >>>>> I started using OSM fairly recently and one thing I've been working on in >>>>> my city is improving the route relations for public transit (bus only in >>>>> my city). This has included cleaning the ways included in the routes >>>>> (such as including the entirety of roundabouts instead of just the >>>>> portion used, having many gaps, roads out of order, or roads included >>>>> multiple times when they should not be) as well as creating new relations >>>>> when both outbound and inbound are mapped together or for route variants. >>>>> >>>>> Now on the topic of route variants, I'm wondering what that best practice >>>>> is for marking opening_hours (as mentioned on the Buses wiki page >>>>> <https://wiki.openstreetmap.org/wiki/Buses#Step_2_-_Create_the_new_bus_relations>), >>>>> particularly when multiple buses may be at different points within the >>>>> route when the opening_hours status changes from one to the other. >>>>> *_Should the time be based on when the first and last bus on the variant >>>>> leave from the starting point or when there is the first difference >>>>> between the two routes _*(like the first time that the bus stops at one >>>>> bus stop instead of another)? I tried to do some searching on the wiki, >>>>> the old and new help forums, and the web in general, as well as looking >>>>> at the guides on the wiki pages for public transit, the route relation >>>>> page, and the buses page, but I was not able to find any specific advice >>>>> on how I should map the hours (and I wasn't able to find a specific >>>>> switch time from my transit agency either). >>>>> >>>>> For reference, the bus route I am referring to initially departs the >>>>> starting stop at 05:25, arriving at the first different stop at 05:53. >>>>> Each bus on this route continues to depart for the variant until the last >>>>> one (in the morning) on the variant leaves at 07:55 and arrives at the >>>>> first different stop at 08:23, ultimately reaching the final destination >>>>> stop at 08:37. However, before that bus has arrived at the stop, the next >>>>> bus on the route switches to the non-variant form of the route and >>>>> departs at 08:10, reaching the first different stop at 08:42. It then >>>>> continues on this route until the last bus (in the afternoon) on the main >>>>> route departs at 15:34. The variant bus then departs at 15:46, running >>>>> until the final variant bus (of the entire day) departs at 16:58, >>>>> reaching its destination at 17:40. The main route bus departs again at >>>>> 17:10 and continues until the last one on this route departs at 23:00 and >>>>> finally reaches its destination at 23:35. For anyone wishing to look at >>>>> this route themselves here is the master relation >>>>> <https://www.openstreetmap.org/relation/4271833> and here is my transit >>>>> agency's schedule <https://www.cata.org/schedules/01/1>. >>>>> >>>>> Thank you, >>>>> Aenet > _______________________________________________ > 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
