<div dir="ltr"><div><div><div><div><div>I, for one, prefer to have the platform node/way and its corresponding stop_position in 1 stop_area relation per direction of travel or per platform (in bus stations).<br><br></div>I don't mind adding the shelter, waste_basket, bench, ticket_vending_device, announcement_board to such a relation.<br><br></div>Then these stop_area relations can be grouped. I started doing this in stop_area_group, but later on simply started creating a hierarchy of stop_area relations, as JOSM's  validator complained about the stop_area_group relations.<br><br></div>Having said that, I'm not always creating these stop_area relations. I'm mostly mapping bus stops and routes and if there is no ambiguity with resolving the correspondance between platform and stop_position/[highway to be added ot the route relation], then spatial is good enough for me.<br><br></div>For underground features I would probably map all of the stop_area relations, so it's clear what belongs together. For grouping 2 platforms / 2 stop_positions with the same name that are near to each other, there is no real benefit in having them all together in stop_area relations either, what's the functionality of that?<br><br></div>Polyglot<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-10 19:43 GMT+01:00 marc marc <span dir="ltr"><<a href="mailto:marc_marc_irc@hotmail.com" target="_blank">marc_marc_irc@hotmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 10. 11. 17 à 17:45, Ilya Zverev a écrit :<br>
<span class=""><br>
> Your "why change" argument looks weird with this sentence, by the way.<br>
<br>
</span>I will rephrase my question. What are the benefits of your proposal ?<br>
What is the problem with the current situation and how does your<br>
proposal improve it ? the main change seems to be to cut a relationship<br>
in 2 without my understanding of the benefit.<br>
a proposal usually said "problem, current situation, solution".<br>
yours said "clarification (=change)".<br>
But in the talk page, problem are after your changes, not before :)<br>
<span class=""><br>
>> - On the other hand, the section "What This Affects" is incomplete.<br>
>> -- it lacks the incomprehensible prohibition to map a station a an area.<br>
> Did you read <a href="https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway" rel="noreferrer" target="_blank">https://wiki.openstreetmap.<wbr>org/wiki/Tag:station%3Dsubway</a> ?<br>
<br>
</span>yes (but no link to the approved proposal)<br>
either your proposal does not change the previous proposal on this and<br>
then it is not a proposal since it is already the case. either your<br>
proposal wishes to make an existing situation "deprecated" but without<br>
saying so.<br>
often going from a node to an area is an improvement in the accuracy of<br>
information, so I do not really understand the point of wanting to<br>
depreciated the most accurate way of describing a station. Saying that a<br>
station is not visible on a satellite image or that a laser is necessary<br>
is a strange argument (road tunnels are also absent from satellite view,<br>
that does not stop anyone from describing them in osm without needing a<br>
laser)<br>
<span class=""><br>
>> -- many other details are incomprehensible as "Platform Layer should be<br>
>> at least -3". what should be "mandatory" between layer and -3 ?<br>
> 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.<br>
<br>
</span>you misunderstand the layer tag.<br>
it should not be a value for tunnel, a value for junction, and a value<br>
for a station. it depends on the reality of site.<br>
Starting from the ground, first could have -1, next -2 and so.<br>
for ex <a href="https://www.openstreetmap.org/way/474210035" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>way/474210035</a><br>
what is the benefit of having to change it to layer -3 ?<br>
for me it's a useless constraint.<br>
how to map this <a href="https://www.openstreetmap.org/way/485683927" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>way/485683927</a> ?<br>
with a change to layer -3 and the other platform to -4<br>
and the highway tunnel to -5 ? what is the benefit of not using<br>
the (often) first free layer value like it's currently done ?<br>
a lot of change without advantage over the existing situation.<br>
if I'm wrong, feel free to explain WHY change.<br>
<span class=""><br>
>> -- no explanation why the new shchema is better than the current one.<br>
>> for ex why a stop_area should be duplicated stop_area containing only<br>
>> part + a stop_area_group that groups them.<br>
</span><span class="">> How is that worse than the current schema?<br>
<br>
</span>your proposal makes it mandatory to do 3 relationships for every small<br>
station (2 stop_area + 1 stop_area_group).<br>
exemple <a href="https://www.openstreetmap.org/relation/7151720" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>relation/7151720</a><br>
it 'll need to be splited in 3... without reading the benefit of these<br>
additional relationships.<br>
<span class=""><br>
>> At the same time, on the mailing transport, there is already the case<br>
>> that a contributor who "cleanup" sncf station to apply the new scheme<br>
>> without any discussion with the local community concerned with app<br>
>> problems that do not work anymore . The phrase "More than fifty metro<br>
>> networks" has to be read as "no matter what your vote is, we have<br>
>> already begun to impose it". it is obviously not very positive.<br>
</span><span class="">> I intended to resolve this privately and to wait a couple weeks before making the issue public<br>
</span>Wanting to solve this privately is contradictory to calling to vote<br>
after you have been warned of the problem.<br>
Either you want to find a solution either you start voting.<br>
Opening the voting period assumes that the detected problems<br>
have been resolved.<br>
Voting a proposal that is already known to have problems is a mistake.<br>
<span class=""><br>
> <a href="http://www.openstreetmap.org/changeset/53267689" rel="noreferrer" target="_blank">http://www.openstreetmap.org/<wbr>changeset/53267689</a><br>
> Turns out some agency in France misuses stop_area relations to contain _everything_ in the vicinity of a railway station.<br>
<br>
</span>maybe it's wrong to have soo many items to this relation.<br>
but when reading<br>
<a href="http://wiki.openstreetmap.org/wiki/Tag:public" rel="noreferrer" target="_blank">http://wiki.openstreetmap.org/<wbr>wiki/Tag:public</a> transport=stop area<br>
you 'll see : "shelter, bench, bicycle_parking, taxi.   Recommended, if<br>
available."<br>
So removing all those POI (and prior to the voting) is wrong.<br>
If dev of existing applications need some time to think about<br>
the issue, it does not seem to be excessive.<br>
<span class=""><br>
> I suggested retagging the original type=public_transport to type=site<br>
<br>
</span>this is in contraction with the page<br>
<a href="http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site" rel="noreferrer" target="_blank">http://wiki.openstreetmap.org/<wbr>wiki/Relations/Proposed/Site</a><br>
that says "not to be used in cases where the elements are inside one or<br>
more areas where the perimeter can be tagged with an appropriate Area"<br>
and propose the opposite modification.<br>
a station is not a dispersed facilities power plants like wind.<br>
Also you claim that a relationship containing hundreds of objects is a<br>
mistake but your solution is to create another relationship with the<br>
same thing.<br>
What is the advantage over the current situation with one relationship<br>
with roles of members that can be use to find what you want ?<br>
<span class=""><br>
> If Marc wishes for it to be resolved publicly, I welcome your opinions on this.<br>
<br>
</span>I have no special wishe with this. I have not link with sncf nor with<br>
those edits. but if somebody warm a problem, it would have been nice to<br>
give some time to the discussion to find a solution before calling to vote.<br>
Calling for opignon after calling for voting is a mistake.<br>
<br>
Another problematic aspect is that your proposal introduces a different<br>
meaning for stop_area depending on whether it concerns metros or other<br>
public transport (for example bus+tram can have a single stop_area with<br>
multiple platforms). An advantage of PTv2 was precisely to reduce the<br>
differences between different types of transport.<br>
<br>
Regards,<br>
Marc<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/tagging</a><br>
</div></div></blockquote></div><br></div>