The node doesn't describe the platform. The naming is unfortunate, but I think we're stuck with it. The node represents the stop. What stop platform way and stop_position node belongs together can be expressed using a stop_area relation. Then it's needed only once. There is no need to do it over and over again in the route relations.
If it's such a problem that mapped stop_positions are not in the route relations, my next step (for Belgium at least) is to remove the ones that I added from the OSM. The route relations I'm maintaining will continue to have 1 object per stop. Unfortunately, my colleague in Brussels read the wiki and he is adding stop_position nodes everywhere and adding them to the route relations of the STIB/MIVB operator. The consequence is that I won't be maintaining those (not really a problem, as I wasn't doing that anyway), but those stops are being used by the other 2 operators too, of course. And I won't be able to remove those stop_position nodes AND I won't be adding them to the route relations, so it becomes impossible to comply with what the wiki 'dictates' at present (it didn't just a few months ago). What I mean by stability of the data is the following: A mapper comes along and maps a bus stop on a node. Another mapper adds it to some route relations. Then a mapper passes by and adds a way for the platform, transferring all the tags and adding the way to the route relations. Then somebody read the wiki and adds a stop_position node as well and adds this to all the route relations as well. Lots of changes to the relations, no real change to the itineraries. If the second mapper had simply added a highway=platform and maybe a stop_area relation, the route relations would have remained stable. Anyway, I'll keep going the way I like mapping PT and the rest of the world can do it in more complex ways, each slightly different from the other, depending on when they read the wiki. It's all fine. I'd like to see it become simpler, more inclusive for everyone. Now most mappers simply say: public transport I don't touch it. Tried to read the wiki, gave up. Let the 'specialists' handle it. I'll continue working on PT_Assistant and of course I'll try to make it work for simple and complex ways of mapping alike. Polyglot 2018-04-16 20:51 GMT+02:00 Stephen Sprunk <step...@sprunk.org>: > Jo, > > IMHO, if a stop_position exists but isn't in a relation, consumers can't > be sure which routes/platforms it applies to, and that means it's just > clutter rather than useful data. Given how many of them seem to be > flat-out wrong, though, we definitely need to document it better--and make > maybe it optional so mappers aren't forced to add something that they don't > really understand. > > If there's a way/area for the platform, then IMHO one should not add a > separate node for the platform; that is redundant. If you need a single > point for some purpose, you can just compute the centroid. I don't see > what "stability" has to do with it; once it's mapped, it's not going to > change much over time unless the physical platform itself is changed, and > one shouldn't expect stability in that case. One can tag either just as > easily too, so I don't understand that argument at all. > > When I map a building, I can make a node and put all the tags there, or I > can make an area and put all the tags there. Nobody expects a a way for > the outline and a separate node inside it with all the tags--or more > likely, a conflicting set of tags because some mappers didn't notice the > redundancy. Why should a platform be any different? > > S > > > On 2018-04-16 13:20, Jo wrote: > > I knew this was going to be hard. Anyway, I made sure that it's definitely > allowed to tag bus stops as platform nodes. Every few months I look at the > wiki and each time it changes. At present it says that if a stop_position > node is present for a bus stop, it has to be added to the route relations. > I definitely don't agree with that and I won't do that. The route relations > I'm creating only contain 1 object per stop. Having said that, I won't be > removing stop_position nodes or platform ways from route relations, if they > are already present. Unless this proposal passes somehow, then I will help > with the conversion. > > My proposal does not say that it's not allowed or possible to map > platforms as ways or areas. > > It only says that for stability of the data, it would be better to map all > the detail tags on 1 node and only add that node to the route relations. > > If a platform is present, it's perfectly possible to tag it with > > highway=platform or railway=platform > and optionally > tactile_paving=yes > wheelchair=yes/limited/no > > Jo > > 2018-04-16 19:17 GMT+02:00 Stephen Sprunk <step...@sprunk.org>: > >> On 2018-04-16 08:11, Philip Barnes wrote: >> >>> On 16 April 2018 07:46:13 BST, Jo <winfi...@gmail.com> wrote: >>> >>>> Anyway, you're right in that the main point of my proposal is to get >>>> people to add 1 object per stop to the route relations. >>> >>> >>> I think this is a good idea for bus routes as they are quite simple. >>> There is a sign, the passengers wait thereabouts, the bus stops so the >>> door is at this point and the passengers can then board, pay or show >>> their pass to the driver. Making this too complicated will deter >>> mappers from adding public transport. >>> >>> If mappers want to add additional information then they should be free >>> to do so but it should not be compulsory. >>> >> >> To me, this is the crux of the debate. If mappers have put in additional >> data or detail that you don't care about, then you should ignore it rather >> than remove it (or demand that they do so), because some other consumer may >> want that additional data. Ignoring data that is present but not needed is >> always easier and more reliable than trying to deduce data that is needed >> but not present. >> >> If a consumer doesn't care about stop_position members, it's trivial to >> ignore them. If the current spec says they're mandatory, then propose >> making them optional; I would support that. I don't support prohibiting or >> removing them. >> >> If a consumer only wants a node for the platform but it's mapped as a >> way/area, then it's trivial to detect that and compute the centroid. I >> don't support replacing existing ways/areas with nodes or prohibiting new >> ways/areas in the future. If the current spec says they must be >> ways/areas, then propose making nodes allowed too; I thought that was >> already the case, but if not, I would support fixing that. >> >> S >> >> >> -- >> Stephen Sprunk "Those people who think they know everything >> CCIE #3723 are a great annoyance to those of us who do." >> K5SSS --Isaac Asimov >> > > -- > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
