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? Polyglot 2017-11-10 19:43 GMT+01:00 marc marc <[email protected]>: > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
