Public Transport Timetables Proposal RFC

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

Public Transport Timetables Proposal RFC

Leif Rasmussen
Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. 


Please feel free to look over the page and give feedback.  I am very open to changing the proposal, so let me know if you have any ideas for improvements to it.
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 Proposal RFC

Tom Pfeifer
I am strongly against storing timetable data in OSM.

tom

On 31.10.2018 00:54, Leif Rasmussen wrote:

> Hello everyone!
> I recently wrote up a proposal page for public transport schedule data.  This information would
> allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a
> platform.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
>
> Please feel free to look over the page and give feedback.  I am very open to changing the proposal,
> so let me know if you have any ideas for improvements to it.
> 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 Proposal RFC

OSMDoudou
In reply to this post by Leif Rasmussen
A couple of thoughts:

- The schedules I know have values different for week days and week-ends and again for school holidays, so I wonder if the depature tag value (as well as the other timetable tags) of frequent departure lines will not run into the 255 character limit. This is similar to the opening_hours tag which was discussed recently [1]. This possible issue should be looked into: based on real data: how likely is it to happen, and how can the tagging scheme circumvent the limit?

- As the proposal mentions, there exist public and maintained sources of data (GTFS). Can you discuss how this proposal will not result on the long run in duplicating these data, thus requiring double maintenance? Wouldn't it be better to interface and integrate this external data (like with wikimedia tag)?

[1] https://lists.openstreetmap.org/pipermail/tagging/2018-October/039889.html


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

Re: Public Transport Timetables Proposal RFC

OSMDoudou
In reply to this post by Leif Rasmussen
As you don't provide more details, this statement reads as a personal preference and isn't helping in improving the proposal of enabling public transport routing. Can you make a more factual and informative explanation as to how it would be bad for OSM to contain timetable data? The proposal mentions a number of interesting use cases. Thx.

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

Re: Public Transport Timetables Proposal RFC

djakk
Hello ! I think it’s a good idea to “replace” GTFS files with OSM data. 

In OSM there is already half of the GTFS (the relations that describes stops and route). 

Most lines of big cities can be map with frequency only (subway every 90 seconds during rush hour, 3 minutes otherwise). 


djakk



Le mer. 31 oct. 2018 à 09:02, OSMDoudou <[hidden email]> a écrit :
As you don't provide more details, this statement reads as a personal preference and isn't helping in improving the proposal of enabling public transport routing. Can you make a more factual and informative explanation as to how it would be bad for OSM to contain timetable data? The proposal mentions a number of interesting use cases. Thx.
_______________________________________________
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 Proposal RFC

voschix
In reply to this post by OSMDoudou
It is generally a bad idea to store data twice in different places. Any database expert will agree with that.
It's a simple question of data maintanance.
OSM is being suffocated with imports/insertion of data that are maintained outside OSM, and hence needs regular re-import or manual update:
buildings, landuse, monumental trees, publc transport routes, whatever, and now even time tables of public transpiort.
How on earth can we maintain all that stuff in a single data base with our manpower?
And as we cannot maintain our data copies in OSM, they will drift apart from the originals from the moment they are imported/inserted. No reasonable person would trust public transport timetables that are in OSM.

My five Eurocents.

Volker





On Wed, 31 Oct 2018 at 09:02, OSMDoudou <[hidden email]> wrote:
As you don't provide more details, this statement reads as a personal preference and isn't helping in improving the proposal of enabling public transport routing. Can you make a more factual and informative explanation as to how it would be bad for OSM to contain timetable data? The proposal mentions a number of interesting use cases. Thx.
_______________________________________________
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 Proposal RFC

Jo-2
In reply to this post by djakk


Op wo 31 okt. 2018 om 09:31 schreef djakk djakk <[hidden email]>:
Hello ! I think it’s a good idea to “replace” GTFS files with OSM data. 

In OSM there is already half of the GTFS (the relations that describes stops and route). 

