Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

[Sven Geggus]

Joseph Eisenberg  wrote:

> I still think it's easiest for us to approve the fairly popular tag
> "camp_site=camp_pitch", which is already supported by some editors,
> since the alternatives also have some disadvantages.

+1

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked

Hello, fellow tagging enthusiasts! At long last, and after many discussions
on a variety of fora, I am putting this proposal forward in the hopes of
getting feedback, making any necessary revisions, and then moving to a vote.

The motivation for changing how we tag pedestrian crossings has emerged
from the collective experience of many mappers and teachers of OSM mapping
(as well as developers of editors), where this is one of the primary
challenges to coherently mapping pedestrian features: crossing=* tags have
a ton of problems in terms of orthogonality, understandability by new and
veteran mappers alike, and semantic correctness (which also impacts
consumability). One of the primary confusions is the "uncontrolled" (and
"zebra") values, which are, in effect, intended to mean that a crossing is
"marked", but do not clearly communicate this fact to mappers, leading to
all kinds of data issues and difficulties in explaining mapping to
newcomers (and therefore getting good data).

While the proposal itself goes into detail about why crossing=marked is a
good idea and other tags are a bad idea, this is the short version:
  - crossing=* values are not truly orthogonal and this needs to be
addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are not
truly orthogonal descriptors. This proposal is part of a larger effort to
improve the values used for pedestrian crossings, but does not depend on
that effort.
  - There is fragmentation in tag usage for marked crossings between
"zebra" and "uncontrolled".
 - I believe that a significant portion of this fragmentation can be
attributed to the unconventional use of the term "uncontrolled", which is
technically incorrect, extremely jargon-y, and currently describes *two*
things whereas other values for 'crossing' describe just one.
  - crossing=marked is direct and clear about its meaning and use cases.
  - crossing=marked is already in use and supported by various editors,
including being the default in iD and an auto-filled option in JOSM.
  - crossing=marked has the potential for subtag uses, e.g. marked=zebra.
  - We can address fragmentation via machine edits and/or reviews using
MapRoulette.

The primary goal of this proposal is to create truly orthogonal,
descriptive, and intuitive tag values for markings on crossings. If related
proposals are also accepted, the only values used on crossings would be
marked/unmarked/no, with other attributes being namespaced tags
(crossing:island, crossing:signals, etc), but acceptance of this proposal
does not depend on those other proposals becoming accepted.

Please let me know any concerns you have regarding the impacts of this
proposal or semantics. I'd like to make any ambiguities clear and have the
proposal page be as thorough as possible.

Best,

Nick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals

Hello fellow tagging enthusiasts!

This proposal suggests the deprecation of crossing=traffic_signals and
replacing it with crossing:signals=yes, i.e. placing pedestrian
signalization on a dedicated tag that is separate from crossing=* values.

The current values for the crossing=* tag are not orthogonal:
crossing=traffic_signals is not actually orthogonal to
crossing=uncontrolled or crossing=unmarked, for example. This presents a
significant challenge to understanding the meaning of these tags and in
creating properly descriptive tags on map elements. For example, let's take
three attributes of a pedestrian crossing: signalization for pedestrians,
signalization for traffic, and markings on the ground. What do
crossing=uncontrolled/unmarked/traffic_signals say about these scenarios?

crossing=uncontrolled:
  - signalization for pedestrians is undefined
  - signalization for traffic *should* not exist, but due to confusions
over the meaning of the tag, might.
  - markings are implied, but due to confusions over the meaning of the
tag, might not not.

crossing=unmarked:
  - signalization for pedestrians is undefined
  - signalization for traffic is undefined
  - there are no markings

crossing=traffic_signals
  - signalization for pedestrians: yes
  - signalization for traffic is undefined
  - markings are undefined

So, you can see the problem: the values are describing completely different
things and the rest is ambiguous.

I'm interested in any/all feedback regarding this tag proposal! Thank you
for your time!

Best,

Nick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Volker Schmidt]

Two spontanous reactions

1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)

2) please  define the terms you use.
What is "signalization"?
I know these terms: traffic signals, road marking (=horizontal traffic
signs), signs (=vertical traffic signs), but signalization?








Virus-free.
www.avast.com

<#m_3715203604143881037_m_5214136548138821738_m_4990119247789359937_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


crossing=uncontrolled:
>   - signalization for pedestrians is undefined
>   - signalization for traffic *should* not exist, but due to confusions
> over the meaning of the tag, might.
>   - markings are implied, but due to confusions over the meaning of the
> tag, might not not.
>
> crossing=unmarked:
>   - signalization for pedestrians is undefined
>   - signalization for traffic is undefined
>   - there are no markings
>
> crossing=traffic_signals
>   - signalization for pedestrians: yes
>   - signalization for traffic is undefined
>   - markings are undefined
>
> So, you can see the problem: the values are describing completely
> different things and the rest is ambiguous.
>
> I'm interested in any/all feedback regarding this tag proposal! Thank you
> for your time!
>
> Best,
>
> Nick
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


Virus-free.
www.avast.com

<#m_3715203604143881037_m_5214136548138821738_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Tobias Knerr]

On 07.05.19 23:08, Nick Bolten wrote:
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.

I agree with separating orthogonal characteristics of crossings into
different tags. A single tag cannot easily express both the presence of
traffic signs and the presence of markings.

However, it seems odd to "demote" traffic signals to a sub-tag when
their presence or absence is perhaps the biggest influence on the
crossing's overall character.

In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using
a separate tag for the markings instead. We need a tag for the _type_ of
the markings anyway (as different patterns for marked crossings can have
entirely different legal meanings in some jurisdictions), and we can use
that same tag for presence/absence by also allowing yes/no values.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> 1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)

This proposal does not deprecate crossing=uncontrolled.

For the latter: why not? The tag is, in technical terms, garbage, and other
tags in relatively high use have been deprecated before.

> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
signs), signs (=vertical traffic signs), but signalization?

Visual displays for the specified form of traffic. Signalization for
automotive traffic might be stop signs or stop lights. Signalization for
pedestrians might be a crossing signal / do not cross sign.

Best,

Nick

On Tue, May 7, 2019 at 2:47 PM Volker Schmidt  wrote:

> Two spontanous reactions
>
> 1) You cannot deprecate a tagging that is used 750k times
> (crossing=uncontrolled) or 570k times (crossing=traffic_signals)
>
> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
> signs), signs (=vertical traffic signs), but signalization?
>
>
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_m_4990119247789359937_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> crossing=uncontrolled:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic *should* not exist, but due to confusions
>> over the meaning of the tag, might.
>>   - markings are implied, but due to confusions over the meaning of the
>> tag, might not not.
>>
>> crossing=unmarked:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic is undefined
>>   - there are no markings
>>
>> crossing=traffic_signals
>>   - signalization for pedestrians: yes
>>   - signalization for traffic is undefined
>>   - markings are undefined
>>
>> So, you can see the problem: the values are describing completely
>> different things and the rest is ambiguous.
>>
>> I'm interested in any/all feedback regarding this tag proposal! Thank you
>> for your time!
>>
>> Best,
>>
>> Nick
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> However, it seems odd to "demote" traffic signals to a sub-tag when their
presence or absence is perhaps the biggest influence on the crossing's
overall character.

I agree that it's not ideal to have to make these kinds of choices about
"demoting". In case it's helpful, this is my original rationale:

1) To have properly orthogonal values for the crossing key, it should
describe one category of things, like markings or signals. This means
"demoting" all but one feature to other tags (hopefully namespaced) like
crossing:signals. Imagine if highway=primary originally implied 4 lanes as
well as "major, separated high-speed street" and only later did we have to
separate out highway=primary from lanes=4. We agree on this, just thought
it was an important point.

2) Which category should be used as the primary value of crossing? I went
with the marking because it is, by far, the most-tagged value:
uncontrolled/zebra/marked/unmarked account for 3 times as many tags as
traffic_signals.

> In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using a
separate tag for the markings instead. We need a tag for the _type_ of the
markings anyway (as different patterns for marked crossings can have
entirely different legal meanings in some jurisdictions), and we can use
that same tag for presence/absence by also allowing yes/no values.

Would it be fair to say you're suggesting something along the lines of
crossing:marking=*, where * can be yes, no, or a marking type? You make a
good point about the simplicity of avoiding a subtag for markings.

Aside from frequency of tagging, the biggest reason I've prioritized
markings as the primary value is that marked crossings are starkly
different from unmarked ones from many different perspectives:

- Unmarked crossings are abstract "fictions" representing where an
individual might cross the street, marked crossings are identifiable from
imagery.
- Because unmarked crossings are "fictions", they are only suggested places
to cross, according to the mapper. In contrast, marked crossings are
"official".
- Marked crossings confer safety and right-of-way information to both
pedestrian and street traffic: this is a place where pedestrians can cross,
so watch out.
- Marked crossings are one of the few pedestrian spaces that can be
straightforwardly considered as a linear feature: it connects spaces across
a street.
- Marked crossings tend to have legal implications, as you note.

Thus, when someone asks me, "what type of crossing is this?", my gut
reaction is to say "a crosswalk" or "not marked", potentially followed up
by a marking type if applicable. A marked crosswalk is a real,
"on-the-ground" thing whereas unmarked is a workaround for needing to
representing and use 2D spaces as lines.

I'd be curious to find some survey data regarding the importance of
pedestrian features that included crosswalks and signals. I could've sworn
I knew of one, but am having trouble finding it.

Best,

Nick

On Tue, May 7, 2019 at 3:08 PM Tobias Knerr  wrote:

> On 07.05.19 23:08, Nick Bolten wrote:
> > This proposal suggests the deprecation of crossing=traffic_signals and
> > replacing it with crossing:signals=yes, i.e. placing pedestrian
> > signalization on a dedicated tag that is separate from crossing=* values.
>
> I agree with separating orthogonal characteristics of crossings into
> different tags. A single tag cannot easily express both the presence of
> traffic signs and the presence of markings.
>
> However, it seems odd to "demote" traffic signals to a sub-tag when
> their presence or absence is perhaps the biggest influence on the
> crossing's overall character.
>
> In comparison, it seems somewhat less important whether a signalled
> crossing also has painted markings on the road. So I would suggest using
> a separate tag for the markings instead. We need a tag for the _type_ of
> the markings anyway (as different patterns for marked crossings can have
> entirely different legal meanings in some jurisdictions), and we can use
> that same tag for presence/absence by also allowing yes/no values.
>
> Tobias
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Dave F via Tagging]

On 07/05/2019 22:46, Volker Schmidt wrote:

Two spontanous reactions

1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)


In principle, why do you think it can't be performed?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging