Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Thu, Nov 8, 2018 at 5:07 PM Leif Rasmussen <354...@gmail.com> wrote:

> Integrating GTFS seems like a much better idea than adding actual
> schedules to OpenStreetMap.  I had not considered this previously because I
> did not understand how GTFS is used worldwide.  Perhaps it would be
> possible to start something like a new gtfs.openstreetmap.org (which
> would be similar to transit.land and transitfeeds.com, but with a focus
> of OpenStreetMap integration) for hosting GTFS feeds that could be
> integrated into OSM.  That would allow for much easier integration and
> maintenance.
>

Easier still would be to use existing feeds.  The only copyright issue
involved iswhether or not those
feeds permit "deep linking" and I think most do.

Copying what Google has done successfully seems like a better option than
> creating a big, out of date mess.
>

Google has put a lot of thought into it.  It's possible, of course, that
the current GTFS now evolved from
more primitive beginnings and has a few things that might be bettter if
starting from scratch.
Nevertheless, it seems like a workable system and, more importantly, it's
already in use and some
organizations use it to make their route information public.  I don't think
that wheel needs to be
re-invented.

I think that creating a new GTFS server would be better than using transit
> land or transitfeeds.com, because OSM would have full control over what
> happened to the servers and which licencing was used.
>

I think that anything other than full mirroring, in the same way the OSM
database is mirrored by other
tile providers, would be a mistake.  And even full mirroring would be
unnecessary for this usage.  I
see an OSM GTFS server, if it comes into existence, as a way for mappers to
create GTFS feeds
for routes that don't currently have them.  And, if we're able to use
something like transitland or
transitfeeds for that purpose, we don't even need an OSM server (unless we
don't trust their data
or trust them to stay in existence, for some reason).

-- 
Paul
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

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  a
écrit :

>
>
> sent from a phone
>
> > On 6. Nov 2018, at 15:41, djakk djakk  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
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Thu, Nov 8, 2018 at 12:07 AM OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

> > Even if you can make it fit, it's not necessarily a good idea to do it.
> > I'm thinking of the Hoover Dustette.
>
> Excuse my ignorance. You’re thinking to what ?
>

The Hoover Dustette was a cylinder vacuum cleaner.  The impeller had no
protective guard since
it was set so far inside the machine that the British Standard Finger (yes,
there is such a thing)
could not reach it and therefore it was not a danger.  Not a danger until
somebody found himself
sexually attracted to something that was warm, throbbed and sucked.  It
didn't end well for him.
Nor for the others that tried the same thing.  The excuses they came up
with for how they had their
"accident" were amusing.  Moral which applies to this thread: even if you
can make it fit, it may not
be a good idea to do so.

> 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.
>
> Problem solved already, it seems: http://transitfeeds.com.
>

 Looks good, apart from their problem loading Google Maps.  If only there
were some other map
they could use instead. :)

I think that, unless there are serious flaws with GTFS, we should figure
out a way to tag it.  Another
problem I thought of is whether it should go on individual stops or route
relations.  Simplicity and
data integrity says on route relations.  The ability for an ordinary user
to use the query tool on the
standard map to find which buses stop at a certain stop and at what times
says on bus/train stops.

-- 
Paul
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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  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:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> 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
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> --
> Jono
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jonathon Rossi]

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  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:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> 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
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Jono
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Hello !

Ok for a google hangout ! I’m also available tonight and on Friday evening.

Julien « djakk »


Le mer. 7 nov. 2018 à 12:53, Jo  a écrit :

