[Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski <jarek at piorkowski.ca> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190305/00e9eec5/attachment.html>