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 <djakk.dj...@gmail.com
<mailto:djakk.dj...@gmail.com>>:
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 <winfi...@gmail.com
<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
<djakk.dj...@gmail.com <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 <winfi...@gmail.com
<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
<djakk.dj...@gmail.com <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
<djakk.dj...@gmail.com
<mailto:djakk.dj...@gmail.com>> 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
<djakk.dj...@gmail.com
<mailto:djakk.dj...@gmail.com>> 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
<winfi...@gmail.com
<mailto:winfi...@gmail.com>> 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
<mailto: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 <djakk.dj...@gmail.com
<mailto:djakk.dj...@gmail.com>> 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
<djakk.dj...@gmail.com
<mailto:djakk.dj...@gmail.com>>
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
<winfi...@gmail.com
<mailto:winfi...@gmail.com>>
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
<mailto: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"="<amount
of time between
arrival and
departure at this
platform>" tag
instead of
separate
arrivals/departures
tags?
Thanks,
Leif Rasmussen
_______________________________________________
Tagging mailing list
tagg...@openstreetmap.org
<mailto:tagg...@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
tagg...@openstreetmap.org
<mailto:tagg...@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