> Hi Tony,
>
> Could you also have a look at the proposal I created?
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> At the moment I'm looking into how to represent that in meaningful ways
> using MapCSS in JOSM, but I don't think that makes too much sense.
>
> For your use case where you want to do routing. The timetable relations
> give the possibility to calculate when a bus passes at a particular stop at
> a given time of day. And it's possible to see how long it takes to get from
> there to another stop or calculate at what time one arrives there. For
> complex routing involving transfers this will involve quite a bit of
> recursion, but it should be feasible.
>
> At the moment I'm looking how this can be rendered in meaningful ways and
> how data entry can be made as convenient as possible. (I think we need
> spreadsheet like functionality to accomplish that, I made an attempt here:
> https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
> .
> But we need more possibilities for indicating where a specific time on the
> schedule came from.
>
> Right now I have the following:
>
> Line (route_master relation)
>contains several:
>  Itineraries composes of (longest) stop sequences including ways
> (route relation)
> if referred to by 1 or more
>Actual stop sequences with time deltas (timetable relation)
>The stops in these relations are always a subset of the
> referre route relation
>
> I would also include a public_holidays relation in each route_master
> relation to avoid duplication but still enable which days get Sunday
> schedules and which days are in school holiday periods.
>
>
> If anyone feels like doing a Google Hangout to discuss this, let me know.
> I have time tonight and Friday evening
>
> Polyglot
>
> Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :
>
>> Hi
>>
>> I have worked in data analysis for many years, recently become interested
>> in PT and added routes to my locality. I look at PT timetables frequently
>> as much of my travel is by PT.
>>
>> My use case is that I want to find times and routes from A to B, I do not
>> know the route numbers or their actual route. I expect the system to be
>> able to give times and routes and any interchanges.
>>
>> As a system I fail to see how putting the timing detail on each stop will
>> enable me to efficiently perform that use case. From what is described
>> system would have to identify route, then iterate route to check if
>> destination is on route, if on route then  select time entry in A then a
>> time entry in B and ASSUME that they both relate to the same journey and
>> have been updated correctly. For connections/interchanges the same rules
>> apply. Those assumptions make storing the data against a stop
>> extraordinarily unreliable, the proposed method does not take shortened
>> journeys - eg school or factory journeys where the whole route is not
>> travelled  - into account.
>>
>> I suggest that the best way to get timetable data is to replicate the
>> present system that most PT organisations do - a table related to the
>> route. A timetable could be associated with an OSM route. A system will be
>> required to generate meaningful times and itineraries, so should we be
>> asking those existing OSM routing people what  is their preferred way to
>> store timetable data that can be updated reliably.
>>
>> Here in the UK timetable data is in the public domain - is that the case
>> in other places?
>>
>> TonyS
>>
>>
>>
>> On 06/11/2018 19:59, Jo wrote:
>>
>> 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 :
>>
>>> 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  a écrit :
>>>
 Yes, 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Wed, Nov 7, 2018 at 5:08 PM Jo  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
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Tony Shield]

Hi

I have worked in data analysis for many years, recently become 
interested in PT and added routes to my locality. I look at PT 
timetables frequently as much of my travel is by PT.


My use case is that I want to find times and routes from A to B, I do 
not know the route numbers or their actual route. I expect the system to 
be able to give times and routes and any interchanges.


As a system I fail to see how putting the timing detail on each stop 
will enable me to efficiently perform that use case. From what is 
described system would have to identify route, then iterate route to 
check if destination is on route, if on route then  select time entry in 
A then a time entry in B and ASSUME that they both relate to the same 
journey and have been updated correctly. For connections/interchanges 
the same rules apply. Those assumptions make storing the data against a 
stop extraordinarily unreliable, the proposed method does not take 
shortened journeys - eg school or factory journeys where the whole route 
is not travelled  - into account.


I suggest that the best way to get timetable data is to replicate the 
present system that most PT organisations do - a table related to the 
route. A timetable could be associated with an OSM route. A system will 
be required to generate meaningful times and itineraries, so should we 
be asking those existing OSM routing people what  is their preferred way 
to store timetable data that can be updated reliably.


Here in the UK timetable data is in the public domain - is that the case 
in other places?


TonyS



On 06/11/2018 19:59, Jo wrote:
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 >:


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 mailto:winfi...@gmail.com>> 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
mailto:djakk.dj...@gmail.com>>:

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 mailto:winfi...@gmail.com>> 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
mailto:djakk.dj...@gmail.com>>:

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

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk
mailto:djakk.dj...@gmail.com>> a écrit :

I think it is important to have an osm object
  

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Hi Tony,

Could you also have a look at the proposal I created?

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

At the moment I'm looking into how to represent that in meaningful ways
using MapCSS in JOSM, but I don't think that makes too much sense.

For your use case where you want to do routing. The timetable relations
give the possibility to calculate when a bus passes at a particular stop at
a given time of day. And it's possible to see how long it takes to get from
there to another stop or calculate at what time one arrives there. For
complex routing involving transfers this will involve quite a bit of
recursion, but it should be feasible.

At the moment I'm looking how this can be rendered in meaningful ways and
how data entry can be made as convenient as possible. (I think we need
spreadsheet like functionality to accomplish that, I made an attempt here:
https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
.
But we need more possibilities for indicating where a specific time on the
schedule came from.

Right now I have the following:

Line (route_master relation)
   contains several:
 Itineraries composes of (longest) stop sequences including ways (route
relation)
if referred to by 1 or more
   Actual stop sequences with time deltas (timetable relation)
   The stops in these relations are always a subset of the
referre route relation

I would also include a public_holidays relation in each route_master
relation to avoid duplication but still enable which days get Sunday
schedules and which days are in school holiday periods.


If anyone feels like doing a Google Hangout to discuss this, let me know. I
have time tonight and Friday evening

Polyglot

Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :

> Hi
>
> I have worked in data analysis for many years, recently become interested
> in PT and added routes to my locality. I look at PT timetables frequently
> as much of my travel is by PT.
>
> My use case is that I want to find times and routes from A to B, I do not
> know the route numbers or their actual route. I expect the system to be
> able to give times and routes and any interchanges.
>
> As a system I fail to see how putting the timing detail on each stop will
> enable me to efficiently perform that use case. From what is described
> system would have to identify route, then iterate route to check if
> destination is on route, if on route then  select time entry in A then a
> time entry in B and ASSUME that they both relate to the same journey and
> have been updated correctly. For connections/interchanges the same rules
> apply. Those assumptions make storing the data against a stop
> extraordinarily unreliable, the proposed method does not take shortened
> journeys - eg school or factory journeys where the whole route is not
> travelled  - into account.
>
> I suggest that the best way to get timetable data is to replicate the
> present system that most PT organisations do - a table related to the
> route. A timetable could be associated with an OSM route. A system will be
> required to generate meaningful times and itineraries, so should we be
> asking those existing OSM routing people what  is their preferred way to
> store timetable data that can be updated reliably.
>
> Here in the UK timetable data is in the public domain - is that the case
> in other places?
>
> TonyS
>
>
>
> On 06/11/2018 19:59, Jo wrote:
>
> 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 :
>
>> 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  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
>>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

:)

Le mar. 6 nov. 2018 à 20:55, Yves  a écrit :

> Are you looking for a general transit feed specification?
> :)
>
> Yves
>
> Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk 
> 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  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 :
>>>
 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  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  >:
>
>> In which case a timetable per stop and per route is unmaintable ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 <
> djakk.dj...@gmail.com>:
>
>> 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 
>> a écrit :
>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Yves]

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

Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk  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  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
>:
>>
>>> 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  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
>:

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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 
>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  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 <
 djakk.dj...@gmail.com>:

> 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
> 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 »
>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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 :
>
>> 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  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 :
>>>
 In which case a timetable per stop and per route is unmaintable ?

 Julien “djakk”


 Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 <
>>> djakk.dj...@gmail.com>:
>>>
 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  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 
> a écrit :
>
>> Martin, maybe locals do know their bus stop timetable, as they
>> always use the service they may memorize the schedules ... ?
>>
>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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 :
>
>> 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  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  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  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:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> 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 <354...@gmail.com>:
>
>> 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"="> at this platform>" tag instead of separate arrivals/departures tags?
>>
>> Thanks,
>> Leif Rasmussen
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Talk-transit mailing list
Talk-transit@openstreetmap.org

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

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

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 :
>>>
 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  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  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  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:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>
>>> 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 <354...@gmail.com
>>> >:
>>>
 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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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 :
>
>> In which case a timetable per stop and per route is unmaintable ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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  >:
>
>> 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  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  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  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:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> 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 <
> 354...@gmail.com>:
>
>> 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 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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  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 :
>>
>>> 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  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  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  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:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> 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 <354...@gmail.com>:
>>
>>> 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"=">> departure at this platform>" tag instead of separate arrivals/departures
>>> tags?
>>>
>>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> 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 <354...@gmail.com>:
>
>> 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"="> this platform>" tag instead of separate arrivals/departures tags?
>>
>> Thanks,
>> Leif Rasmussen
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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  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  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  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:

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

 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 <354...@gmail.com>:

> 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"=" at this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
 ___
 Tagging mailing list
 tagg...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

>>>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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  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:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> 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 <354...@gmail.com>:
>>
>>> 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"=">> this platform>" tag instead of separate arrivals/departures tags?
>>>
>>> Thanks,
>>> Leif Rasmussen
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk 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  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  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  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:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>
>>> 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 <354...@gmail.com>:
>>>
 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"=">>> at this platform>" tag instead of separate arrivals/departures tags?

 Thanks,
 Leif Rasmussen
 ___
 Tagging mailing list
 tagg...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

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

Excuse my ignorance. You’re thinking to what ?

> 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.

Problem solved already, it seems: http://transitfeeds.com.___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:30, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> 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.___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:18, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> 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).___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Kevin Arutyunyan]

Hello,

it would be good to have this generalised kind of information for
routes.
https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport
may be related.

We should not keep thinking about this "2nd version" though. It is
probably impossible to add this data to OSM in a maintainable way. It
will probably not be correct, and there are so many things to keep in
mind for a timetable that I just can't see it ever happening in OSM.
Applications don't want data with these properties (also described
below), they want to use something like GTFS data. (LeifRasmussen wrote
"Schedule data in OpenStreetMap would allow for applications such as
OsmAnd and Maps.me to create public transport based routing services
that would be useful to users.").
It is good to add traceable identifiers to OSM (like ref:IFOPT), so it
can be linked with timetable datasets.

I mapped most stops and routes (including probably all variants;
including lines with only one trip per day or less) in my city, and that
was a lot of work. Having the route variants is one of the first
requirements to fulfill before thinking about adding exact schedule
data, and I don't see that happening, even in larger cities for example
here in Germany (route variants other than the usually two or a few more
main ones are rarely mapped, many users don't see the benefit in them).
Look at the number of relations here:
https://wiki.openstreetmap.org/wiki/HST
And that's just one of the highest layers in timetable data.

On https://de.wikipedia.org/wiki/Benutzer:D3d9/Linien_HST I
automatically generate a table (see 1.1.1 -> Linien, collapsible) using
open data. The table on that page is not fully usable on its own, as the
actual stops/platforms a variants trips stop at, the times between
stops, and exact calendar dates are missing; but it is a good way to see
how many things you have to go through until you get from a line/its
variants/its stops to the actual time a trip departs.
A line has multiple variants (every used "sequence of platforms"),
a line+variant has multiple timing groups (sequence of times between
stops),
a line+variant+timinggroup can have multiple restrictions (calendar
dates, and it's more than just one list of weekdays with a few
exceptions),
a line+variant+timinggroup+restriction has (or at least it looks like it
has (in this dataset it doesn't seem to matter, especially when showing
it this way)) specific weekdays/"daytypes",
and finally, you get to the initial departure times for just that
specific combination.

Of course this is just one way to save/display/interpret this data
(based on the german DINO format), however it won't be simple and
efficient in any case if you want to have it complete and correct
(=usable, see next sentence and last paragraph).
If a dataset doesn't contain all of this required (to have a fully
correct dataset which can be reliably used for passenger information)
data, no application will ever use it.
It also needs to be updated very often, more than one might expect. The
wiki table is made using static data (released weekly) and this
operator, like others, updates their static data continuously to account
for things like temporary detours or special events, which is very good
for data consumers.

I don't believe that OSM will ever continuously [in a specific area, of
course not even speaking about large areas] contain data that is so
complete, correct, and up to date that it can be used by applications
for passenger information (for detailed things like trip planning,
departure lists, ...), so I don't see any reason why we should even try
to go in the direction of the "2nd version"; that data (something
inbetween generalised/describing data and the really complete accurate
timetable) will just not be usable, so we should just think about a good
(and usable everywhere on the world) way to define more general
information about trips.

d3d9



On 2018-11-07 20:40, Tony Shield wrote:
> Hi
> 
> I like the approximation idea as part of the route relations. I think
> that moving to typical examples and making sure that the proposal
> works will be good. In these examples I am reflecting some of the
> services in my local area which I think is easily usable for all my
> local services - clearly others may have different patterns. I think
> that adding peak services may be too much. Detailed timings will need
> to be researched from other sources.
> 
> Ex1 - Mo-Sa 0530 - 1900 6 per hour, 1900 - 2330 2 per hour; Su
> 0600-2300 2 per hour
> 
> Ex2 - Mo-Fr 2 per day outbound and 3 per day on the return.
> 
> Ex3 - Tu, Th 1 per day
> 
> Having a 2nd version with much more detail makes a lot of sense. I
> think it is not too urgent as its a large amount of work and data to
> prepare, it must be correct so as to allow routing and timetable apps
> to use the data - I think that this much data is not human-readable.
> I too have doubts about creation and maintainability of this version
> and 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

(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
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Great to hear that. when I get back home I'll further elaborate on the
spreadsheet idea. Now with a full timetable for one general direction of
travel

On Wed, Nov 7, 2018, 13:59 Tony Shield  Hi Jo
>
> I've looked at your proposal and I'm starting to understand it and like it.
>
> I looked at your spreadsheet and this is the style of data entry which I
> think will work, using a spreadsheet then processing it to OSM data
> formats. If we use a spreadsheet then why not put the whole timetable in
> there and then process it. In that case short journeys are allowed
> wherever they start and end, not having to calculate journey time and
> apply to a stop is easier and allows direct look up of departures from
> the stop - as Leif originally wanted, spreadsheet processing then allows
> for peak hour times; and the source and style of the data matches that
> in OSM - so traceability is resolved.
>
> Using the route_master to hold the timetable is good.
>
> Can't help with MapCSS - I don't know how it fits in.
>
> Sorry - busy tonight and Friday so can't talk.
>
> Regards
>
> Tony
>
>
>
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Tony Shield]

Hi Jo

I've looked at your proposal and I'm starting to understand it and like it.

I looked at your spreadsheet and this is the style of data entry which I 
think will work, using a spreadsheet then processing it to OSM data 
formats. If we use a spreadsheet then why not put the whole timetable in 
there and then process it. In that case short journeys are allowed 
wherever they start and end, not having to calculate journey time and 
apply to a stop is easier and allows direct look up of departures from 
the stop - as Leif originally wanted, spreadsheet processing then allows 
for peak hour times; and the source and style of the data matches that 
in OSM - so traceability is resolved.


Using the route_master to hold the timetable is good.

Can't help with MapCSS - I don't know how it fits in.

Sorry - busy tonight and Friday so can't talk.

Regards

Tony





___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Hi Tony,

Could you also have a look at the proposal I created?

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

At the moment I'm looking into how to represent that in meaningful ways
using MapCSS in JOSM, but I don't think that makes too much sense.

For your use case where you want to do routing. The timetable relations
give the possibility to calculate when a bus passes at a particular stop at
a given time of day. And it's possible to see how long it takes to get from
there to another stop or calculate at what time one arrives there. For
complex routing involving transfers this will involve quite a bit of
recursion, but it should be feasible.

At the moment I'm looking how this can be rendered in meaningful ways and
how data entry can be made as convenient as possible. (I think we need
spreadsheet like functionality to accomplish that, I made an attempt here:
https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
 .
But we need more possibilities for indicating where a specific time on the
schedule came from.

Right now I have the following:

Line (route_master relation)
   contains several:
 Itineraries composes of (longest) stop sequences including ways (route
relation)
if referred to by 1 or more
   Actual stop sequences with time deltas (timetable relation)
   The stops in these relations are always a subset of the
referre route relation

I would also include a public_holidays relation in each route_master
relation to avoid duplication but still enable which days get Sunday
schedules and which days are in school holiday periods.


If anyone feels like doing a Google Hangout to discuss this, let me know. I
have time tonight and Friday evening

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

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 :

> 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  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 :
>>
>>> 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  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 :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 <
 djakk.dj...@gmail.com>:

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

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 :

> 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  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 :
>>
>>> In which case a timetable per stop and per route is unmaintable ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 > >:
>>
>>> 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  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  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  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.

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

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 :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  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  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  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 :

> 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  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  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  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:

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

 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 <354...@gmail.com
 >:

> 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.
>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

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:
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

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 <354...@gmail.com>:

> 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"=" this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit