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

djakk
:)

Le mar. 6 nov. 2018 à 20:55, Yves <[hidden email]> a écrit :
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

dieterdreist
In reply to this post by djakk


sent from a phone

> On 6. Nov 2018, at 15:41, djakk djakk <[hidden email]> wrote:
>
> Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?


there are no timetables and the service is notoriously bad and infrequent, while management scandals are frequent. This weekend there will be a referendum about closing the public company and procurement by tender.

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

Jonathon Rossi
In reply to this post by Jo-2
I've been following along the few threads to better understand this topic, however I'm still feeling that mapping complex timetables is a bit like mapping the full menu of a cafe or restaurant, or the room options at a hotel. These things vary whenever the service business chooses and it is close to impossible to keep it up to date.

In Brisbane Australia, some PT timetables vary often especially with public holidays (local, state or federal), school holidays (which differ between schools) and especially with special events (sporting, concerts, etc). Sometimes timetables get more trips sometimes less, it can be quite variable throughout the year and not something that can be 100% codified into timetable rules, and obviously not known too far in advance.

I appreciate that timetables are very useful for consumers of maps, and understand that in some cities timetables can be reverse engineered by being somewhat observable (I would think copying a full timetable off a sign would classify as an import), however are we concerned that this adds a massive burden to maintain this data in OSM and it is very likely to always be out of date? If it is always going to be out of date will any app developer even integrate this data into their app when they can use GTFS feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of either application been consulted?

Having this data embedded in the OSM tags also forces apps to reduce their map cache duration to try to get more updated timetables.

I'm not very experienced with PT in OSM, but I'd have thought improving the tags for mapping objects to GTFS feeds, including the GTFS endpoints and license info as tags, and maybe then adding the ability to discover the GTFS Realtime extension would be the way to go. I think this would give much more power to app developers. It does overlap a little with Transitland, but obviously OSM wouldn't be polling or hosting the feeds, that would be up to an application developer.

Happy to hear any feedback if I've missed the point of this.

On Tue, Nov 6, 2018 at 2:07 AM Jo <[hidden email]> wrote:
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
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

--
Jono

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

Re: Public Transport Timetables

djakk
For example in Japan transit companies sells their timetable for about 1000€ ... maybe copying the timetable is forbidden but Osm can have at least an opening hour and a frequency for a line in Japan. 
An other example, the city of Accra (Ghana) : only share taxis, no transit authority, lines are already mapped in OSM, with a travel time and a frequency. 

Julien « djakk »


Le mer. 7 nov. 2018 à 14:37, Jonathon Rossi <[hidden email]> a écrit :
I've been following along the few threads to better understand this topic, however I'm still feeling that mapping complex timetables is a bit like mapping the full menu of a cafe or restaurant, or the room options at a hotel. These things vary whenever the service business chooses and it is close to impossible to keep it up to date.

In Brisbane Australia, some PT timetables vary often especially with public holidays (local, state or federal), school holidays (which differ between schools) and especially with special events (sporting, concerts, etc). Sometimes timetables get more trips sometimes less, it can be quite variable throughout the year and not something that can be 100% codified into timetable rules, and obviously not known too far in advance.

I appreciate that timetables are very useful for consumers of maps, and understand that in some cities timetables can be reverse engineered by being somewhat observable (I would think copying a full timetable off a sign would classify as an import), however are we concerned that this adds a massive burden to maintain this data in OSM and it is very likely to always be out of date? If it is always going to be out of date will any app developer even integrate this data into their app when they can use GTFS feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of either application been consulted?

Having this data embedded in the OSM tags also forces apps to reduce their map cache duration to try to get more updated timetables.

I'm not very experienced with PT in OSM, but I'd have thought improving the tags for mapping objects to GTFS feeds, including the GTFS endpoints and license info as tags, and maybe then adding the ability to discover the GTFS Realtime extension would be the way to go. I think this would give much more power to app developers. It does overlap a little with Transitland, but obviously OSM wouldn't be polling or hosting the feeds, that would be up to an application developer.

Happy to hear any feedback if I've missed the point of this.

