Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

maybe we can use some keys like eta_link:shortnameofbuscompanyA=*
and eta_link:shortnameofbuscompanyB=* to show different operators
information

在 2019年3月13日週三 15:01，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:
>
>> but in term of GTFS I don't think anyone in the world supply data
>> individually for each stops.
>>
>
> Of course!
>
> It would be nice (but probably impossible) to have a single worldwide
> answer but I don't think that will be possible in the foreseeable future :-(
>
> I think it will finish up that we can list this info in this area, people
> can do so there, there & there, but people in those other areas
> unfortunately won't be able to.
>
> I'd say just go with what we can now, & as areas expand, they can all join
> in.
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:

> but in term of GTFS I don't think anyone in the world supply data
> individually for each stops.
>

Of course!

It would be nice (but probably impossible) to have a single worldwide
answer but I don't think that will be possible in the foreseeable future :-(

I think it will finish up that we can list this info in this area, people
can do so there, there & there, but people in those other areas
unfortunately won't be able to.

I'd say just go with what we can now, & as areas expand, they can all join
in.

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

There are processed data for each stop, but in term of GTFS I don't think
anyone in the world supply data individually for each stops. My
understanding is that each GTFS file usually cover a line or a network.

在 2019年3月13日週三 10:32，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 11:18, Andrew Davidson  wrote:
>
>> However, you may want to include the feed_id every
>> time to make it easier to search for stops. Also do we want to repeat
>> the same information at every stop or should we store it in a single
>> relation?
>>
>
> Unless I've misunderstood the question / problem (which is quite possible
> :-)), how about both?
>
> Stop info on each stop eg
> https://jp.translink.com.au/plan-your-journey/stops/300699
>
> & route info on the relation eg
> https://jp.translink.com.au/plan-your-journey/timetables/bus/t/756/north/2019-03-13
>
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

For the coordinated schedule, as an example there is a route that departure
at the following time:
08:00, 08:00, 08:03, 08:06, 08:09, 08:12, 08:15, 08:18, 08:22, 08:25,
08:29, 08:33, 08:38, 08:38, 08:38, 08:41, 08:44, 08:47, 08:51, 08:54,
08:57, 09:01, 09:05, 09:09, 09:13, and of these departures, 08:00-08:15
departures are operated by operator A, 08:18-08:33 departures operated by
operator B, 08:38-08:54 departures operated by operator A, and then
08:57-09:13 departures are operated by operator B.

I would say if you map them as multiple relationship then end users would
have no idea which relationship is the one they want. It's also
unnecessarily increasing the number of route variants that need to be
maintained by the order of magnitude of hundreds.

在 2019年3月7日週四 22:17，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 7. Mar 2019, at 15:02, Phake Nick  wrote:
> >
> > The route us currently operated by two different operators on
> coordinated timetable and each operator have their own ETA system. While
> they do not provide a GTFS feed for now, it can be expected that each of
> them will provide their own feed if they would like to do so in the future.
> However it doesn't make sense to have multiple relationship for them as
> they run on exact same route with exact same route number and run on a
> coordinated schedule
>
>
> IMHO it could make sense to have multiple relations, we will also have
> multiple GTFS urls in this case. There are route master relations which can
> group route variants and could be used here as well. A coordinated schedule
> means they have completely different schedules, right? (although the
> customers might not care).
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 11:18, Andrew Davidson  wrote:

> However, you may want to include the feed_id every
> time to make it easier to search for stops. Also do we want to repeat
> the same information at every stop or should we store it in a single
> relation?
>

Unless I've misunderstood the question / problem (which is quite possible
:-)), how about both?

Stop info on each stop eg
https://jp.translink.com.au/plan-your-journey/stops/300699

& route info on the relation eg
https://jp.translink.com.au/plan-your-journey/timetables/bus/t/756/north/2019-03-13


Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Andrew Davidson]

On 2/3/19 10:02 am, Leif Rasmussen wrote:
> It seems like the best way forward now is for a proposal allowing 
OpenStreetMap data to be tightly integrated with outside sources (such 
as GTFS) to be created by someone.  This would avoid the issues of 
maintainability in OpenStreetMap.


I'm not interested in producing route maps or attempting to route over 
public transport without the aid of external data, so my requirements 
may not meet all of yours.


What I'd like to be able to do in OSM is:

1. Tag the most appropriate OSM object with the stop_id from a GTFS feed.
2. Have some way of tagging which GTFS feed this is from.
3. Handle the case where a stop appears in more than one GTFS feed.

So I see something along the lines of:

=
=

I noticed that someone else mentioned that the same stop can appear in a 
GTFS feed with different stop_ids. This would look like this:


=;
=

If a stop appears in more than one feed then some how we have to map the 
stop_id to the feed. One possible way would be:


:=
:=
.
.
:=the GTFS feed that stop_id_1 comes from>
:=the GTFS feed that stop_id_2 comes from>

.
.

As you can see there are quite a few design question left to be 
answered. For example, the feed_id is only needed if a stop appears in 
more than one feed. However, you may want to include the feed_id every 
time to make it easier to search for stops. Also do we want to repeat 
the same information at every stop or should we store it in a single 
relation?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 7. Mar 2019, at 15:02, Phake Nick  wrote:
> 
> The route us currently operated by two different operators on coordinated 
> timetable and each operator have their own ETA system. While they do not 
> provide a GTFS feed for now, it can be expected that each of them will 
> provide their own feed if they would like to do so in the future. However it 
> doesn't make sense to have multiple relationship for them as they run on 
> exact same route with exact same route number and run on a coordinated 
> schedule


IMHO it could make sense to have multiple relations, we will also have multiple 
GTFS urls in this case. There are route master relations which can group route 
variants and could be used here as well. A coordinated schedule means they have 
completely different schedules, right? (although the customers might not care).

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 7. Mar 2019, at 13:06, Paul Allen  wrote:
> 
> It's just that at one time the bus will have the
> livery of "Foo Brothers" and at another time it will have the livery of "Bar 
> Buses."  They're not variant
> routes but variant operators.


the basic options are different routes for each operator, or several operators 
within the same relation (if really all other info is the same, I would 
probably go for the multiple values operator tag).

It is a bit of an edge case, imagine the companies started operating the route 
in a different year, according to what you consider “the route” (route number, 
stops, operator, etc. you might use a different start_date=* for them and will 
require different relations, or if you see the route independently from the 
operator you would have only one start date.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

Nope. For example: https://www.openstreetmap.org/relation/3352395 The route
us currently operated by two different operators on coordinated timetable
and each operator have their own ETA system. While they do not provide a
GTFS feed for now, it can be expected that each of them will provide their
own feed if they would like to do so in the future. However it doesn't make
sense to have multiple relationship for them as they run on exact same
route with exact same route number and run on a coordinated schedule.

在 2019年3月7日週四 14:33，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> >
> > Routes do exist with more than one operator.
>
>
> wouldn’t these simply be tagged as several relations?
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Thu, 7 Mar 2019 at 06:33, Martin Koppenhoefer 
wrote:

>
> > On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> >
> > Routes do exist with more than one operator.
>
> wouldn’t these simply be tagged as several relations?
>

I don't know.  It's the same route, with the same service number, the same
destination on the
bus destination board, the same stops.  It's just that at one time the bus
will have the
livery of "Foo Brothers" and at another time it will have the livery of
"Bar Buses."  They're not variant
routes but variant operators.  I hadn't considered the possibility of
treating them as variant routes
and am not sure if that would be considered valid (or sensible).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> 
> Routes do exist with more than one operator. 


wouldn’t these simply be tagged as several relations? 


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski  wrote:

>
> Again, frankly - approximately zero general-purpose apps will support
> whatever scheme we could come up with in OpenStreetMap to tag the
> situation "this stop is served by a route that has two separate
> timetables that are both valid, and is also served by another route,
> and here are the links to PDFs of these three timetables".


If we don't come up with a sensible tagging scheme we can guarantee that no
app
will support it.

Yes, url=* would work for a timetable.  But what if we also want to link to
GTFS?  What if a user
clicks on a url=* expecting a timetable and gets a GTFS?  Let's make it
user- and app-friendly,
not user- and app-unfriendly.  It costs us nothing to have specific keys
for these things (except
the time spent arguing here) and has no downside; going with url=* and
finding out later
that it was a bad idea would cause problems.

Routes do exist with more than one operator.  They've happened around here
in the past when
the county council wanted to split subsidized routes between two
operators.  I also encountered
such routes between a large town and a city when both population centres
had town/city
councils who ran their own bus services, on the route between the two
localities.  I encountered
it in a large city after government deregulation meant that a national
operator and the city's own
bus service competed on some routes to nearby commuter villages.

So even if we restrict this to routes and don't put it on stops, we need to
handle the case where two
(or more) operators put up partial timetables or partial GTFS data.  This
isn't an edge case, it's
what happens.  Again, the cost of dealing with it now (even if it's rarely
needed) is minimal; the
cost of changing it later (if we find it's not a rare thing) will not be.
Bad tagging decisions never
die, and they rarely fade away.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

On Tue, 5 Mar 2019 at 13:35, Paul Allen  wrote:
> But I'd prefer we have specific keys for
> timetables and GTFS data rather than rely upon either of those.  Much better 
> to make things clear
> with timetable=* and gtfs=* (except we have to deal with partial 
> timetables/feeds from operators
> who both run the same route, so we'll need something fancier than that).

Again, frankly - approximately zero general-purpose apps will support
whatever scheme we could come up with in OpenStreetMap to tag the
situation "this stop is served by a route that has two separate
timetables that are both valid, and is also served by another route,
and here are the links to PDFs of these three timetables". So for
these edge cases skip a long discussion, be bold, and just go with
whatever seems to make some sense. And use the time saved to create a
GTFS file instead :)

+1 on the rest of your message.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 17:37, Jarek Piórkowski  wrote:

>
> If your use case is people using the query tool on
> https://openstreetmap.org to follow links to PDFs to plan a journey,
>

Might be a PDF or a simple web page or a Web 2.0 page with funky effects
and even live
updates.  Sadly, given the stupidity of the operators around here, the URL
changes every
time the timetable is updated.

then whatever tagging specification you use doesn't really matter as
> long as it's understandable to the people viewing it - a link looks
> like a link so that's quite easy.


Yes, humans will be OK with whatever key is used as long as the query tool
turns
values that look like URLs into links (which is what it appears to do).
However, it's
nice if we have something consistent and distinct from either website=* or
url=*
which may have other application for the route (or stop, if we add this
information to
stops).  It's always better to make it clear what a link is for than rely
on "that's
a link to something, perhaps it's a timetable."  Especially if we want to
be able
to link to both timetables (for humans) and GTFS data (for apps).

For that matter, for the 10-trips-a-day routes, if you're willing to put in
> the manual

effort, you can probably put the departures into a "departures" tag on the
> stop and it'll be useful when someone queries the stop - the proposal
> got rejected so it's not official guidance, but it doesn't have to be
> official for you to add it and for people to view it.
>

It's not useful on many routes.  Like ones where there's a different
timetable for Saturdays,
no service on Sundays, and one or two of the departures change on school
holidays.  Here
are the codes applying to the T5 route near me:

Sch   Schooldays only
FSVia Fishguard High School on schooldays
S+H Saturday and school holidays only
A  Via Pembrokeshire College on college days
S  Via Aberaeron School on schooldays
SAT  Operates Saturdays only
Col  Connects with College buses
L  Via Llanbadarn Road
HS   Drops off High Street, doesn't drop off at Bus Station
LCVia Llanbadarn Campus, Aberystwyth
X50  Journey destination shows X50, not T5.
T1Change onto T1 service at Aberaeron
FHConnection at Fishguard Square for 410 Fishguard Harbour
FSVia Fishguard School [is this different from the FS above?]
C  Timed to meet with T1 at Aberaeron
cb Connection with Cardi Bach

Actually, it's a little more complex than that. There are other annotations
too.
https://www.richardsbros.co.uk/wp-content/uploads/2018/10/T5-October-2018.pdf

General-purpose transit apps need a machine-readable data format and
> for better or worse, GTFS is the least bad and by far most widespread
> one we've got. Everything else is proprietary, horrible to work with
> (XML SOAP and the like), or both. I know that NaPTAN data got imported
> in some regions of London a good couple of years back, but I really
> draw your attention to the "last modified 2013" in the DfT page you've
> linked - GTFS won and the world has moved on, even Germans are
> starting to publish transit open data as GTFS now.
>

I'm glad GTFS won.  That means we can ignore the NaPTAN stuff.

Where we don't have GTFS, but want to have machine-readable and
> widely-machine-understood timetables for public transit systems,
> building a GTFS file seems a far better option than inventing yet
> another standard within OSM.
>

That seems the best option to me.  It's the primary reason I voted down the
departures
proposal.  There are even sites that give you tools to do that and host it
for you.  Much better
than trying to shoehorn all that into an OSM value.

> I'd use website=* for domains like www.foo.com but url=* for a specific
> page within a website.
>
> I'm not familiar with tagging guidance that suggests this,



>From https://wiki.openstreetmap.org/wiki/Key:url

This tag is being used for very different types of content - official
websites of an amenity or its operator, third-party pages, the object's
Wikipedia entry, photographs featuring the object, or even documentation on
the OSM wiki. So it is advised not to use this tag when more specific
alternatives are available such as website...

So if there's a whole website about an object I use website=* but if it's a
single page within a website
I use url=*.  It's not mandatory (nothing is) but it's what I do.  But I'd
prefer we have specific keys for
timetables and GTFS data rather than rely upon either of those.  Much
better to make things clear
with timetable=* and gtfs=* (except we have to deal with partial
timetables/feeds from operators
who both run the same route, so we'll need something fancier than that).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

Paul,

If your use case is people using the query tool on
https://openstreetmap.org to follow links to PDFs to plan a journey,
then whatever tagging specification you use doesn't really matter as
long as it's understandable to the people viewing it - a link looks
like a link so that's quite easy. For that matter, for the
10-trips-a-day routes, if you're willing to put in the manual effort,
you can probably put the departures into a "departures" tag on the
stop and it'll be useful when someone queries the stop - the proposal
got rejected so it's not official guidance, but it doesn't have to be
official for you to add it and for people to view it.

But that will never be consumed by transit apps not specialized to a
given area, so the benefit of worldwide standardization is very very
slim.

General-purpose transit apps need a machine-readable data format and
for better or worse, GTFS is the least bad and by far most widespread
one we've got. Everything else is proprietary, horrible to work with
(XML SOAP and the like), or both. I know that NaPTAN data got imported
in some regions of London a good couple of years back, but I really
draw your attention to the "last modified 2013" in the DfT page you've
linked - GTFS won and the world has moved on, even Germans are
starting to publish transit open data as GTFS now.

Where we don't have GTFS, but want to have machine-readable and
widely-machine-understood timetables for public transit systems,
building a GTFS file seems a far better option than inventing yet
another standard within OSM.

> I'd use website=* for domains like www.foo.com but url=* for a specific page 
> within a website.

I'm not familiar with tagging guidance that suggests this, though
everyone may tag as they like, and in the end the tagging doesn't
really matter as any tags on stops that give URLs to HTML or PDF
timetables or departures will not be used by general-purpose transit
apps.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski  wrote:

>
> On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> > As I said, I'd prefer not to use url=* because it could be for anything
> - a page about the history of
> > the bus stop (maybe the shelter is a listed building),
>
> That would rather be website=* though.


Not necessarily.  I'd use website=* for domains like www.foo.com but url=*
for a specific page
within a website.

And to keep it simple, you can do a lot worse than putting an "upcoming
> buses from this
>
stop" page URL into the website=* for vast majority of stops out there. Only
> problem is that doesn't scale very nicely to 1 stops.
>

There are other problems.

1) Many services around here don't have an "upcoming buses from this stop"
page.  We're lucky
they've finally managed to put the timetables on the web.

2) Upcoming buses are useful if you find yourself stranded near a bus
stop.  If you're planning
a future journey you want a timetable.

3) You can always figure out the upcoming buses if you have a timetable;
you cannot figure out
the timetable from upcoming buses.

> or a timetable or whatever web page the
> > mapper happened to think relevant.  I'd prefer to distinguish between a
> human-readable timetable
> > and raw GTFS data (not really human-readable but could be parsed by an
> app).  For lack of anything
> > better, I'd be happy with timetable=* and gtfs=* but I expect somebody
> will be along shortly to explain
> > why those are a very bad idea.
>
> I'd be happy with gtfs= on a possibly high-level
> relation that ultimately includes stops, and timetable= or
> departures= on stops where available as HTML page.
>

Again, "upcoming buses" just doesn't cut it for me.  Great for big towns
and cities.  Not so good
for rural routes.  Great for when you're unexpectedly stranded near a bus
stop.  Not so good for
planning a journey  in advance.

I think the Berlin tagging makes sense:
> https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
> Other pages I'm familiar with are
> https://nb.translink.ca/text/stop/50167 or
>
> http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed


I'm not sure what point you were making there.  They're web pages, not
tagging schemes. If
you wanted me to admire the pretty web pages, that's nice.  If you want to
see what I have to
put up with, here's what one operator has:
https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf
and here's the
county council's version of the same route (showing more stops):
https://www.ceredigion.gov.uk/media/4410/408.pdf
There is no "next 3 buses" info.  These pages are not updated live.
They're just PDFs.

>From Canadian English perspective, "timetable" would be more likely to
> be interpreted as all departures for the whole week (as on the TTC
> page). "departures" matches the "next 3 buses" case a bit closer. But
> perhaps it's different in British English.
>

>From the perspective of a Brit who uses (but doesn't operate) buses, that
sounds about right.
Where we differ is which is most useful.  We probably need tags for both
(for when both
are available), rather than leave it to the mapper to decide.

> Whatever we go for, we have to cater to the fact that a particular route
> may have more than one
> > operator (I'm not talking about super-routes here).  Around here there
> are many small local operators,
> > and longer routes sometimes split the service between two operators
> (i.e., the route X to Y might
> > be split between an operator based in X and another operator based in Y).
>
> GTFS as a format is operator agnostic (the operator information is not
> in the data at all, only "agency", but each route must be tied to
> exactly one agency). It is more of a question whether a full timetable
> is provided in a given GTFS file or if it is a partial timetable and
> we want to support merging timetables.
>

Good question.  On the routes I have in mind, the county council and one
operator
provided full timetables but the other operator provided a partial
timetable.  The operator
who provided full timetables has managed to produce broken GTFS for some
routes
(it works, but the answers it gives are silly).  I have seen no indication
that the county council
has even heard of GTFS.

What I have seen in transit data collection is one physical stop
> served by multiple agencies which provide separate GTFS files, and
> sometimes they reference the stop using different stop IDs. But in
> that case it would be using different routes, and it should be doable
> with ref:=123 + ref:=abc (where agency_1 and
> agency_2 preferably match the GTFS agency IDs...)
>

Ummm, wouldn't that mean GTFS data about every route by that agency?

However, you've made me abandon hopes of adding this information to stops.
Yes, it
means more steps when using the query tool on standard carto, and some
users won't
be able to handle that, but trying to cater

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

Hello,

I've gotten paid for wrangling GTFS worldwide before - happy to tell
you some of my experiences.

On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> As I said, I'd prefer not to use url=* because it could be for anything - a 
> page about the history of
> the bus stop (maybe the shelter is a listed building),

That would rather be website=* though. And to keep it simple, you can
do a lot worse than putting an "upcoming buses from this stop" page
URL into the website=* for vast majority of stops out there. Only
problem is that doesn't scale very nicely to 1 stops.

> or a timetable or whatever web page the
> mapper happened to think relevant.  I'd prefer to distinguish between a 
> human-readable timetable
> and raw GTFS data (not really human-readable but could be parsed by an app).  
> For lack of anything
> better, I'd be happy with timetable=* and gtfs=* but I expect somebody will 
> be along shortly to explain
> why those are a very bad idea.

I'd be happy with gtfs= on a possibly high-level
relation that ultimately includes stops, and timetable= or
departures= on stops where available as HTML page.

I think the Berlin tagging makes sense:
https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
Other pages I'm familiar with are
https://nb.translink.ca/text/stop/50167 or
http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed

From Canadian English perspective, "timetable" would be more likely to
be interpreted as all departures for the whole week (as on the TTC
page). "departures" matches the "next 3 buses" case a bit closer. But
perhaps it's different in British English.

> Whatever we go for, we have to cater to the fact that a particular route may 
> have more than one
> operator (I'm not talking about super-routes here).  Around here there are 
> many small local operators,
> and longer routes sometimes split the service between two operators (i.e., 
> the route X to Y might
> be split between an operator based in X and another operator based in Y).

GTFS as a format is operator agnostic (the operator information is not
in the data at all, only "agency", but each route must be tied to
exactly one agency). It is more of a question whether a full timetable
is provided in a given GTFS file or if it is a partial timetable and
we want to support merging timetables.

Having done some work on merging GTFS, I am afraid the latter is a
deep rabbit hole very few data consumers will go down.

What I have seen in transit data collection is one physical stop
served by multiple agencies which provide separate GTFS files, and
sometimes they reference the stop using different stop IDs. But in
that case it would be using different routes, and it should be doable
with ref:=123 + ref:=abc (where agency_1 and
agency_2 preferably match the GTFS agency IDs...)

Feel free to ask for more technical info about GTFS :) Or for
real-world usage - I've looked at GTFS for most major metros in Canada
and U.S., some smaller metros, data where available in Europe, and a
bit of Australia.

> But stops can be used by
> more than one route.  So then we'd need timetable:route-number:operator=link.

Different route operators with separate timetables is probably in the
"use departures_1 for departures that don't fit" territory. We don't
need to support every edge case to be useful, just the majority of
real world use.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Sun, 3 Mar 2019 at 00:06, Graeme Fitzpatrick 
wrote:

>
> On Sun, 3 Mar 2019 at 00:21, Paul Allen  wrote:
>
>> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:
>>
>>>
>>> So a documented way of including GTFS link in routes?
>>>
>>
>> Yep.  We could just use url=*
>>
>
> When I've been adding bus stops, I've been using timetable= linked to the
> GTFS data for that stop eg https://www.openstreetmap.org/node/6251012182
> links to https://jp.translink.com.au/plan-your-journey/stops/300772,
> which shows the buses for about the next hour, on both routes that service
> that stop. That page (which, incidentally, we have explicit permission to
> use, plus a waiver!) then also links to the full timetable for today &
> other days.
>

That is not the raw GTFS data but a human-readable, active (it uses web 2.0
magic) timetable based
(presumably) on the GTFS data.

When I've looked at stop info via OSMAND on my phone, the URL is there as a
> clickable link so it would appear to work?
>

I'd guess that OSMAND (and the standard carto, which also treats it as a
link) is using a heuristic
along the lines of "If I don't know what the key means AND the value looks
like a URL then treat the
value as a link."  Which is reasonable, but it would be nice to formalize
it.  If for no other reason than
to allow verification tools to know that the value ought to be a link to a
working web page and that
they should check it.

As I said, I'd prefer not to use url=* because it could be for anything - a
page about the history of
the bus stop (maybe the shelter is a listed building), or a timetable or
whatever web page the
mapper happened to think relevant.  I'd prefer to distinguish between a
human-readable timetable
and raw GTFS data (not really human-readable but could be parsed by an
app).  For lack of anything
better, I'd be happy with timetable=* and gtfs=* but I expect somebody will
be along shortly to explain
why those are a very bad idea.

Whatever we go for, we have to cater to the fact that a particular route
may have more than one
operator (I'm not talking about super-routes here).  Around here there are
many small local operators,
and longer routes sometimes split the service between two operators (i.e.,
the route X to Y might
be split between an operator based in X and another operator based in Y).
In the cases where this
has happened one of those operators produced a timetable showing all of the
services irrespective
of the operator whilst the other operator's timetable showed only its own
services.  Since the route
was subsidized by local gov't, there was also a council timetable.
Actually, the route was between
locations in two counties, so there were probably two council timetables.
But there could have been
only two operator timetables that showed only their own services on that
route.  So maybe we need
timetable:operator=link.

Further complication if we want to add this information to bus stops as
well as routes.  An app
ought to be capable of finding the route from a query about a stop and then
getting the appropriate
timetable.  But using the query tool provided by standard carto may require
more smarts than many
data consumers have, so adding the timetable to stops would be nice.  But
stops can be used by
more than one route.  So then we'd need
timetable:route-number:operator=link.

I'm hoping somebody will come up with a better tagging scheme...

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Sun, 3 Mar 2019 at 00:21, Paul Allen  wrote:

> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:
>
>>
>> So a documented way of including GTFS link in routes?
>>
>
> Yep.  We could just use url=*
>

When I've been adding bus stops, I've been using timetable= linked to the
GTFS data for that stop eg https://www.openstreetmap.org/node/6251012182
links to https://jp.translink.com.au/plan-your-journey/stops/300772, which
shows the buses for about the next hour, on both routes that service that
stop. That page (which, incidentally, we have explicit permission to use,
plus a waiver!) then also links to the full timetable for today & other
days.

When I've looked at stop info via OSMAND on my phone, the URL is there as a
clickable link so it would appear to work?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:

>
> So a documented way of including GTFS link in routes?
>

Yep.  We could just use url=* but I'd prefer to keep that available for
other things.  Besides,
it would probably be a good idea to allow for a link to the operator's
timetable.  Oh, and there
may be some routes with more than one operator (this has happened around
here where a
route is split between two small local operators).

Routes only, or is there a desire to have this on stops too?
>

There are situations where people want to know the timetable info at a
particular stop.  As in
"My car broke down here, I can see a bus stop, when is the next bus?"  (not
all bus stops indicate
which bus routes they serve).

Depends how sophisticated the data consumer is.  A smart app could figure
out a stop is on one
or more routes then grab the relevant data from the route.  Somebody using
the query tool on
standard carto might have more difficulty.

I think it ought to at least be permissible on stops.   But that requires a
tagging scheme capable
of dealing with stops that serve several routes.

I would think a proposal for routes (ferry or otherwise) where GTFS is not
> freely available is also needed.
>

As others have remarked, there are GTFS servers which allow anyone to set
up a route.  I think
that if we have to add information somewhere, it is better to enter it into
GTFS than to bodge it
into OSM.  Supporting both would make things more complicated for data
consumers.  Also,
the GTFS servers that allow anyone to set up a route have provision to turn
the data over to the
operator of that route as and when that becomes sensible.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Mateusz Konieczny]

Mar 2, 2019, 9:12 AM by 61sundow...@gmail.com:

> The other thing picked on it keeping it 'up to date'.
> One says a route is out of date for years (why the contributor does not up 
> date it is not stated)
>
In my case: because updating it would take about half of hour, there are 
multiple ones 
outdated and updating them all would take most of a day.

And all of them will change again once
https://www.openstreetmap.org/way/340398942#map=19/50.07378/19.91285 

is reopened.

Other public transport routes are probably also outdated, but I have more 
interesting things to do
than updating them.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Warin]

On 02/03/19 10:27, Jarek Piórkowski wrote:


On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote:

It seems like the best way forward now is for a proposal allowing OpenStreetMap 
data to be tightly integrated with outside sources (such as GTFS) to be created 
by someone.

+1. To avoid lots of changes, perhaps only set the GTFS link on a
meta-relation where possible, like
https://www.openstreetmap.org/relation/18812


  This would avoid the issues of maintainability in OpenStreetMap.

There is still the concern about GTFS URL changing, which happens
sometimes, but perhaps not as often as schedules in a large city.


So a documented way of including GTFS link in routes?
Routes only, or is there a desire to have this on stops too?

Needs a proposal.




Also, if anyone is interested, I can create a new proposal for adding 
departures times to ferry routes only, and not to bus / train routes.  This 
would be easier to maintain, and as far as I am aware, no GTFS exists for 
ferries.

Just one note - it is possible to have ferry schedules in GTFS. I am
familiar with several cases of these: Berlin city transit ferries;
some ferries in Netherlands in their giant OVapi GTFS file; some
ferries in a Finland; main harbour ferry in Vancouver. You can also
produce your own GTFS for any ferry operation you like (the challenge
is getting people to use it).

It is more a matter of ferries, particularly longer routes, usually
not being operated by public transit bodies that might be more likely
to produce a GTFS feed.


I would think a proposal for routes (ferry or otherwise) where GTFS is not 
freely available is also needed.

The other thing picked on it keeping it 'up to date'.
One says a route is out of date for years (why the contributor does not up date 
it is not stated), so a time table will be even more likely to be out of date.
As these people probably have a GTFS system then a proposal for those who don't 
have GTFS should remove their objection.
But first there needs to be that GTFS link so they can be happy.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote:
> It seems like the best way forward now is for a proposal allowing 
> OpenStreetMap data to be tightly integrated with outside sources (such as 
> GTFS) to be created by someone.

+1. To avoid lots of changes, perhaps only set the GTFS link on a
meta-relation where possible, like
https://www.openstreetmap.org/relation/18812

>  This would avoid the issues of maintainability in OpenStreetMap.

There is still the concern about GTFS URL changing, which happens
sometimes, but perhaps not as often as schedules in a large city.

> Also, if anyone is interested, I can create a new proposal for adding 
> departures times to ferry routes only, and not to bus / train routes.  This 
> would be easier to maintain, and as far as I am aware, no GTFS exists for 
> ferries.

Just one note - it is possible to have ferry schedules in GTFS. I am
familiar with several cases of these: Berlin city transit ferries;
some ferries in Netherlands in their giant OVapi GTFS file; some
ferries in a Finland; main harbour ferry in Vancouver. You can also
produce your own GTFS for any ferry operation you like (the challenge
is getting people to use it).

It is more a matter of ferries, particularly longer routes, usually
not being operated by public transit bodies that might be more likely
to produce a GTFS feed.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] New Tag "Departures" voting results.

[Leif Rasmussen]

Hi everyone,
The proposal for the tag "departures" has finished, and has a final vote of
* 12 "Approve"
* 22 "Reject"
* 3 Comments without vote
* 1 "Degree of incredulity" at the proposal
. . . meaning that the proposal was rejected.

Overall, the main idea voters expressed was that connecting with GTFS and
others would be advantageous over adding the data to OpenStreetMap in the
form of tags, as it would allow data consumers to just download the data
from the original source, making storing the timetables directly in
OpenStreetMap unnecessary.  People living in regions without public GTFS
feeds expressed concerns about cases where OpenStreetMap would be the only
public source of timetable data, however.
Many people agreed on the contrary that the data would still make sense on
ferry routes, which are more essential to car navigation, and usually have
simpler schedules.

It seems like the best way forward now is for a proposal allowing
OpenStreetMap data to be tightly integrated with outside sources (such as
GTFS) to be created by someone.  This would avoid the issues of
maintainability in OpenStreetMap.

Also, if anyone is interested, I can create a new proposal for adding
departures times to ferry routes only, and not to bus / train routes.  This
would be easier to maintain, and as far as I am aware, no GTFS exists for
ferries.

Thank you to everyone who participated in the voting and discussion of this
proposal!
Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging