Proposal talk:Public transport schedules

Schedules change too often to put them on the map

Even if we have a new JOSM plugin, we will never be able to keep schedules up to date. They simply change too often. This idea could only work in two cases:

1. Rural areas where schedules are more or less constant
2. Or when there is a bot connected to a data source, updating schedules.

True. It really depends on the area, though. Google transit does a great job of keeping schedule data up to date, and I believe that OSM contributors could do that as well. I would certainly make a big effort to keep the data up to date. Interesting point about a bot updating schedules, though. That seems easy enough to implement, and would certainly fix the issue of outdated data.

Also, along with weekdays and weekends there are special days or periods where some buses/trains are added or removed from schedule e.g. "on Christmas Eve buses are working with Sunday's schedule, but only up to 19:00, then night lines take over". Or, in some cities, special timetables are published and put on stops only for a week around Christmas.

This is the same issue as with opening hours, so the departures tag or relation role, which would use the same format as post box collection times, would need to reflect that. If that is not possible, than data consumers could provide a "New Years Day might affect these arrival times" message. Good point, though. LeifRasmussen

Finally: why do you propose different format for stops' and platforms' timetables? Rmikke (talk) 00:52, 31 October 2018 (UTC)

I don't really, just the role starting with "stop" or "platform" would be changed. I would actually prefer to just use "stop" or "platform" for both stop positions and platforms. I am proposing using "platform:<arrival data>" and "stop:<arrival data>" currently, but I would love to just use one or the other if people like that. :) LeifRasmussen

Highjacking the roles in the route relations?

I would have loved to be able to say: great idea! Unfortunately maintaining those route relations is already a challenge as it is. Wouldn't it be possible to have a new type of relation public_transport=timetable, where we can take note of the timetable as they can be seen at the stops?

Amazing ideaǃ I have completely changed the proposal to implement this. LeifRasmussen

I'm afraid this will mean a relation for weekdays, another for Saturdays, another for Sundays and holidays and yet another for weekdays during school holidays. That's how it would work here in Belgium. I guess the Sunday/holidays relations would need to keep track which are the holidays, or maybe it would be better to store that information in yet another relation.

So

type=public_transport public_transport=timetable weekdays=06:00;06:12;.... saturdays=07:00;07:30;.... sundays=08:00;09:00;.... school_holiday_weekdays=

members: stop/platform= route=route relation for itinerary this applies to

Linking it to the route relations is somewhat tricky if there are several variations in itinerary for a line.

Not really - you just create a new timetable relation for each variation. LeifRasmussen

I think doing it this way is conceptually simpler than adding it into the roles of the route relations, but it would still not be possible to simply copy the stop's timetable literally for some lines.

I agree. LeifRasmussen

Unfortunately, I'm not totally convinced it would add much and it would indeed be a nightmare to maintain this kind of data. It's already a challenge to maintain the data of the itineraries (route relations) properly. In my own region we have access to real time data. And the route planner of the operator is very likely to start taking that into account when planning trips.--Polyglot (talk) 07:48, 31 October 2018 (UTC)

Umaintainable

It is impossible to maintain this data. For example in my city timetables changes multiple times each year. Even routes of lines change too often to keep them up to date Mateusz Konieczny (talk) 14:40, 31 October 2018 (UTC)

Wow. That is very often. Where I live, they only change every 2-5 years. Perhaps it would be a good idea to only add this type of data in places where timetables are consistent. I have changed the proposal to match Polyglot's idea, which is much better than mine. ː) Because of this, timetable relations could be added and deleted super easily, without affecting existing features in any way or form. Thanks for the feedbackǃ LeifRasmussen

Well, in my city they even do create special routes that exist only for a week or two. Publishing special timetables for specific periods is a regular practice. That's why the only way to present timetables in OSM is the idea of adding a "GTFS link" to a stop in route's relation - someone coined this idea in Tagging list in your thread. Anything else will be umaintainable. Rmikke (talk) 23:34, 31 October 2018 (UTC)

Why not simply gives a link to the timetables on the web when possible. Maintaining a timetable will be difficult. Time tables for trains are changing each 6 months and some timetables are very complex (I can gives samples if needed). You can have a lot of exceptions, limited days or limited periods, alternative routes...wwwouaiebe 22:38, november 1 2018

Would that look like a link to a PDF? I could propose adding the tag "route_map"="https://www.townofchapelhill.org/Home/ShowDocument?id=40287" as part of this proposal.

Yes, a link to a pdf (when available) or to a web site ( when pdf not available - not always easy to find a pdf). wwwouaiebe 16:21, november 2 2018

It would probably be a good idea to link the GTFS feed directly instead if machine readable format is desired.C933103 (talk) 03:31, 12 February 2019 (UTC)

I have to agree with Mateusz, OSM is just not a good place for this. Times change to often, conditions ("only on school days, but not un Thursdays") are way to complicated to fit them into a single 255 character sized value. --Mueschel (talk) 20:20, 12 February 2019 (UTC)

A relation for each (stop, route) pair, really?

Did I understand correctly that the public_transport=timetable relations are specific to an individual stop on a route? That is, a single route would require n_stops relations in order to have a complete timetable (where n_stops is the number of stops on the route in question). This would be a lot of relations and a maintainability nightmare.

I think the earlier version of this proposal was better with the 'departures' tag in the route relation and 'delay' information per stop. However, I don't think it's wise to code the delay in the route relation member roles, as this will probably break a lot of existing tools. It would be better to add a tag like 'delay:<route_ref> = 15' to the stop object, which is then included in the route relation with a stop or platform role, just like they are now. Keimo (talk) 09:22, 2 November 2018 (UTC)

Given that the operators work with a database that contains 5-6 tables, this is the simplest I can think of, IF we want the ability to go in full detail. I agree that it's a maintenance nightmare for lines that change several times a year. And yes, lots and lots of extra relations. The positive thing about those relations is that they aren't broken by people editing ways. But how will we know they became invalid?

A simpler way would be to put the departures as each stop's role property, rather than as a tag on the relation and a generic "stop" role for a single stop. Then it'd be a single relation for each route (assuming that the departures don't exceed ~250 characters, which some here do; splitting into weekday/Saturday/Sunday/holiday relations, possibly even more, would be required for those). Still a maintenance nightmare for updating, but possibly slightly less of a nightmare for a (TBD?) consumer. (For the record, I am against storing timetable data in OSM, and would vote against.) --goldfndr (talk) 23:39, 4 January 2019 (UTC)

Then the question becomes, will this be used by people/apps? If not, it's easy to dismiss the idea. I think it's best to focus first on a system that gives a general idea of the frequency for time of day depending on day of week and Saturday/Sunday/holidays and then decide whether that's enough, or more detail is still wanted.--Polyglot (talk) 11:22, 2 November 2018 (UTC)

I could add the "departures" tag in public transport routes as a new proposal if you want. LeifRasmussen

One of my local bus stops has 7 routes. Will each route have its own timetable relation? Timetable changes are every month on several of these routes - nightmare to maintain. Personally I will not be interested in maintaining timetables. Information I actually want from a bus route is where does it go and how frequently. Some buses I have known operate every 10 minutes or 6 buses per hour and that is how it is written in the timetable, and a lower frequency in the evening. Here in the UK we have a public service called Traveline https://www.traveline.info/ which provides all Great Britain timetable info and uses OSM to overlay its route data. Overall - even with bots I do not see how this could be maintained and store all the actual data within 256 chars.

Well, what I think is that if timetable relations are out of date, they can just be deleted in bulk with an overpass query and JOSM. The challenge then becomes re-adding the timetables. For the bus route you are describing, the tags interval=00ː10 and intervalːconditional can be used. It is totally possible that this data will not be maintained, and instead just deleted.

How do you tell which data can be deleted and which is old but still up-to-date? It's common that there is no ending date given when a new schedule is published. --Mueschel (talk) 20:18, 12 February 2019 (UTC)

Ferry routes

I don't see why ferry routes should be treated as a special case. Certainly it should be possible to map them just like any other public transport route with route variants for both directions. Keimo (talk) 09:29, 2 November 2018 (UTC)

The ferry route proposal is quite simple as is, just different from the other proposal. It just includes "departuresː<forward/backward>" and "durationː<forward/backward>". If this is unknown, the tag "interval" is used for frequency.

But why ferries need a special case? They can be mapped with a route relation (with route=ferry) like any other public transport route. See for example this route_master relation and its members: https://www.openstreetmap.org/relation/8051359

Cool - perhaps it would be better to do it the "timetable relation" way in those cases. I am not sure how that would work, though. LeifRasmussen

Operator's holidays that use Sunday schedule and school holidays

Hi,

I've been giving this quite a bit of thought (over the years and over the past few days).

When creating timetables that go in full detail - and even though I'm pretty sure there will be a lot of resistance against this proposal, I want to investigate it to the full extent - we will need a way to define what are considered to be holidays on which the Sunday schedule comes into vigor and which weekdays are part of school holidays. At least those are the factors that influence timetables in my heck of the woods.

type=public_transport
public_transport=public_holidays
operator=
network=
name=Holidays and off school days in Flanders
01-01      =  New Year's Day
05-01      =  Labour Day
12-25      =  Christmas Day
2018-04-01 =  Easter 2018
2018-12-24 =  no school;Christmas Holidays
2018-12-26 =  no school;Christmas Holidays
2018-12-27 =  no school;Christmas Holidays
2018-12-28 =  no school;Christmas Holidays
2018-12-31 =  no school;Christmas Holidays
2019-01-02 =  no school;Christmas Holidays 
2019-01-03 =  no school;Christmas Holidays 
2019-01-04 =  no school;Christmas Holidays

Either this is a relation with no members that is added as a member to all the timetable relations, or it contains all the timetable relations it applies to (seems harder to maintain and could be 'accused of' being a category relation).

--Polyglot (talk) 15:20, 4 November 2018 (UTC)

I like this, but it seems sort of vague to include just "school days" rather than actual dates. A data consumer would not necessarily know the school days of some random city with this tagging scheme. Perhaps a tag "departures"="<whateveɾ>" and "departuresːconditional"‍="<whateveɾ>", "departuresːconditional#1"‍ː="<conditional extended to avoid 255 limit>", "departuresːconditional#2"‍ː="<more extension to avoid 510 char limit>", etc would work better. This would be harder to add, but would be more practical for data consumers.

--LeifRasmussen

Actually this is the relation that gives those specific dates. For holidays on a fixed date, I'd omit the year, but the weekdays that fall during school holidays are there in full ISO format. It all still needs to be puzzled back together though. Tool support will definitely be necessary to help with that. Did you see the spreadsheet I created?

https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit?usp=sharing

That should make it easier to create such a timetable relation. And in the second tab the result can be viewed, so it becomes easier to compare with the timetable found at a specific bus stop. Work in progress though. Mostly experimenting. --Polyglot (talk) 00:02, 5 November 2018 (UTC)

I'm struggling with this difference between weekdays during school holiday periods and 'normal' weekdays. In the normal schedule there will be more buses, but also more exceptions to cater for school ending earlier on Wednesday and also more buses during rush hour.--Polyglot (talk) 08:21, 5 November 2018 (UTC)

Limitation of this proposal

• This proposal cannot be used to map services that have different intervals during different time, for example: https://www.nwstbus.com.hk/en/uploadedFiles/cust_notice/RI-CTB-6-6-D.pdf
• This proposal cannot be used to map services that have multiple time-fixed point where services are timed to depart at specific time, for example: http://www.nwff.com.hk/route/get_route.php?id=2e2c0154-902a-4c11-9405-f7743f6e6d2e&route_id=0&submenu_num=3&lang=en

C933103 (talk) 04:03, 12 February 2019 (UTC)

Licensing

Before we approve a tagging scheme like this, we should clarify how much data is actually available under a license that is compatible with ODbL. Unless it's officially published as Open Data we can neither use data from web pages nor data from time tables posted at bus stops. Even if everybody can read them, the information still has a copyright on them in most cases. --Mueschel (talk) 20:23, 12 February 2019 (UTC)

• Fact are not copyrightable. Only representation/expression of facts can be copyrighted. That's how they can be added to other sites like Wikipedia without problem. C933103 (talk) 22:52, 12 February 2019 (UTC)
  • I'm not refering to the US-American understanding of 'copyright' (which doesn't exist is many countries), I'm refering to any kind of license or restrictions on the data. As long as there is no freely licensed source, you can't add any 'facts' because you can't copy them from anywhere (unless you spend a week at a bus stop and take notes when the buses arrive. Mueschel (talk)