[Tagging] Feature Proposal - Voting - Metro Mapping
marc_marc_irc at hotmail.com
Fri Nov 10 18:43:43 UTC 2017
Le 10. 11. 17 à 17:45, Ilya Zverev a écrit :
> Your "why change" argument looks weird with this sentence, by the way.
I will rephrase my question. What are the benefits of your proposal ?
What is the problem with the current situation and how does your
proposal improve it ? the main change seems to be to cut a relationship
in 2 without my understanding of the benefit.
a proposal usually said "problem, current situation, solution".
yours said "clarification (=change)".
But in the talk page, problem are after your changes, not before :)
>> - On the other hand, the section "What This Affects" is incomplete.
>> -- it lacks the incomprehensible prohibition to map a station a an area.
> Did you read https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway ?
yes (but no link to the approved proposal)
either your proposal does not change the previous proposal on this and
then it is not a proposal since it is already the case. either your
proposal wishes to make an existing situation "deprecated" but without
often going from a node to an area is an improvement in the accuracy of
information, so I do not really understand the point of wanting to
depreciated the most accurate way of describing a station. Saying that a
station is not visible on a satellite image or that a laser is necessary
is a strange argument (road tunnels are also absent from satellite view,
that does not stop anyone from describing them in osm without needing a
>> -- many other details are incomprehensible as "Platform Layer should be
>> at least -3". what should be "mandatory" between layer and -3 ?
> I chose -3 from the practical standpoint: -1 is usually used for highway tunnels, and -2 might be used on complex junctions, so having a layer -3 and less would be a safe option.
you misunderstand the layer tag.
it should not be a value for tunnel, a value for junction, and a value
for a station. it depends on the reality of site.
Starting from the ground, first could have -1, next -2 and so.
for ex https://www.openstreetmap.org/way/474210035
what is the benefit of having to change it to layer -3 ?
for me it's a useless constraint.
how to map this https://www.openstreetmap.org/way/485683927 ?
with a change to layer -3 and the other platform to -4
and the highway tunnel to -5 ? what is the benefit of not using
the (often) first free layer value like it's currently done ?
a lot of change without advantage over the existing situation.
if I'm wrong, feel free to explain WHY change.
>> -- no explanation why the new shchema is better than the current one.
>> for ex why a stop_area should be duplicated stop_area containing only
>> part + a stop_area_group that groups them.
> How is that worse than the current schema?
your proposal makes it mandatory to do 3 relationships for every small
station (2 stop_area + 1 stop_area_group).
it 'll need to be splited in 3... without reading the benefit of these
>> At the same time, on the mailing transport, there is already the case
>> that a contributor who "cleanup" sncf station to apply the new scheme
>> without any discussion with the local community concerned with app
>> problems that do not work anymore . The phrase "More than fifty metro
>> networks" has to be read as "no matter what your vote is, we have
>> already begun to impose it". it is obviously not very positive.
> I intended to resolve this privately and to wait a couple weeks before making the issue public
Wanting to solve this privately is contradictory to calling to vote
after you have been warned of the problem.
Either you want to find a solution either you start voting.
Opening the voting period assumes that the detected problems
have been resolved.
Voting a proposal that is already known to have problems is a mistake.
> Turns out some agency in France misuses stop_area relations to contain _everything_ in the vicinity of a railway station.
maybe it's wrong to have soo many items to this relation.
but when reading
http://wiki.openstreetmap.org/wiki/Tag:public transport=stop area
you 'll see : "shelter, bench, bicycle_parking, taxi. Recommended, if
So removing all those POI (and prior to the voting) is wrong.
If dev of existing applications need some time to think about
the issue, it does not seem to be excessive.
> I suggested retagging the original type=public_transport to type=site
this is in contraction with the page
that says "not to be used in cases where the elements are inside one or
more areas where the perimeter can be tagged with an appropriate Area"
and propose the opposite modification.
a station is not a dispersed facilities power plants like wind.
Also you claim that a relationship containing hundreds of objects is a
mistake but your solution is to create another relationship with the
What is the advantage over the current situation with one relationship
with roles of members that can be use to find what you want ?
> If Marc wishes for it to be resolved publicly, I welcome your opinions on this.
I have no special wishe with this. I have not link with sncf nor with
those edits. but if somebody warm a problem, it would have been nice to
give some time to the discussion to find a solution before calling to vote.
Calling for opignon after calling for voting is a mistake.
Another problematic aspect is that your proposal introduces a different
meaning for stop_area depending on whether it concerns metros or other
public transport (for example bus+tram can have a single stop_area with
multiple platforms). An advantage of PTv2 was precisely to reduce the
differences between different types of transport.
More information about the Tagging