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 >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
