As part of the proposal .. I think  a document on how to map PTv3 in the 
simplest most basic way needs to be done.

This would not be the bells and whistles method, but the bread and water 
method. The basics that would have the routing working and the map displaying 

It needs to be done for at least trains and buses. Some would like ferries too.

That would demonstrate how easy PTv3 would be for mappers to map,
without going through the documentation for the extra features that actually 
don't help the routing.

On 25/07/18 00:56, Leo Gaspard wrote:

Hi Ilya,

I unfortunately won't be anywhere near Milan anytime soon, but thanks
for the invitation :)

The problem I can see with your proposal is that it appears to be based
on PTv1, not on PTv2, which looks much more logical to me (even though I
still don't understand it completely). I mean, there are 8 tags in your
proposal for “Stops and Stations”, whereas if I try to adapt marginally
PTv2 I would get to public_transport=platform, bus=yes / tram=yes / ...
; which sounds more consistent and easy to use both for the mapper and
for the data consumer. Same issue with 5 tags for “platforms”.

Basically, I feel like (without anything to prove my point) just
reordering and rewording the documentation for PTv2 (by explicitly
marking some elements as “optional if the mapper feels like mapping
them” and not talking about things that were done once) and maybe minor
changes would be enough for a huge boost in usability of PTv2, without
needing to rollback to PTv1 :) (again, I don't know what I'm talking
about, but the feeling I had from PTv2 is that it tried to unify tagging
so that it's easier to both remember and programmatically use, and the
feeling I have from your current specification is that it's not really

On 07/24/2018 11:32 PM, Ilya Zverev wrote:
Hi Leo,

As a person who tried for many years not to touch any public transport in OSM 
because of hard to understand tagging, I share your pain about missing 
tutorials and instructions. The situation with these is a bit better in the 
Russian part of wiki, because we don't have hordes of mappers eager to bikeshed 
every explanation.

The title of the proposal is a bit misfortunate. It is not a new schema that coexists 
with previous two. On the contrary, it (if accepted) will be the single reference schema 
that data processors and validators would be built against. The version is misleading, 
and I think I should've taken on SK53's suggestion to rename it to e.g. "Refined 
Public Transport Tagging".

What the proposal really is is a clarification of what PTv1/2 elements really 
mean and how and when to use them. I refrained from wording it as a tutorial, 
because the last time I did that, I've got a lot of rage over every tiny thing. 
Some people here are still angry at me for that. Proposals are not tutorials.

I hope this answers your points 1-5. If you read the new proposal carefully, you'll 
notice that unlike the previous proposals, it spends many words explaining reasons behind 
every decision. It also makes mapping routes simple, while keeping options for 
micromapping (see the "Examples" section).

PTv1 will never vanish, because we didn't have it in the first place. It was just a pile 
of tags (like highway=bus_stop) which everybody understood and which did not form a 
coherent "schema", and route relations that were basically collections of 
everything related to a route.

PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
mapping. It failed with many mappers like you (and me), because it was based on 
industry standards, which are very sensible, but imply a state-of-art editing 
system behind them. Mapping a route in PTv2 is like writing a GTFS feed in the 

The new proposal is about shedding off all the complexity, and leaving only 
elements required for using stops and routes. Once (if) it is accepted, it 
would be very easy to write a tutorial, because then you would be able to learn 
it gradually. First with collecting bus_stop nodes in a relation, then with 
platforms, and so on. The new proposed schema is flexible, which means you 
don't have to learn all of it to map a proper route. I believe that will 
attract many new mappers to add their public transport routes.

Thank you for your opinion, and I would very much like to discuss how can we 
make mapping routes simpler. If you're in Milan these holidays, come to my talk 
on Sunday morning, and look for a public transport BoF meeting, most likely on 


24 июля 2018 г., в 16:55, Leo Gaspard <osm...@leo.gaspard.io> написал(а):

My point of view, as a beginner in OSM who still hasn't understood how
PTv1 and PTv2 are supposed to work (and thus didn't read this specific
proposal, take this as generic comments on PT tagging in OSM):

1. Beginners are already at a loss, introducing a third (!) tagging
scheme will just make things worse

2. If I were developer of an OSM tool, I'd be facepalming as soon as I
saw the word “PTv3”

3. What is *really* needed is a clarification of what PTv[12] actually
mean. This is first and foremost a documentation issue, not a tagging
scheme issue.

4. If I understood correctly, it's possible to use PTv2 with as few
tags as PTv1, but noone really understands it because the documentation
is such a mess. So I think a proposal of “Clarification of the relative
importance of tags in Public Transportation tagging” would be great.

Tagging mailing list

Reply via email to