We have the part of GTFS that makes sense to have in a geographical database. That's only 10-15% of what is found in a GTFS file though, not 50%. We're already struggling to keep that part up-to-date. I'm not convinced either it would be a good idea to try and add timetable data into OSM. Doing it in full detail gets very complex, very fast, due to all the exceptions and not doing it in full detail is not useful to begin with.
For irregular services like school buses or market buses, it may make sense to use an opening hours scheme as they only function 2 times a day or 1 day per week. For metro lines it may make sense to indicate whether to expect 1 every 5 or 1 every 15 minutes.

Polyglot



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

Re: Public Transport Timetables Proposal RFC

Frederik Ramm
In reply to this post by Leif Rasmussen
Hi,

On 31.10.2018 00:54, Leif Rasmussen wrote:
> I recently wrote up a proposal page for public transport schedule data. 
> This information would allow OpenStreetMap to store information about
> when or how often certain buses or trains arrive at a platform.

Surveying that is hard, and the results only valid for half a year or a
year at best.

Copying the information may violate a third party's database right, and
also burdens OSM with dead data that will not be properly maintained.

Therefore I don't think public transport schedules have a place in OSM.

One thing we could investigate is some sort of indication whether a bus
or train route tagged in OSM is frequent, infrequent, or rarely used -
but we'd have to find a classifier for this that is vague enough to not
change twice a year, and precise enough to still be useful (and e.g.
draw "infrequent" lines with a dashed color on a public transport map or
so).

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

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

Re: Public Transport Timetables Proposal RFC

djakk
If we allow timetables in OSM, transit companies will possibly maintain directly them through OSM ;)

There is a lot of non-geographical informations in OSM like the opening hours of a shop so public transport schedule does not shocked me :)


djakk

Le mer. 31 oct. 2018 à 09:58, Frederik Ramm <[hidden email]> a écrit :
Hi,

On 31.10.2018 00:54, Leif Rasmussen wrote:
> I recently wrote up a proposal page for public transport schedule data. 
> This information would allow OpenStreetMap to store information about
> when or how often certain buses or trains arrive at a platform.

Surveying that is hard, and the results only valid for half a year or a
year at best.

Copying the information may violate a third party's database right, and
also burdens OSM with dead data that will not be properly maintained.

Therefore I don't think public transport schedules have a place in OSM.

One thing we could investigate is some sort of indication whether a bus
or train route tagged in OSM is frequent, infrequent, or rarely used -
but we'd have to find a classifier for this that is vague enough to not
change twice a year, and precise enough to still be useful (and e.g.
draw "infrequent" lines with a dashed color on a public transport map or
so).

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
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 Proposal RFC

Topographe Fou
In reply to this post by Leif Rasmussen
Hi Leif,

I would rather consider the ability to store a "GTFS API link" (or something similar) in transport relations. As soon as its stops are well referenced, then an app will have everything it needs with nearly no need from users to update them (and ability to automatically detect missing or extra stops for QA tools).

Yours

LeTopographeFou
Envoyé: 31 octobre 2018 1:26 AM
Répondre à: [hidden email]
Objet: [Tagging] Public Transport Timetables Proposal RFC

Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. 


Please feel free to look over the page and give feedback.  I am very open to changing the proposal, so let me know if you have any ideas for improvements to it.
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 Proposal RFC

djakk
Moreover, GTFS always have some errors, as they are maintained by only a few people. 


djakk


Le mer. 31 oct. 2018 à 10:17, Topographe Fou <[hidden email]> a écrit :
Hi Leif,

I would rather consider the ability to store a "GTFS API link" (or something similar) in transport relations. As soon as its stops are well referenced, then an app will have everything it needs with nearly no need from users to update them (and ability to automatically detect missing or extra stops for QA tools).

Yours

LeTopographeFou
Envoyé: 31 octobre 2018 1:26 AM
Répondre à: [hidden email]
Objet: [Tagging] Public Transport Timetables Proposal RFC

Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. 


Please feel free to look over the page and give feedback.  I am very open to changing the proposal, so let me know if you have any ideas for improvements to it.
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 Proposal RFC

Michael Reichert-3
In reply to this post by Leif Rasmussen
TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
Please store them outside of OSM and link them using foreign keys.


Hi Leif,

Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> I recently wrote up a proposal page for public transport schedule data.
> This information would allow OpenStreetMap to store information about when
> or how often certain buses or trains arrive at a platform.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

I think that the frequency and the days a route is served is sufficient.
There should not be any more details about the timetable in OSM beyond
that. While public transport looks simple :-) if you look at urban
areas, it becomes difficult to model if you go to the boundary of urban
areas or even into rural areas or developing countries.

OSM already struggles to model route relations for bus lines which have
15 trips per day but 12 different variants (e.g. bus lines in rural
Germany). How do you deal with train lines which run on days matching
the following specification only?

> nur Fr, So
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>
> Fr = Friday
> So = Sunday
> nur … = on … only
> auch … = also on …
> nicht … = not on …
This specification changes every year and it can't be simplified to "Fr,
Su and public holidays in at least two German states". Currently, many
route relations don't have to be modified every year but your tagging
schema would force mappers to do so. And the example above is quite
simple. In practice, the specification is even longer because many
constructions to refurbish the railway network a running and lead to
different departures nearly every second weekend or trains don't serve
the whole line from start to end because parts of the line are closed on
some weekends/weeks during the year due to constructions.

How would you deal with lines which have a clear interval of 60 minutes
if you round all depatures and arrival times? There are a lot of train
lines where the times differ by a +-3 minutes through the day. Peak vs.
off-peak is not the reason.

OSM was designed to be a database for geometries with attributes. The
database design of OSM has some issues but I am sure that database
designed for public transport timetables would not require the timetable
to be encoded into relation membership roles and relation tags.

Using OSM to encode timetables looks more like a ugly hack and should be
solved by having some kind of foreign key as tag of the route relation
which is used by a separate database project under a free and open
license which is designed for and used to store timetable information.

Nobody forbids anyone to run a project for crowdsourced timetable
information. But it is out of scope for OSM.

Your tagging proposal suggests to use relation membership roles to store
depatures in a way like that:
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"

Aren't membership roles limited to 256 characters, too?

In addition, your tagging schema is incompatible with the current public
transport tagging schema and probably all recently discussed proposals
which aim to replace or improve it. All of them know a role "platform".
From my point of view, relation membership roles are keys. Keys should
not contain value information.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Public Transport Timetables Proposal RFC

Joseph Eisenberg
I agree that it would be useful and reasonable to have frequency (headway’s) and the days a route is served.

Here in Indonesia, most local buses do not run on a timetable, but it would be very useful to know if there is one bus a day, one per hour, or one per minute. This makes a huge difference, and can be verified without needing to copy an official timetable, if you know the local routes.

Even back in the USA it would be useful and reasonably maintainable to record the frequency of transit vehicles at different times. Something like “Mo-Fr every 30m 5:30-7:00; 10m 7:00-9:00; 15m 9:00 to 15:00; 10m 15:00 to 18:00; 30m 18:00 to 22:00”

This gets you most of the information you need to make a good public transit map, because you can have more frequent routes render with wider lines or brighter colors. And it even provides enough info for approximate route planning.

In developing countries this would probably be the highest level of detail available. There are no GTFS databases for most of the non-Western world, so it would be useful.

Joseph
On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert <[hidden email]> wrote:
TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
Please store them outside of OSM and link them using foreign keys.


Hi Leif,

Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> I recently wrote up a proposal page for public transport schedule data.
> This information would allow OpenStreetMap to store information about when
> or how often certain buses or trains arrive at a platform.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

I think that the frequency and the days a route is served is sufficient.
There should not be any more details about the timetable in OSM beyond
that. While public transport looks simple :-) if you look at urban
areas, it becomes difficult to model if you go to the boundary of urban
areas or even into rural areas or developing countries.

OSM already struggles to model route relations for bus lines which have
15 trips per day but 12 different variants (e.g. bus lines in rural
Germany). How do you deal with train lines which run on days matching
the following specification only?

> nur Fr, So
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>
> Fr = Friday
> So = Sunday
> nur … = on … only
> auch … = also on …
> nicht … = not on …

This specification changes every year and it can't be simplified to "Fr,
Su and public holidays in at least two German states". Currently, many
route relations don't have to be modified every year but your tagging
schema would force mappers to do so. And the example above is quite
simple. In practice, the specification is even longer because many
constructions to refurbish the railway network a running and lead to
different departures nearly every second weekend or trains don't serve
the whole line from start to end because parts of the line are closed on
some weekends/weeks during the year due to constructions.

How would you deal with lines which have a clear interval of 60 minutes
if you round all depatures and arrival times? There are a lot of train
lines where the times differ by a +-3 minutes through the day. Peak vs.
off-peak is not the reason.

OSM was designed to be a database for geometries with attributes. The
database design of OSM has some issues but I am sure that database
designed for public transport timetables would not require the timetable
to be encoded into relation membership roles and relation tags.

Using OSM to encode timetables looks more like a ugly hack and should be
solved by having some kind of foreign key as tag of the route relation
which is used by a separate database project under a free and open
license which is designed for and used to store timetable information.

Nobody forbids anyone to run a project for crowdsourced timetable
information. But it is out of scope for OSM.

Your tagging proposal suggests to use relation membership roles to store
depatures in a way like that:
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"

Aren't membership roles limited to 256 characters, too?

In addition, your tagging schema is incompatible with the current public
transport tagging schema and probably all recently discussed proposals
which aim to replace or improve it. All of them know a role "platform".
From my point of view, relation membership roles are keys. Keys should
not contain value information.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


_______________________________________________
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 Proposal RFC

Allan Mustard
That’s true even in parts of the developed world.  It would be useful!

Sent from my iPhone

On Oct 31, 2018, at 4:18 PM, Joseph Eisenberg <[hidden email]> wrote:

I agree that it would be useful and reasonable to have frequency (headway’s) and the days a route is served.

Here in Indonesia, most local buses do not run on a timetable, but it would be very useful to know if there is one bus a day, one per hour, or one per minute. This makes a huge difference, and can be verified without needing to copy an official timetable, if you know the local routes.

Even back in the USA it would be useful and reasonably maintainable to record the frequency of transit vehicles at different times. Something like “Mo-Fr every 30m 5:30-7:00; 10m 7:00-9:00; 15m 9:00 to 15:00; 10m 15:00 to 18:00; 30m 18:00 to 22:00”

This gets you most of the information you need to make a good public transit map, because you can have more frequent routes render with wider lines or brighter colors. And it even provides enough info for approximate route planning.

In developing countries this would probably be the highest level of detail available. There are no GTFS databases for most of the non-Western world, so it would be useful.

Joseph
On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert <[hidden email]> wrote:
TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
Please store them outside of OSM and link them using foreign keys.


Hi Leif,

Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> I recently wrote up a proposal page for public transport schedule data.
> This information would allow OpenStreetMap to store information about when
> or how often certain buses or trains arrive at a platform.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

I think that the frequency and the days a route is served is sufficient.
There should not be any more details about the timetable in OSM beyond
that. While public transport looks simple :-) if you look at urban
areas, it becomes difficult to model if you go to the boundary of urban
areas or even into rural areas or developing countries.

OSM already struggles to model route relations for bus lines which have
15 trips per day but 12 different variants (e.g. bus lines in rural
Germany). How do you deal with train lines which run on days matching
the following specification only?

> nur Fr, So
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>
> Fr = Friday
> So = Sunday
> nur … = on … only
> auch … = also on …
> nicht … = not on …

This specification changes every year and it can't be simplified to "Fr,
Su and public holidays in at least two German states". Currently, many
route relations don't have to be modified every year but your tagging
schema would force mappers to do so. And the example above is quite
simple. In practice, the specification is even longer because many
constructions to refurbish the railway network a running and lead to
different departures nearly every second weekend or trains don't serve
the whole line from start to end because parts of the line are closed on
some weekends/weeks during the year due to constructions.

How would you deal with lines which have a clear interval of 60 minutes
if you round all depatures and arrival times? There are a lot of train
lines where the times differ by a +-3 minutes through the day. Peak vs.
off-peak is not the reason.

OSM was designed to be a database for geometries with attributes. The
database design of OSM has some issues but I am sure that database
designed for public transport timetables would not require the timetable
to be encoded into relation membership roles and relation tags.

Using OSM to encode timetables looks more like a ugly hack and should be
solved by having some kind of foreign key as tag of the route relation
which is used by a separate database project under a free and open
license which is designed for and used to store timetable information.

Nobody forbids anyone to run a project for crowdsourced timetable
information. But it is out of scope for OSM.

Your tagging proposal suggests to use relation membership roles to store
depatures in a way like that:
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"

Aren't membership roles limited to 256 characters, too?

In addition, your tagging schema is incompatible with the current public
transport tagging schema and probably all recently discussed proposals
which aim to replace or improve it. All of them know a role "platform".
From my point of view, relation membership roles are keys. Keys should
not contain value information.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


_______________________________________________
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 Proposal RFC

Dave F
In reply to this post by Leif Rasmussen
Hi

I hope you're open to rescinding this proposal.

This data is too transient to be of benefit within the OSM database. The poor implemented & negligibly maintenance of opening hours is a good example as to why it shouldn't be added.

The numerous Public Transport schemas are a mess. Their problems need sorting out, not adding to. From what I've seen, most of PT's tags are duplicates of other which are already established & work well. See 'public_transport=station'

'stop_areas' are a pig's ear of incomprehensibility. Even those who conceived it appear uncertain as to its scope.

Cheers
DaveF
 

On 30/10/2018 23:54, Leif Rasmussen wrote:
Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. 


Please feel free to look over the page and give feedback.  I am very open to changing the proposal, so let me know if you have any ideas for improvements to it.
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 Proposal RFC

Graeme Fitzpatrick
In reply to this post by Allan Mustard
As others have said, it could be handy but probably better just linked to an external data-base.

One concern I have is trying to insert a schedule for different routes that use the same stop?

eg This bus stop has a 53 bus about every 30 minutes from 7am till 5pm; a 65 bus every 10 minutes in peak time & 20 minutes outside 24 hours a day; a 77 bus every hour, from 6 till 6; a school bus at 8am; & a long-distance / interstate coach twice a day. (& that's not a made up example! - it's a single bus stop near us, but I've actually simplified the details a bit :-))

How would you insert that level of detail?

Thanks

Graeme

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

Re: Public Transport Timetables Proposal RFC

Leif Rasmussen
In reply to this post by Leif Rasmussen
Thanks for the feedback on this proposal!  Maintainability and corruption of existing features seem to be the two biggest concerns, both of which I have reduced in the new version of the proposal.  I really like the idea that Polyglot expressed on the talk page of the proposal of using a completely separate relation to represent a single timetable.  It is a completely different system that is much more elegant, versatile, practical, and simple.  By using a relation similar in design to turn restrictions, the complexity of this proposal has been reduced significantly.

The new version of the proposal will not affect existing public transport routes in any way or form.  They will remain unchanged and uncorrupted, similarly to how turn restrictions do not affect highways in any noticeable way.  Data consumers will not have to worry about any changes to public transport details.


Please let me know what you all think about the improved proposal.  Maintainability will still be difficult, but much easier than before.  It may also be possible for these types of relations to be added by, and checked for currency by, StreetComplete without much trouble.

Example of a timetable relation: https://www.openstreetmap.org/relation/8873463

Thank you,
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 Proposal RFC

seirra

this does feel like a much easier to understand idea now, it may be worth thinking of a way to still incorporate the interval in the second proposed feature, for example a local bus in my area has one every 10 minutes for a substantial amount of time.


On 10/31/18 21:04, Leif Rasmussen wrote:
Thanks for the feedback on this proposal!  Maintainability and corruption of existing features seem to be the two biggest concerns, both of which I have reduced in the new version of the proposal.  I really like the idea that Polyglot expressed on the talk page of the proposal of using a completely separate relation to represent a single timetable.  It is a completely different system that is much more elegant, versatile, practical, and simple.  By using a relation similar in design to turn restrictions, the complexity of this proposal has been reduced significantly.

The new version of the proposal will not affect existing public transport routes in any way or form.  They will remain unchanged and uncorrupted, similarly to how turn restrictions do not affect highways in any noticeable way.  Data consumers will not have to worry about any changes to public transport details.


Please let me know what you all think about the improved proposal.  Maintainability will still be difficult, but much easier than before.  It may also be possible for these types of relations to be added by, and checked for currency by, StreetComplete without much trouble.

Example of a timetable relation: https://www.openstreetmap.org/relation/8873463

Thank you,
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 Proposal RFC

Tijmen Stam
In reply to this post by Leif Rasmussen
> Thanks for the feedback on this proposal!  Maintainability and corruption
> of existing features seem to be the two biggest concerns, both of which I
> have reduced in the new version of the proposal.  I really like the idea
> that Polyglot expressed on the talk page of the proposal of using a
> completely separate relation to represent a single timetable.  It is a
> completely different system that is much more elegant, versatile,
> practical, and simple.  By using a relation similar in design to turn
> restrictions, the complexity of this proposal has been reduced
> significantly.
>
> The new version of the proposal will not affect existing public transport
> routes in any way or form.  They will remain unchanged and uncorrupted,
> similarly to how turn restrictions do not affect highways in any
> noticeable
> way.  Data consumers will not have to worry about any changes to public
> transport details.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

As others, I strongly oppose having public transport timetables in OS

Maintainability and doubling of data are the main problems. Any data
consumer that could do something with this, could just as well source
their data from a GTFS or similar feed. I heard one commenter say he/she
hoped PT companies would add their data to OSM - I think they far earlier
would invest into having their data automatically exported into GTFS (or
another open data format, such as BISON in the Netherlands)

Another drawback is that many lines would very quickly hit the
256-character value limit. I work in public transit, and many of "my"
lines have 50 trips per direction per day (but 220 is no exception) all
leaving at slightly different minutes of the hour and having slightly
different travel times. Things aren't so simple anymore that we have a
peak, off-peak and evening/sunday service pattern, and I think you grossly
underestimate the complexity of PT timetabling.

In my view, Openstreetmap is a geographical database and in my view this
is too far from geographical data to be a valuable OSM addition.

I see one exception where timetables could be useful and valuable
addition: anywhere where a "portage" function exists, where another mode
piggybacks on a timetabled transport: Cars on ferries or train shuttles,
bicycles on public elevators, walkers on funiculars etc.

These usually have a very predictable route and timetable structure
(exceptions off course apply)
•between two nodes without intermediate stops
•Fixed start and finish times based on day and period of year
(=opening_hours, may be different per direction)
•Fixed going tmes (e.g. :20 from point a, :50 from b) ór fixed headways
(every 15 minutes)
•Very predictable transit times (e.g. always 20 minutes)
•Usually quite distinct in their use and operation from "traditional"
public transit like buses or ferries

In this way, a data consumer can make a prediction of say, an ETA of a
route that uses a ferry with tags that are not much more complicated than
an opening_hours tag.

Just my 2 cents,
Tijmen/IIVQ


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

Re: Public Transport Timetables Proposal RFC

Leif Rasmussen
In reply to this post by Leif Rasmussen
Graeme Fitzpatrick:
I have changed the proposal, and the level of detail that you describe can now be added very easily.  At the bus stop, the proposal now states to create one new relation for each bus route stopping at that stop and include both the stop and the route inside each of those new relations.  Then, add the tag departures=* to mark the timetable.

Thanks, 
Leif

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