[Tagging] Feature Proposal - Voting - Metro Mapping

Jo winfixit at gmail.com
Fri Nov 10 20:25:46 UTC 2017

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).

I don't mind adding the shelter, waste_basket, bench,
ticket_vending_device, announcement_board to such a relation.

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.

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.

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?


2017-11-10 19:43 GMT+01:00 marc marc <marc_marc_irc at hotmail.com>:

> 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
> saying so.
> 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
> laser)
> >> -- 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).
> exemple https://www.openstreetmap.org/relation/7151720
> it 'll need to be splited in 3... without reading the benefit of these
> additional relationships.
> >> 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.
> > http://www.openstreetmap.org/changeset/53267689
> > 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
> available."
> 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
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
> 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
> same thing.
> 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.
> Regards,
> Marc
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20171110/73374cba/attachment-0001.html>

More information about the Tagging mailing list