> I suggest that you read the discussion I started in December about crossing=zebra because it is the main cause of the current situation.
I read it back in December, but I disagree. The cause of the situation is the huge problems with the crossing=* values for marked crossings. That problem also caused the iD editor to use its zebra and now marked presets. > Bryan replaced crossing=zebra with crossing=marked in iD but as the crossing=zebra problems were not understood, the alternative has exactly the same problems as the replaced solution. Such as...? > the crossing key is however simple to use except for badly chosen values does the passage have a fire? crossing=traffic_signals otherwise, does the passage have a marking on the ground? crossing=uncontrolled (the work is not perfect because a marking a kind of controll) otherwise crossing=unmarked I don't understand what you're saying here (fire?), but would be interested in knowing what you mean. Could you please rephrase? > Last year, I have review ~1k crossing=zebra, the fragmentation is mainly due to iD I'd expect quite a few tags to come from iD, as it's the default editor on openstreetmap.org, of course. I'm curious about your methodology, since I don't remember seeing this in that December thread. How did you sample? What were the results? > for now, the "new" iD preset destroys perfectly valid data at a frightening rate! if someone modifies a pedestrian crossing with a light, iD replaces it with crossing=marked, which disrupts the information of the presence of the light. This is not relevant to my proposal. Please keep unrelated gripes regarding editors to another thread. > There is already a tag for the reference of a crossing. I'm aware. Please read my proposal, where I explicitly discuss this. > a bad preset is not a good usage Please explain why it's a bad preset. Best, Nick On Wed, May 8, 2019 at 1:51 AM marc marc <[email protected]> wrote: > Le 07.05.19 à 22:57, Nick Bolten a écrit : > > - crossing=* values are not truly orthogonal and this needs to be > > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are > > not truly orthogonal descriptors. > > I suggest that you read the discussion I started in December about > crossing=zebra because it is the main cause of the current situation. > Bryan replaced crossing=zebra with crossing=marked in iD but as the > crossing=zebra problems were not understood, the alternative has exactly > the same problems as the replaced solution. > the crossing key is however simple to use except for badly chosen values > does the passage have a fire? crossing=traffic_signals > otherwise, does the passage have a marking on the ground? > crossing=uncontrolled (the work is not perfect because a marking a kind > of controll) > otherwise crossing=unmarked > > > - There is fragmentation in tag usage for marked crossings between > > "zebra" and "uncontrolled". > > Last year, I have review ~1k crossing=zebra, > the fragmentation is mainly due to iD > > > - crossing=marked is direct and clear about its meaning and use cases. > > for now, the "new" iD preset destroys perfectly valid data > at a frightening rate! > if someone modifies a pedestrian crossing with a light, iD replaces it > with crossing=marked, which disrupts the information of the presence of > the light. > There is already a tag for the reference of a crossing. > if the reference is not known, it would be easy to use crossing_ref=yes > as it is done with many keys. > > > - crossing=marked is already in use and supported by various editors, > > including being the default in iD > > a bad preset is not a good usage > > Regards, > Marc > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