On Tue, Nov 6, 2018 at 2:07 AM Jo <[hidden email]> wrote:
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
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

--
Jono
_______________________________________________
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 reply to this post by dieterdreist
That is something that OSM should map instead of the official timetable :)

In Paris it is almost the same case, the bus does not follow their official timetable due to grid locks. 

Julien « djakk »


Le mer. 7 nov. 2018 à 00:16, Martin Koppenhoefer <[hidden email]> a écrit :


sent from a phone

> On 6. Nov 2018, at 15:41, djakk djakk <[hidden email]> wrote:
>
> Martin, maybe locals do know their bus stop timetable, as they always use the service they may memorize the schedules ... ?


there are no timetables and the service is notoriously bad and infrequent, while management scandals are frequent. This weekend there will be a referendum about closing the public company and procurement by tender.

Cheers, Martin
_______________________________________________
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
In reply to this post by Leif Rasmussen
> including the GTFS endpoints and license info as tags, and maybe then adding the ability to discover the GTFS Realtime extension would be the way to go

+1

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

Re: Public Transport Timetables

Paul Allen
On Wed, Nov 7, 2018 at 2:15 PM OSMDoudou <[hidden email]> wrote:
> including the GTFS endpoints and license info as tags, and maybe then adding the ability to discover the GTFS Realtime extension would be the way to go

+1

Although I've never used AOL, I have to say "me too."

If a transport company already uses GTFS then they're not going to want to bother with duplicating
the same information in OpenStreetMap.  If they don't already use GTFS it's probably because they
don't want to put in that sort of effort and nobody is forcing them to use GTFS, so you have to rely
on mappers keeping it up to date (timetables in some places are very stable and in other places
subject to change almost upon whim).

It's possible some companies use some method, other than GTFS, with license conditions
that would allow it to be "screen scraped" in which case an auxiliary database might be appropriate
and the tagging scheme that references GTFS could be expanded to include this database.  But
I doubt it would cover more than a handful of cases and may not be worth the effort involved.

Worst case, most routes have one or more known operators and we could have a tag pointing to
the operator's web site (better still, the URL of the page showing timetables, best of all the URL of
the timetable for that route alone).  Preferably a key distinct from the current website/url keys, although
I'm open to arguments for re-using them.

And then there are copyright issues.  I can map one the path of variant of one bus route by riding the
bus and breach nobody's copyright.  Timetables, whether taken from a website, or a printed timetable
at a bus stop, open up copyright issues.  Who has the time to ride every journey on every route
several times (to avoid one-off variations giving the wrong time) to figure out what the timetable ought
to be?

Since we have many incomplete/missing/outdated bus routes it seems folly to add this extra
level of detail in this way.  In reality it would deal with a minority of the routes we already have
and would not be adequately maintained, resulting in stale info.  Incorrect information is worse
than no information.

--
Paul


_______________________________________________
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 do not agree with your last argument, it is like « do not add residential roads before primary roads are all mapped » ;-)

GTFS can have errors (I’ve worked with Paris’ GTFS, bus stops names in caps locks, sometimes misplaced), plus, as I said, does not reflect the reality (there was this train from Versailles to Paris scheduled at 8am, always suppressed for months) (or this bus line 85 from Paris to Saint-Ouen which very often terminates at the town hall instead of the docks due to delays due to long term tram construction - this enough regularly to be mapped). Only a independent and crowdsourced database can handle that. 

Julien « djakk »


Le mer. 7 nov. 2018 à 15:34, Paul Allen <[hidden email]> a écrit :
On Wed, Nov 7, 2018 at 2:15 PM OSMDoudou <[hidden email]> wrote:
> including the GTFS endpoints and license info as tags, and maybe then adding the ability to discover the GTFS Realtime extension would be the way to go

+1

Although I've never used AOL, I have to say "me too."

If a transport company already uses GTFS then they're not going to want to bother with duplicating
the same information in OpenStreetMap.  If they don't already use GTFS it's probably because they
don't want to put in that sort of effort and nobody is forcing them to use GTFS, so you have to rely
on mappers keeping it up to date (timetables in some places are very stable and in other places
subject to change almost upon whim).

It's possible some companies use some method, other than GTFS, with license conditions
that would allow it to be "screen scraped" in which case an auxiliary database might be appropriate
and the tagging scheme that references GTFS could be expanded to include this database.  But
I doubt it would cover more than a handful of cases and may not be worth the effort involved.

Worst case, most routes have one or more known operators and we could have a tag pointing to
the operator's web site (better still, the URL of the page showing timetables, best of all the URL of
the timetable for that route alone).  Preferably a key distinct from the current website/url keys, although
I'm open to arguments for re-using them.

And then there are copyright issues.  I can map one the path of variant of one bus route by riding the
bus and breach nobody's copyright.  Timetables, whether taken from a website, or a printed timetable
at a bus stop, open up copyright issues.  Who has the time to ride every journey on every route
several times (to avoid one-off variations giving the wrong time) to figure out what the timetable ought
to be?

Since we have many incomplete/missing/outdated bus routes it seems folly to add this extra
level of detail in this way.  In reality it would deal with a minority of the routes we already have
and would not be adequately maintained, resulting in stale info.  Incorrect information is worse
than no information.


--
Paul

_______________________________________________
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

Mateusz Konieczny-3
7. Nov 2018 16:15 by [hidden email]:

Only a independent and crowdsourced database can handle that.


Competent public transport company also can do it.


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

Re: Public Transport Timetables

Frederik Ramm
In reply to this post by Jonathon Rossi
Hi,

On 07.11.2018 14:35, Jonathon Rossi wrote:
> I've been following along the few threads to better understand this
> topic, however I'm still feeling that mapping complex timetables is a
> bit like mapping the full menu of a cafe or restaurant, or the room
> options at a hotel. These things vary whenever the service business
> chooses and it is close to impossible to keep it up to date.

Yes, that's why I continue to find that it is a very bad idea to try and
start mapping timetables.

At most, I would say let's map in coarse strokes how frequent a service
is (which is still something that is subject to change at the operator's
whim but maybe not as often).

Anything beyond that is madness and should not be in OSM. I just don't
want to say it every time someone enthusiastically posts in this thread,
and of course they can try it out - but as Andy Townsend said, I'd
suggest a serious trial first, and *then* attempts at standardisation,
instead of the other way round.

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

djakk
In reply to this post by Mateusz Konieczny-3
Then, why OSM as they are some competent national geographic societies ? ;-)

Julien « djakk »

Le mer. 7 nov. 2018 à 16:19, Mateusz Konieczny <[hidden email]> a écrit :
7. Nov 2018 16:15 by [hidden email]:

Only a independent and crowdsourced database can handle that.


Competent public transport company also can do it.

_______________________________________________
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

Mateusz Konieczny-3
Mapping, for example, buildings is feasible as it is possible to map the faster that they change.

Doing that for timetables is not going to work.

In addition, OSM data format is optimized for mapping buildings and horrible for

mapping timetables. I hope that in my mapping I will not encounter places with

piles of relations created in an attempt to map timetables.


7. Nov 2018 16:28 by [hidden email]:

Then, why OSM as they are some competent national geographic societies ? ;-)

Julien « djakk »

Le mer. 7 nov. 2018 à 16:19, Mateusz Konieczny <[hidden email]> a écrit :
7. Nov 2018 16:15 by [hidden email]:

Only a independent and crowdsourced database can handle that.


Competent public transport company also can do it.

_______________________________________________
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
(started writing this several hours ago)

The way this proposal is evolving, there will be 2  versions. One that gives an approximate idea of how much time there is between 2 buses for a given time of day/day of week. Those can be added as tags on the route relations.

That one should not be dismissed outright.

And another that goes into full detail, listing all the departures at the first stop and then lists all stops, with the most common times between stops as roles. For this we would need separate public_transport=timetable relations.

I've been trying how that could work and I can confirm what everybody already knew: it's a lot of work, even for lines that seem relatively simple at first sight! :-) An incredible time sink.

It is an interesting exercise though and I found some errors in the route relations while doing it.

One of the shortcuts I took when creating route relations is that I only mapped the longest variations. An advantage of adding the timetables the way I'm proposing it, is that the stop sequences of the shorter variations now also become visible. This may make validation easier to do. When stops are not in order anymore in a route relation, the validator can detect that.

But it's a lot of data to add and it becomes stale very quickly, plus it's hard to verify whether it's still OK, or not, even more so than the route relations for the buses. The only advantage is that they don't 'deteriorate' due to other people mapping. Errors are introduced in route relations all the time because they are so 'fragile', due to ways getting split, removed/readded to OSM, but not to the relations, etc.

Anyway, I wanted to make sure that the proposal is as good as can be, but I'm not convinced that it's maintainable for a larger region either.
Of course, 10 years ago, I was not convinced any small group of volunteers would be able to create a detailed map of the world.

I think, at present, it's far more important we get to a way of mapping public transport with a single object (preferably a node next to the highway) to represent each stop.

Polyglot



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

Re: Public Transport Timetables

Paul Allen
On Wed, Nov 7, 2018 at 5:08 PM Jo <[hidden email]> wrote:
(started writing this several hours ago)

And another that goes into full detail, listing all the departures at the first stop and then lists all stops, with the most common times between stops as roles. For this we would need separate public_transport=timetable relations.

I've been trying how that could work and I can confirm what everybody already knew: it's a lot of work, even for lines that seem relatively simple at first sight! :-) An incredible time sink.

And it can go stale, very quickly.  Sure, there are places where the same route has operated to the
same schedule since time immemorial, but there are other places where timetables change on whim.

And it's re-inventing the wheel.  GTFS already exists.  Could we do better?  Maybe, maybe not.  Could
we convince operators to duplicate their effort in maintaining GTFS and our alternative?  I very much
doubt it.  Could we convince data consumers to support our format as well as GTFS?  I very much
doubt that too.  This is not just re-inventing the wheel, it's insisting everyone has to fit our wheel as
well as the wheel they already have.  Good luck with that.

What we can do is come up with a tag to place on a route that points at a GTFS feed on the web.
That feed could be published by the operator or by an independent organization.  We could perhaps
encourage mappers to generate feeds where the operator doesn't provide them and maybe even
go so far as to run a web server hosting those feeds until such time as a more official feed is
available.  Even offer an alternative feed that our tag points to when the official feed is known to be
seriously incorrect.

I think we could (probably should) have a tag linking to the operator's timetable whether or not
a GTFS feed is available.  Even the query tool of the standard map exposes links that can be clicked
on.  That doesn't require a third-party app to make the info available to an ordinary user.

So, an interesting exercise.  One that (perhaps) had to be tried to determine if it was a good idea or
not.  And maybe there's room for a sloppy "once a day" or "once a week" tag on minor routes that
will probably never get a GTFS feed.

--
Paul

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

Re: Public Transport Timetables

OSMDoudou
> And it's re-inventing the wheel.  GTFS already exists.
> Could we do better?  Maybe, maybe not.

Indeed. If someone determines GTFS needed improvement, it’s best to work in that community to improve it instead of inventing another standard. This xkcd comic is particularly well suited for this situation: https://xkcd.com/927/.

> We could perhaps encourage mappers to generate
> feeds where the operator doesn't provide them and maybe even
> go so far as to run a web server hosting those feeds until
> such time as a more official feed is available.

It’s very much what I have in mind as well.

We should think one step further than the tagging and figure a solution for maintaining and hosting GTFS files in case the PT organization doesn’t publish one. If we can resolve the issue of hosting the files, it will encourage OSM contributors to think more towards contributing to a web of data and less into “forcing” whatever geo-related data in OSM database.

And hosting these files doesn’t need to be complex. For example, certain JOSM plug-in’s have their configuration hosted in the wiki: https://josm.openstreetmap.de/wiki/Presets#JOSMwikiAvailablepresetpreferredmethod. So, we maybe already have the solution (with the OSM wiki, not the JOSM wiki).

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

Re: Public Transport Timetables

OSMDoudou
Just a quick web search, but it appears there exist GTFS editors and there is an entire ecosystem around creating and hosting GFTS files. Here is one editor, for example: https://conveyal-data-tools.readthedocs.io/en/latest.

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

Re: Public Transport Timetables

OSMDoudou
In reply to this post by OSMDoudou
(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:18, OSMDoudou <[hidden email]> wrote:

> And it's re-inventing the wheel.  GTFS already exists.
> Could we do better?  Maybe, maybe not.

Indeed. If someone determines GTFS needed improvement, it’s best to work in that community to improve it instead of inventing another standard. This xkcd comic is particularly well suited for this situation: https://xkcd.com/927/.

> We could perhaps encourage mappers to generate
> feeds where the operator doesn't provide them and maybe even
> go so far as to run a web server hosting those feeds until
> such time as a more official feed is available.

It’s very much what I have in mind as well.

We should think one step further than the tagging and figure a solution for maintaining and hosting GTFS files in case the PT organization doesn’t publish one. If we can resolve the issue of hosting the files, it will encourage OSM contributors to think more towards contributing to a web of data and less into “forcing” whatever geo-related data in OSM database.

And hosting these files doesn’t need to be complex. For example, certain JOSM plug-in’s have their configuration hosted in the wiki: https://josm.openstreetmap.de/wiki/Presets#JOSMwikiAvailablepresetpreferredmethod. So, we maybe already have the solution (with the OSM wiki, not the JOSM wiki).

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

Re: Public Transport Timetables

OSMDoudou
In reply to this post by OSMDoudou
(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:30, OSMDoudou <[hidden email]> wrote:

Just a quick web search, but it appears there exist GTFS editors and there is an entire ecosystem around creating and hosting GFTS files. Here is one editor, for example: https://conveyal-data-tools.readthedocs.io/en/latest.

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

Re: Public Transport Timetables

Paul Allen
In reply to this post by OSMDoudou
On Wed, Nov 7, 2018 at 11:20 PM OSMDoudou <[hidden email]> wrote:

We should think one step further than the tagging and figure a solution for maintaining and hosting GTFS files in case the PT organization doesn’t publish one. If we can resolve the issue of hosting the files, it will encourage OSM contributors to think more towards contributing to a web of data and less into “forcing” whatever geo-related data in OSM database.

Even if you can make it fit, it's not necessarily a good idea to do it.  I'm thinking of the Hoover Dustette.

And hosting these files doesn’t need to be complex. For example, certain JOSM plug-in’s have their configuration hosted in the wiki: https://josm.openstreetmap.de/wiki/Presets#JOSMwikiAvailablepresetpreferredmethod. So, we maybe already have the solution (with the OSM wiki, not the JOSM wiki).

Having done precisely no research into the matter whatsoever, I'm not sure that a wiki would be the
optimal architecture for this if we ended up with many GTFS feeds that were interrogated frequently.
The wiki architecture isn't necessarily optimized for that use-case.  But it's probably adequate
for testing the concept.

--
Paul


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

Re: Public Transport Timetables

Paul Allen
In reply to this post by OSMDoudou
On Wed, Nov 7, 2018 at 11:31 PM OSMDoudou <[hidden email]> wrote:

Just a quick web search, but it appears there exist GTFS editors and there is an entire ecosystem around creating and hosting GFTS files.

One thought just occurred to me.  It looks like whatever tag we come up with will have a URL as
its value, since GTFS files seem to be (mostly) available over HTTP.  I have local routes which are
subsidized by the County Council (almost no routes around here would be commercially viable
without the subsidy, but it's a large, rural county so buses are needed).  Some of those routes
have more than one operator.  Each might publish its own GTFS feed for only its own vehicles on
that route (one of the operators has done it with timetables which show only its own buses on
a shared route).  Given that the values would be arbitrary URLs, the semi-colon would be unsafe
to use as a separator.  So we'd have to come up with something like gtfs:big_yellow_bus_co=*.
or route:gtfs:etc.  Same thing if we want to add URLs to the operator's human-readable timetable.

--
Paul



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