[Tagging] Feature Proposal - RFC - Public Transport v3

John Doe music.kashish at gmail.com
Mon Mar 9 11:28:32 UTC 2020


This is quite off-topic, but I can't bear to read more completely unfounded criticism of PTv2.

I hereby declare that I find the old tags to be a complete abomination (Is it on the way? Is it beside the way? Is it a stop, a platform, a halt, a station? Why is a platform or a bus stop a railway or a highway?), and PTv2 tags to be very consistent and comprehensible in comparison. Indeed, this thread has motivated me to stop using legacy tags entirely - to hell with Carto and other legacy consumers.

If tram stops (as described on the wiki) are accessible from both sides and it makes sense to put them on the way, then PTv2 is very much justified in creating an umbrella tag for stops which are placed on the way. I don't understand why the critics of PTv2 seem to think stop positions are such a big deal - they are optional!

Platforms are where passengers wait.
Stations are places with many platforms.
Stop positions are where vehicles stop - an optional alternative to using platforms, included for backward-compatibility.
And the feature is not confounded with the vehicle that serves it, nor the infrastructure provided. A platform is a platform regardless of shelter, bench, or tactile paving.

It remains an elusive mystery as to how I, a mere mortal, managed to map >70 services using this arcane, Baroque schema. /s

https://wiki.openstreetmap.org/wiki/Delhi/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Noida/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Delhi/Share_autos

09-Mar-2020 13:46:42 Alan Mackie <aamackie at gmail.com>:

> 
> 
> On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, < tagging at openstreetmap.org [mailto:tagging at openstreetmap.org] > wrote:
> 
> > This proposal by Stereo is nothing really new. Just a alternative to
> > routing which has been around since relations were introduced.
> > Definitely not 'PTv3'. The 'via' option appears almost as difficult to
> > maintain as including ways.
> > 
> > 
> > On 08/03/2020 01:41, John Doe wrote:
> > 
> > 
> > >
> > > That would be tempting, because it would mean a lot less work for us in the short term. However, I'm afraid of ending up like PTv2 -
> > > 1. It 'does not deprecate the old tags', use of the new tags is 'recommended but not mandatory'...whatever that means.
> > It means PTv2 tags aren't required as there are existing tags performing
> > the same job.
> > > 2. People with a preference for the old tags see that as an excuse to keep using them
> > 
> > No. They are preferred because they simple to comprehend, accurate &
> > abundant.
> > > 3. Consumers see that as an excuse to not support the new schema, even after 8 years of people requesting it - https://github.com/gravitystorm/openstreetmap-carto/issues/311
> > PTv2 [https://github.com/gravitystorm/openstreetmap-carto/issues/311PTv2] isn't supported because it's not abundant (people get bored of
> > adding them after a couple weeks)
> > 
> > > 4. People who want to use the new tags have to use _both_ sets of tags 🤦♀️
> > No they don't. They can use just the original tags. PTv2 tags are pure
> > duplication.
> > > 5. Both sets of tags have to be documented, making the documentation more verbose than it might be.
> > > They should coexist...for a transitional phase. But it has to be just that - a _transition_, not a permanent inconsistent mess.
> > 
> > The original tags are here to stay because they work. PTv2 is a
> > *separate*, *independent* scarcer schema running in parallel that adds
> > nothing over existing tags.
> > 
> > It is only PTv2 which is the mess. Even those who conceived it are
> > confused by it.
> > 
> > DaveF
> > 
> 
> Whenever I have considered adding things in a ptv2 compatible way I have ended up confused and reverted to a simple highway=bus_stop. Ptv2 seems to want imaginary unverifiable stop points and for you to add signs on poles as "platforms" for reasons I could never fathom. Then of course even the simplest route actually has to be two or more routes for some reason. All of these seemed to have documentation spread across several different wiki pages with no clear relationship to each other.  
> The new proposal seems to be an attempt to get back to the clarity of the original system while throwing the baby away with the bathwater. In theory a router could reconstruct a route from points, if it's simple enough, but if we are going to do that then we may as well drop the route relation completely and just put the list of services on the stop nodes where most jurisdictions have them signposted. After all, we have just massively increased the amount of data crunching by any consumer anyway, they may as well start that process by doing a search for local refs and build their own stop lists.  
> 




More information about the Tagging mailing list