Re: Public Transport Timetables

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Leif Rasmussen
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
I'm mostly experimenting to figure out what can work. My initial though was a relation per route/stop pair, but that means a lot of relations. Then I was thinking: it would be nice to have an idea about the approximate time to get to the next stop, which led to what I did now. Taking that idea a bit further, why stop at only the next stop, if you can describe the whole itinerary?

I do think we need a plugin to make handling the information easier. I think it can easily be added to PT_Assistant if we manage to find someone who can code in JAVA.

What I like about doing it this way, is that it becomes possible to determine what will be the final stop for the particular bus that passes at that stop at that time. This is something we didn't have yet.

The other thing that is nice is that we now have a basis to sort the stops in the route relations on. (atm PT_Assistant has functionality to sort them along the highways, if they are sorted correctly).

For someone entering the data, it's enough to enter the departures times for the first stop. If the times between the stops are not known yet, the roles remain empty at first. Or we could put sequence numbers in there. About that, I do notice some have the same minute, it would be nice to have a way to sort the stops based on the times though.

If someone entered the times at a stop somewhere in the middle of the itinerary a tool can help adapt the times afterwards.


That PDF only describes what itineraries it takes on weekdays outside of school holidays...

Jo

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

OSMDoudou
Considering De Lijn may share their data as GTFS, isn’t it a better effort to integrate instead of duplicate existing data?


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

dieterdreist
In reply to this post by Leif Rasmussen


sent from a phone

> On 3. Nov 2018, at 16:24, Leif Rasmussen <[hidden email]> wrote:
>
> Polyglot:
> I think that having a timetable relation for each stop is less complicated than having one per route.


In Rome there are no timetables for bus stops, there are theoretical departure times from the terminal (which give you a theoretical frequency). Bus stop related timetables would make zero sense here.

Also the frequency currently is not very reliable, but at least it can give some indication.

The most important distinction for buses I see around here is:
-ordinary daytime bus route (different frequencies)
-bus route on sundays / holidays (often route variations)
-night bus (not operating during the day)
-tourist route (very few lines)

Cheers, Martin



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
In reply to this post by OSMDoudou
You are right, for the concrete case of De Lijn it will be better to link to their realtime data from the stops and add a url to the route relations for the timetables. I'm merely using these as a test case, a proof of concept. I'm not planning to add all of them. I think it does make sense for the school, market and student buses that run relatively infrequently.

Jo


Op za 3 nov. 2018 om 23:16 schreef OSMDoudou <[hidden email]>:
Considering De Lijn may share their data as GTFS, isn’t it a better effort to integrate instead of duplicate existing data?


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
In reply to this post by Leif Rasmussen
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
... and/or an abbreviation with the frequency : departures=5:15 - 1:25 every 1:30 ~ 3 minutes
(This is for Rennes’ subway line)

Julien « djakk »


Le mar. 6 nov. 2018 à 16:07, djakk djakk <[hidden email]> a écrit :
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
In reply to this post by djakk
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each timetable describes the arrival time and the departure time of several trips at the stop. 

There must be the same number of trips along the stops’ timetables. (Otherwise this is an other route). 

You mean, if somebody messed up and add an extra trip inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo <[hidden email]> a écrit :
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
Yes, very hard to debug and we already established some change every few months. So after a change from the operator. One traveler will update one of those schedules, Another may do so for 3 stops down the line, in the mean time the stops in between and after are not updated yet. A maintenance nightmare. The way I proposed it, suffers less from that problem. When timetables change it's usually that trips are added or removed or their start time changes slightly. The time to get from one stop to the next will remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk <[hidden email]>:
I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each timetable describes the arrival time and the departure time of several trips at the stop. 

There must be the same number of trips along the stops’ timetables. (Otherwise this is an other route). 

You mean, if somebody messed up and add an extra trip inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo <[hidden email]> a écrit :
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

djakk
Ok I see. 

I am still a bit reluctant to your proposal since the travelling time between 2 stops can vary during the day, especially for train routes. 
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with your proposal (it needs to know the timetable for the whole line), we’ll depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo <[hidden email]> a écrit :
Yes, very hard to debug and we already established some change every few months. So after a change from the operator. One traveler will update one of those schedules, Another may do so for 3 stops down the line, in the mean time the stops in between and after are not updated yet. A maintenance nightmare. The way I proposed it, suffers less from that problem. When timetables change it's usually that trips are added or removed or their start time changes slightly. The time to get from one stop to the next will remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk <[hidden email]>:
I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each timetable describes the arrival time and the departure time of several trips at the stop. 

There must be the same number of trips along the stops’ timetables. (Otherwise this is an other route). 

You mean, if somebody messed up and add an extra trip inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo <[hidden email]> a écrit :
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Yves-2
Are you looking for a general transit feed specification?
:)
Yves

Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk <[hidden email]> a écrit :
Ok I see. 

I am still a bit reluctant to your proposal since the travelling time between 2 stops can vary during the day, especially for train routes. 
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with your proposal (it needs to know the timetable for the whole line), we’ll depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo <[hidden email]> a écrit :
Yes, very hard to debug and we already established some change every few months. So after a change from the operator. One traveler will update one of those schedules, Another may do so for 3 stops down the line, in the mean time the stops in between and after are not updated yet. A maintenance nightmare. The way I proposed it, suffers less from that problem. When timetables change it's usually that trips are added or removed or their start time changes slightly. The time to get from one stop to the next will remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk <[hidden email]>:
I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each timetable describes the arrival time and the departure time of several trips at the stop. 

There must be the same number of trips along the stops’ timetables. (Otherwise this is an other route). 

You mean, if somebody messed up and add an extra trip inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo <[hidden email]> a écrit :
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables

Jo-2
In reply to this post by djakk
Indeed, a mapper who wants to add this and who can't find the information on the internet or in a booklet, would have travel to the first stop, take note of all the departure times and then establish the deltas between all the stops of the itinerary.
If that's the case, such a mapper would probably better use the tags based method on the route relations.

It all depends on how much detail you want to add (and maintain in the long run).

Another weakness of the relation pet stop/route pair method is that it will be very hard to encode the exceptions; not on Wednesdays, only on Fridays, etc.

Jo

Op di 6 nov. 2018 om 20:22 schreef djakk djakk <[hidden email]>:
Ok I see. 

I am still a bit reluctant to your proposal since the travelling time between 2 stops can vary during the day, especially for train routes. 
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with your proposal (it needs to know the timetable for the whole line), we’ll depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo <[hidden email]> a écrit :
Yes, very hard to debug and we already established some change every few months. So after a change from the operator. One traveler will update one of those schedules, Another may do so for 3 stops down the line, in the mean time the stops in between and after are not updated yet. A maintenance nightmare. The way I proposed it, suffers less from that problem. When timetables change it's usually that trips are added or removed or their start time changes slightly. The time to get from one stop to the next will remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk <[hidden email]>:
I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each timetable describes the arrival time and the departure time of several trips at the stop. 

There must be the same number of trips along the stops’ timetables. (Otherwise this is an other route). 

You mean, if somebody messed up and add an extra trip inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo <[hidden email]> a écrit :
If you have a single one for a stop/route pair, no problem. As soon as you have a few hundred and the information in them starts to conflict with other another timetable relation for the same route it will be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk <[hidden email]>:
In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk <[hidden email]> a écrit :
I think it is important to have an osm object describing the timetable user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import it later in osm without the need of any extra tool. 
Validator can be inside a tool. 

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk <[hidden email]> a écrit :
Almost that ! Sometimes bus stops does not have their official timetable, the user have to refer to the closest previous bus stop having an official timetable. So this kind of bus stop may not have a timetable in osm (except an osm mapper really wants to put it into osm, knowing per habits the schedule). 


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo <[hidden email]> a écrit :
You mean per stop/route pair? That's an incredible s amount of relations! It seems to me that it would be a nighmare to try and maintain it that way. At first sight it seems simpler, but with the new proposal i came up with, you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become 00:30-00:35 instead of simply 00:35 for the departure offset to the time the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served also enables comparing this with the stops sequence in the route relation they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk <[hidden email]>:
I’ll agree with Leif, having a timetable relation per stop is better. 


Yes Leif, there can be a delay expressed in minutes instead of an arrival-departure pair of time. 

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk <[hidden email]> a écrit :
In order to reduce the length of the value of the departures= tag, should we allow this kind of abstraction level : departures=5:35 ; 6:35 ; [7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk <[hidden email]> a écrit :
Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo <[hidden email]> a écrit :
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a new one. It differs in rather important ways from your proposal, so I preferred not modifying your wiki page. I also think it's important to decouple the (voting for a) full timetable solution from the solution where tags are added to indicate interval during 'opening_hours' or a route, which is a lot more likely to be accepted.

So here goes:

Please let me know what you think. What I still haven't figured out yet is how to differ weekdays that fall in school holiday periods from "normal" weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <[hidden email]>:
Polyglot:
I think that having a timetable relation for each stop is less complicated than having one per route.  There are several advantages to this:
1) People can easily add a single relation at a time, rather than having to do the entire line at one time.  This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?"  iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations.  It also makes more features possible in the future, such as additional tags to each timetable.
2) The system is easier for newbies to learn to use.

The disadvantage is that there are now a ton of relations per bus / train / subway route.  Creating these could made easier by a new JOSM plugin.  Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf  

If people really prefer a single timetable relation for each route, then I will go with that.  

Julien:
Why not have a "delay"="<amount of time between arrival and departure at this platform>" tag instead of separate arrivals/departures tags?

Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123