[Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> 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 <marc_marc_irc at hotmail.com> 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
> 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/20190509/611104b2/attachment.html>