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

[Nick Bolten]

Hello everyone, this is a late addition to this thread (I'll start a new
one soon after I improve the proposal page), but I want to give an example
of a crossing that has lights but no markings that is traversed by
(guessing) thousands of people per day:
https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
Despite having a lot of interesting art, there is no way to distinguish the
crossing location from non-crossing locations via markings on the ground.

This is topical, as crossing=traffic_signals is often claimed to imply
crossing=marked.

On Tue, May 7, 2019 at 2:08 PM Nick Bolten  wrote:

> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> I’ve read that whole previous discussion, and from my point of view it
was just a whole bunch of completely useless noise, with everyone telling
you that you aren’t making sense and you ignoring it and bulldozing your
way forward.

Ah, and incidentally, I'd say I have the exact opposite problem: I reply to
just about every single thread, quoting just about everything and
attempting to take it into consideration.

Let's try to make this a productive discussion, not one laden with (for
some reason primarily German-speaking-originating) disdain.

On Sun, May 19, 2019 at 10:20 PM Nick Bolten  wrote:

> > if you are having trouble where people are “fixing” your mapping, then
> draw a way with no highway=* tag put crossing=no on it.
>
> Is this an established strategy? I'd be happy to promote it + update the
> wiki if it's communally supported. If it's not necessarily an established
> strategy, I'd also be interested in making a new thread about it in the
> hopes of making it one.
>
> On Sun, May 19, 2019 at 10:09 PM John Willis via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>>
>> On May 20, 2019, at 9:52 AM, Nick Bolten  wrote:
>>
>> Unfortunately, people will draw the crossing if there isn't negative
>> information there saying to stop doing that, e.g. crossing=no
>>
>>
>> if you are having trouble where people are “fixing” your mapping, then
>> draw a way with no highway=* tag
>>
>> put crossing=no on it. that should at least read as “mapped” to imagery
>> tracers out there.
>>
>> similar to demolished=* on a line mapped over a bridge visible on imagery
>> that has actually been destroyed.
>>
>> Javbw
>> ___
>> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> I’ve read that whole previous discussion, and from my point of view it
was just a whole bunch of completely useless noise, with everyone telling
you that you aren’t making sense and you ignoring it and bulldozing your
way forward.

Well, so much for community discussion. I will make appeals to those
interested in hearing other points of view.

On Sun, May 19, 2019 at 10:09 PM  wrote:

> I’ve read that whole previous discussion, and from my point of view it was
> just a whole bunch of completely useless noise, with everyone telling you
> that you aren’t making sense and you ignoring it and bulldozing your way
> forward.
>
>
>
> *From:* Nick Bolten 
> *Sent:* Monday, 20 May 2019 10:48
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] "Unambiguous crossings" proposals and related
> questions
>
>
>
> It's a little disappointing to see these points rehashed given the lengthy
> recent discussions, but at the risk of creating a new massive thread I'd
> like to clear some things up.
>
>
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> if you are having trouble where people are “fixing” your mapping, then
draw a way with no highway=* tag put crossing=no on it.

Is this an established strategy? I'd be happy to promote it + update the
wiki if it's communally supported. If it's not necessarily an established
strategy, I'd also be interested in making a new thread about it in the
hopes of making it one.

On Sun, May 19, 2019 at 10:09 PM John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
>
> On May 20, 2019, at 9:52 AM, Nick Bolten  wrote:
>
> Unfortunately, people will draw the crossing if there isn't negative
> information there saying to stop doing that, e.g. crossing=no
>
>
> if you are having trouble where people are “fixing” your mapping, then
> draw a way with no highway=* tag
>
> put crossing=no on it. that should at least read as “mapped” to imagery
> tracers out there.
>
> similar to demolished=* on a line mapped over a bridge visible on imagery
> that has actually been destroyed.
>
> Javbw
> ___
> 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] "Unambiguous crossings" proposals and related questions

[osm.tagging]

I’ve read that whole previous discussion, and from my point of view it was just 
a whole bunch of completely useless noise, with everyone telling you that you 
aren’t making sense and you ignoring it and bulldozing your way forward.

 

From: Nick Bolten  
Sent: Monday, 20 May 2019 10:48
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] "Unambiguous crossings" proposals and related questions

 

It's a little disappointing to see these points rehashed given the lengthy 
recent discussions, but at the risk of creating a new massive thread I'd like 
to clear some things up.

 

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

What do you mean with "feature"? Do you mean the whole proposal? Do you mean the "feature" subtag ( changing_table:features )? Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 19. May 2019, at 20:31, Valor Naram  wrote:> > I have rewritten my proposal to hopefully please the critic. Please check it out: https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table> > Author: Valor Naram> Definition: A tag to mark the possibility to change the baby's nappy. It makes tagging of changing tables possible. See https://en.oxforddict ionaries.com/definition/changing_table for the definition.IMHO you should provide a definition for the feature in the proposal and be explicit if this is for a “possibility to change the baby’s nappy” or more specifically a “changing table”. Cheers, Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

Hey Markus,

This is a very good example that I somehow forgot to add to any of my
replies / the wiki. Thank you for reminding me!

There are certainly many crossings that have pedestrian signals but are
tagged with the flavor du jour of crossing=marked because the latter can be
mapped from aerial imagery and the former has to be verified on the ground.

On Sun, May 19, 2019 at 10:55 AM Markus  wrote:

> On Sun, 19 May 2019 at 18:32,  wrote:
> >
> > Personally, I can not remember having ever seen, in my whole life, a
> signal controlled pedestrian crossing that does not have road markings,
> excluding cases where there are temporarily no road markings at all because
> they haven't been painted yet after the road has just been laid down or
> resurfaced.
> >
> > [...]
> >
> > crossing=uncontrolled and crossing=zebra have been used a combined 1.25
> million times. In practical usage, they mean exactly the same thing, and
> they have widespread software support already. Trying to replace them with
> a 3rd value that still means exactly the same things is a classical case of
> https://xkcd.com/927/
>
> While it may be true that there aren't any signal controlled
> pedestrian crossing without road markings, the problem with
> zebra/marked using the same key as traffic_signals is that mappers
> (those that don't visit the place, don't have local knowledge and
> likely haven't read the documentation) see a marked crossing on the
> aerial imagery and tag it crossing=zebra/marked even if there are
> traffic lights -- sometimes they even retag a crossing=traffic_signals
> to crossing=zebra/marked. I've already corrected dozens of them, but
> there are constantly new ones being wrongly added or retagged. While
> crossing=unmarked/{uncontrolled|zebra|marked}/traffic_signals
> theoretically may work, it doesn't in practice. I think that only
> moving traffic lights and road markings to separate keys will solve
> this problem.
>
> Regards
>
> Markus
>
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> if you do not draw the ways for people to cross, then they don’t exist,
right?

Unfortunately, people will draw the crossing if there isn't negative
information there saying to stop doing that, e.g. crossing=no. I'd add
crossing=no to that particular place in addition to your recommendations.
This is a bit like the situation where mappers add buildings that don't
exist from aerial imagery and diligent local mappers have to keep deleting
them / adding notes / using a tagging scheme just to say, "this doesn't
exist".

If that crossing location is illegal, which I would hope it is simply due
to being so dangerous, even more reason to add crossing=no.

On Sun, May 19, 2019 at 5:02 PM John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> On May 20, 2019, at 6:57 AM, Graeme Fitzpatrick 
> wrote:
>
> Draw the fence
>
>
>
> Draw the fence.
>
> access=no
>
>
> if you do not draw the ways for people to cross, then they don’t exist,
> right?
>
> where people have made narrow footpaths (without breaking barriers, such
> as paths over a hill between two formal ways), then highway=path
> surface=ground informal=yes is how I tag those, though this might not be
> correct.
>
> But in this instance, you are talking about a barrier being ignored and
> jumped. simply do not map the crossings.
>
> javbw.
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

It's a little disappointing to see these points rehashed given the lengthy
recent discussions, but at the risk of creating a new massive thread I'd
like to clear some things up.

> "The "traffic_signals" namespace is used to describe both vehicular
traffic signals and pedestrian/bicycle traffic signals, to everyone's
confusion."
> This statement is simply completely factually wrong.
> a) traffic_signals is the *value* here, not the name of the tag

Yes, that was a silly typo/flub. It's been fixed.

> b) there are 2 distinct tags to describe the presence of traffic signals
for the road way and foot/cycle way:
> highway=traffic_signals for signals controlling traffic on the road
> crossing=traffic_signals for signals controlling crossing pedestrians

If we acknowledge the typo, this isn't actually a contradiction. It's still
the same value being used for both, everyone is still confused, and believe
it or not, many in the previous thread explicitly stated that
crossing=traffic_signals is not solely about signals controlling
pedestrians, but implies signals controlling street traffic as well.

> "To make matters worse, it forces mappers to choose between tagging a
crossing's markings, [...], or whether it has signalization."

> Personally, I can not remember having ever seen, in my whole life, a
signal controlled pedestrian crossing that does not have road markings (...)

Have you done an audit? It's easy to miss these things if you aren't
directly concerned about them. There are several right in downtown Seattle,
Washington by Westlake Park, if you want to see an example. Plenty of neat
designs on the ground, but none are actually saying where the crossing is.
I've seen the situation in New York and Montana, as well.

> And even if there should really be signal controlled crossings that on
purpose do not have any road markings, I would consider that to be
basically completely irrelevant (...)

I find this attitude surprising. Why not ask if anyone finds it relevant?
This map isn't just for any single person.

- People with low vision use crosswalk markings to help navigate.
- Marked crossings assist in establishing a pedestrian space where car
traffic should not stop (which is one of the reasons they are installed
even when there are signals).
- Marked crossings increase pedestrian safety.

I, and many others, want to know when a crossing is marked or not.

> Deprecating a tag that has been used almost 60 times and has
widespread software support, just to replace it with a different tag that
means exactly the same seems somewhat insane to me, and while I can't speak
for anyone else, I can guarantee to always vote no for this.

I would urge you to wait for responses before making up your mind.

As can be seen in the previous threads, none of the tags I've proposed mean
"the exact same thing" as what currently exists, because the meaning and
tagging of what exists is in no way agreed upon by even long-term expert
mappers. crossing=uncontrolled has the unfortunate reality of not actually
meaning "uncontrolled" and crossing="traffic_signals" says nothing about
markings (in addition to confusion about what it even describes about
signals).

Concerning the number of times the tag is used, consider that there are
33,000 marked crossings in my city (Seattle) alone. We have not mapped
anywhere near enough marked crossings/signaled crossings: they are
effectively unmapped for the vast majority of locations. Now is the perfect
time to deprecate any bad tags: there is intense interest in mapping these
typically unmapped features, but I can barely even tell people what to do
in terms of tags. I've also tried to figure out what data consumers even do
with the existing tags, particular those on nodes. I have found very few
uses, which would make sense given the shoddy coverage: you certainly can't
depend on them being mapped where they exist. Here's all that I know of:

- Adding a delay to car routing software, as the car might have to stop.

- Locally-scoped projects showing visual metaphors for "traffic signaled"
and "uncontrolled/marked/whatever" on a base map.

- A 3D renderer that shows continental crossings wherever
crossing=uncontrolled exists on a node.

I'm always interested to hear about more examples, but it's clear that
coverage is poor, which will limit applications.

> I can agree with this one, but it's essentially a non-issue as this has
already been done.

It's a successful example of orthogonalizing pedestrian crossing
information away from this catch-all namespace.

> crossing=uncontrolled and crossing=zebra have been used a combined 1.25
million times. In practical usage, they mean exactly the same thing, and
they have widespread software support already. Trying to replace them with
a 3rd value that still means exactly the same things is a classical case of
https://xkcd.com/927/

That comic is literally linked in the proposal about this very issue.

In practical usage, they clearly don't mean the 

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Martin Koppenhoefer]

sent from a phone

> On 20. May 2019, at 02:00, John Willis via Tagging 
>  wrote:
> 
> Draw the fence. 


+1, I would also suggest for fences and walls to tag the height.


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

[Tagging] tagging large farm complexes

[John Willis via Tagging]

I am currently mapping the Japanese imperial stock farm. 

https://www.openstreetmap.org/way/527800117 


it is a large farm complex, operated by the imperial household of Japan (the 
emperor’s family), with different farmyards for various farm animals, with a 
lot of pasture, farmland, and amenties for visitors (a guest house, staff 
housing, an office, a park, parking lots, etc). 

to me the individual areas are obviously farmyards, and the other areas are 
easily mappable - but what about the entire landuse? is it  commercial? 
farmyard?

I currently tagged as commercial, but I have the suspicion that is wrong - or 
every farm in Japan would be landuse=commercial, but this is like a weird 
tourist-farm-zoo kind of place. 

any suggestions for the proper encompassing tagging? 


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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[John Willis via Tagging]

> On May 20, 2019, at 6:57 AM, Graeme Fitzpatrick  wrote:
> 
> Draw the fence


Draw the fence. 

access=no 


if you do not draw the ways for people to cross, then they don’t exist, right?

where people have made narrow footpaths (without breaking barriers, such as 
paths over a hill between two formal ways), then highway=path surface=ground 
informal=yes is how I tag those, though this might not be correct. 

But in this instance, you are talking about a barrier being ignored and jumped. 
simply do not map the crossings. 

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Warin]

On 20/05/19 06:45, Graeme Fitzpatrick wrote:



On Mon, 20 May 2019 at 04:32, Valor Naram > wrote:


Hey guys,

my first proposal has been rejected for some reason. I have
rewritten my proposal to hopefully please the critic. Please check
it out: 



https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

Corrected typo in link address!

What changes have you made to the proposal?

Would be handy to have a section there to show what they were




I think there has been a reduction in  the number of sub tags. But I 
don't think the reduction has gone far enough to appease the 'no' voters.


I think the proposal should only be about replacing the existing tag 
diaper=* with change_table=*. Nothing else, just that and see if that 
passes .. there are some who will object to just that and it could be a 
close call on just getting the replacement passed.


Good luck Valor.



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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Graeme Fitzpatrick]

On Mon, 20 May 2019 at 02:32,  wrote:

Pretty well agree with everything you said, Thorsten, but I'd like to
clarify one point thanks.

no - there is no crossing possible/legal here
>

Understand the idea, but how do we actually use it?

The fence here
https://www.google.com/maps/@-28.0725198,153.4441123,3a,75y,182.92h,70.96t/data=!3m6!1e1!3m4!1spYYE39O0IZ2ymA7Jh-D-5g!2e0!7i13312!8i6656
is
"supposed" to stop people crossing the highway (it doesn't!) & extends for
several k, broken only by cross-streets, turning lanes & pedestrian
crossings.

So how do we mark crossing=no along this entire stretch?

Draw the fence in & add a crossing tag to that? Would anything / anyone
read it?

Crossing=no added to the road itself? Same thing applies.

Any other thoughts? (Or is there an obvious, simple solution that I'm
missing :-))

Thanks

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Graeme Fitzpatrick]

On Mon, 20 May 2019 at 04:32, Valor Naram  wrote:

> Hey guys,
>
> my first proposal has been rejected for some reason. I have rewritten my
> proposal to hopefully please the critic. Please check it out:


https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

Corrected typo in link address!

What changes have you made to the proposal?

Would be handy to have a section there to show what they were

Thanks

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Martin Koppenhoefer]

sent from a phone

> On 19. May 2019, at 20:31, Valor Naram  wrote:
> 
> I have rewritten my proposal to hopefully please the critic. Please check it 
> out: https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table
> 
> Author: Valor Naram
> Definition: A tag to mark the possibility to change the baby's nappy. It 
> makes tagging of changing tables possible. See https://en.oxforddict 
> ionaries.com/definition/changing_table for the definition.


IMHO you should provide a definition for the feature in the proposal and be 
explicit if this is for a “possibility to change the baby’s nappy” or more 
specifically a “changing table”. 


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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Martin Koppenhoefer]

sent from a phone

> On 19. May 2019, at 18:30,  
>  wrote:
> 
> "The "traffic_signals" namespace is used to describe both vehicular traffic 
> signals and pedestrian/bicycle traffic signals, to everyone's confusion."
> 
> This statement is simply completely factually wrong.
> 
> a) traffic_signals is the *value* here, not the name of the tag
> 
> b) there are 2 distinct tags to describe the presence of traffic signals for 
> the road way and foot/cycle way:
> 
> highway=traffic_signals for signals controlling traffic on the road
> crossing=traffic_signals for signals controlling crossing pedestrians
> 
> "To make matters worse, it forces mappers to choose between tagging a 
> crossing's markings, [...], or whether it has signalization."
> 
> Personally, I can not remember having ever seen, in my whole life, a signal 
> controlled pedestrian crossing that does not have road markings, excluding 
> cases where there are temporarily no road markings at all because they 
> haven't been painted yet after the road has just been laid down or resurfaced.
> 
> And even if there should really be signal controlled crossings that on 
> purpose do not have any road markings, I would consider that to be basically 
> completely irrelevant. The presence of signals that control traffic and 
> pedestrian movement supersedes the meaning any road markings might have. If a 
> signal controlled crossing has road markings or not does not in any way 
> change its operation.
> 
> Deprecating a tag that has been used almost 60 times and has widespread 
> software support, just to replace it with a different tag that means exactly 
> the same seems somewhat insane to me, and while I can't speak for anyone 
> else, I can guarantee to always vote no for this.
> 
> "Replacing crossing=island" 
> 
> I can agree with this one, but it's essentially a non-issue as this has 
> already been done. At most the wiki might need slight editing to make it more 
> clear that the use of crossing=island has been deprecated.
> 
> "Replacing crossing=uncontrolled and crossing=zebra with crossing=marked"
> 
> crossing=uncontrolled and crossing=zebra have been used a combined 1.25 
> million times. In practical usage, they mean exactly the same thing, and they 
> have widespread software support already. Trying to replace them with a 3rd 
> value that still means exactly the same things is a classical case of 
> https://xkcd.com/927/
> 
> Looking at taginfo, there are already 168281 cases of crossing=marked right 
> now, so the unfortunate reality is that we already have the case of 3 
> different values meaning the same thing and no matter how much you try to 
> dictate the usage of a particular one by fiddling with the wiki, it's 
> unlikely that there will ever be a day when all 3 aren't in widespread use 
> synonymously.
> 
> As such the best that can be done is to slightly adjust the wiki to document 
> the reality that all 3 values are used synonymously.
> 
> All this basically leaves the crossing key with the following possible values:
> 
> no - there is no crossing possible/legal here
> 
> unmarked - there are no road markings or traffic signals here, but this is a 
> place where people are generally (legally) cross the road, e.g. because of 
> lowered kerbs, or because the sidewalk on one side of the road stops here, or 
> some other indication that this is a commonly used crossing point.
> 
> uncontrolled/zebra/marked - there are road markings, but no signals that 
> control traffic flow, that make it clear to both road and pedestrian traffic 
> that this is a designated crossing point
> 
> traffic_signals - there are traffic signals here that control traffic flow, 
> it is extremely likely that there are also road markings, but their presence 
> or absence is irrelevant as it would not change how the crossing operates
> 
> I think you'll find that any proposal that tries to completely throw over 
> this well-established tagging scheme is doomed to failure


full quote, +1
thank you for taking the time to formulate a thorough reply 

just one remark: crossing=zebra clearly means a zebra crossing (implications 
for traffic may vary according to the jurisdiction), crossing=marked means 
_any_ marked crossing. Both will imply (from my understanding) that there are 
no traffic lights (for pedestrians), but the meaning may not be identical.

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

[Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

Hey guys,

my first proposal has been rejected for some reason. I have rewritten my 
proposal to hopefully please the critic. Please check it out: 
https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table

Author: Valor Naram
Definition: A tag to mark the possibility to change the baby's nappy. It makes 
tagging of changing tables possible. See https://en.oxforddict 
ionaries.com/definition/changing_table for the definition.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Markus]

On Sun, 19 May 2019 at 18:32,  wrote:
>
> Personally, I can not remember having ever seen, in my whole life, a signal 
> controlled pedestrian crossing that does not have road markings, excluding 
> cases where there are temporarily no road markings at all because they 
> haven't been painted yet after the road has just been laid down or resurfaced.
>
> [...]
>
> crossing=uncontrolled and crossing=zebra have been used a combined 1.25 
> million times. In practical usage, they mean exactly the same thing, and they 
> have widespread software support already. Trying to replace them with a 3rd 
> value that still means exactly the same things is a classical case of 
> https://xkcd.com/927/

While it may be true that there aren't any signal controlled
pedestrian crossing without road markings, the problem with
zebra/marked using the same key as traffic_signals is that mappers
(those that don't visit the place, don't have local knowledge and
likely haven't read the documentation) see a marked crossing on the
aerial imagery and tag it crossing=zebra/marked even if there are
traffic lights -- sometimes they even retag a crossing=traffic_signals
to crossing=zebra/marked. I've already corrected dozens of them, but
there are constantly new ones being wrongly added or retagged. While
crossing=unmarked/{uncontrolled|zebra|marked}/traffic_signals
theoretically may work, it doesn't in practice. I think that only
moving traffic lights and road markings to separate keys will solve
this problem.

Regards

Markus

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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[osm.tagging]

"The "traffic_signals" namespace is used to describe both vehicular traffic 
signals and pedestrian/bicycle traffic signals, to everyone's confusion."

This statement is simply completely factually wrong.

a) traffic_signals is the *value* here, not the name of the tag

b) there are 2 distinct tags to describe the presence of traffic signals for 
the road way and foot/cycle way:

highway=traffic_signals for signals controlling traffic on the road
crossing=traffic_signals for signals controlling crossing pedestrians

"To make matters worse, it forces mappers to choose between tagging a 
crossing's markings, [...], or whether it has signalization."

Personally, I can not remember having ever seen, in my whole life, a signal 
controlled pedestrian crossing that does not have road markings, excluding 
cases where there are temporarily no road markings at all because they haven't 
been painted yet after the road has just been laid down or resurfaced.

And even if there should really be signal controlled crossings that on purpose 
do not have any road markings, I would consider that to be basically completely 
irrelevant. The presence of signals that control traffic and pedestrian 
movement supersedes the meaning any road markings might have. If a signal 
controlled crossing has road markings or not does not in any way change its 
operation.

Deprecating a tag that has been used almost 60 times and has widespread 
software support, just to replace it with a different tag that means exactly 
the same seems somewhat insane to me, and while I can't speak for anyone else, 
I can guarantee to always vote no for this.

"Replacing crossing=island" 

I can agree with this one, but it's essentially a non-issue as this has already 
been done. At most the wiki might need slight editing to make it more clear 
that the use of crossing=island has been deprecated.

"Replacing crossing=uncontrolled and crossing=zebra with crossing=marked"

crossing=uncontrolled and crossing=zebra have been used a combined 1.25 million 
times. In practical usage, they mean exactly the same thing, and they have 
widespread software support already. Trying to replace them with a 3rd value 
that still means exactly the same things is a classical case of 
https://xkcd.com/927/

Looking at taginfo, there are already 168281 cases of crossing=marked right 
now, so the unfortunate reality is that we already have the case of 3 different 
values meaning the same thing and no matter how much you try to dictate the 
usage of a particular one by fiddling with the wiki, it's unlikely that there 
will ever be a day when all 3 aren't in widespread use synonymously.

As such the best that can be done is to slightly adjust the wiki to document 
the reality that all 3 values are used synonymously.

All this basically leaves the crossing key with the following possible values:

no - there is no crossing possible/legal here

unmarked - there are no road markings or traffic signals here, but this is a 
place where people are generally (legally) cross the road, e.g. because of 
lowered kerbs, or because the sidewalk on one side of the road stops here, or 
some other indication that this is a commonly used crossing point.

uncontrolled/zebra/marked - there are road markings, but no signals that 
control traffic flow, that make it clear to both road and pedestrian traffic 
that this is a designated crossing point

traffic_signals - there are traffic signals here that control traffic flow, it 
is extremely likely that there are also road markings, but their presence or 
absence is irrelevant as it would not change how the crossing operates

I think you'll find that any proposal that tries to completely throw over this 
well-established tagging scheme is doomed to failure.

> -Original Message-
> From: Markus 
> Sent: Monday, 20 May 2019 00:37
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] "Unambiguous crossings" proposals and related
> questions
> 
> Hi Nick, hi everyone,
> 
> I welcome these proposals (crossing=marked, crossing:signals=* and
> footway=island) [1] to bring order to the pedestrian crossing
> tagging.
> Thank you, Nick, for your efforts so far!
> 
> I have two questions, not about the proposals themselves, but about
> pedestrian crossing tagging in general:
> 
>   * When the crossing type is tagged on the way (e.g.
> highway=footway
> + footway=crossing + crossing=marked + crossing:signals=yes), should
> the crossing type also be tagged (duplicated) on the crossing node
> or are routers able to get that information from the crossing ways?
> 
>   * Should the road be split for short refuge islands into two one-
> way ways? This would result in unusual maps, especially at
> crossroads
> (example: [2]).
> 
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_cr
> ossings
> [2]:
> https://wiki.openstreetmap.org/wiki/File:Crossroads_with_traffic_isl
> ands.png
> 
> Regards
> 
> Markus
> 
> 

[Tagging] "Unambiguous crossings" proposals and related questions

[Markus]

Hi Nick, hi everyone,

I welcome these proposals (crossing=marked, crossing:signals=* and
footway=island) [1] to bring order to the pedestrian crossing tagging.
Thank you, Nick, for your efforts so far!

I have two questions, not about the proposals themselves, but about
pedestrian crossing tagging in general:

  * When the crossing type is tagged on the way (e.g. highway=footway
+ footway=crossing + crossing=marked + crossing:signals=yes), should
the crossing type also be tagged (duplicated) on the crossing node or
are routers able to get that information from the crossing ways?

  * Should the road be split for short refuge islands into two one-way
ways? This would result in unusual maps, especially at crossroads
(example: [2]).

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_crossings
[2]: 
https://wiki.openstreetmap.org/wiki/File:Crossroads_with_traffic_islands.png

Regards

Markus

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

Re: [Tagging] Wiki changes for police tag

[Martin Koppenhoefer]

sent from a phone

> On 19. May 2019, at 13:26, marc marc  wrote:
> 
> indeed but putting the tag not on the building currently lost the info 
> "this poi use the whole building"
> adding a polygone with the same outer doesn't solve it (a shop may use a 
> level and not the whole building


if this is your concern you could be explicit about the levels, both for the 
building and for the Poi.

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

Re: [Tagging] Wiki changes for police tag

[marc marc]

Le 19.05.19 à 11:29, Martin Koppenhoefer a écrit :
> 1. differentiation of building and user (distinct objects also when the whole 
> building is occupied by one user)

indeed but putting the tag not on the building currently lost the info 
"this poi use the whole building"
adding a polygone with the same outer doesn't solve it (a shop may use a 
level and not the whole building
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Saeed Hubaishan]

Adding ramadan as  is good.

I also  suggest adding optional [@calendar] to date range rules for non 
Gregorian dates and using month number instead of month abber name for example:

Sa-Th 09:00-21:00; 09/01-09/30 @hijri 20:00-03:00


الحصول على Outlook for Android


From: Simon Poole 
Sent: Saturday, May 18, 2019 1:59:39 PM
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Opening hours syntax for non Gregorian calendar



As I've pointed out before the one thing that is unproblematic to add are more 
variable date public holidays, right now there is only easter defined,  adding 
ramadan for example would be no problem.

Further expressing a rule is one thing, evaluating it is a something else, and 
adding some kind of "context" value to help in the later (for example a time 
zone value as has been suggested previously)  could potentially work.

Simon

Am 18.05.2019 um 12:34 schrieb Phake Nick:
That doesn't seems to solve the problem that would occur. For instance, how to 
represent the first Sunday (a feature in Gregorian calendar) after Chinese 
traditional ceremony X (a feature in Chinese traditional calendar) in the 
opening time syntax, if they're split up for "simplicity"? What about when the 
opening time also cover non-holiday festivals that only occurs according to 
either calendars?

On 2019-05-18 Sat 04:50, Paul Allen 
mailto:pla16...@gmail.com>> wrote:
Problem of splitting: what if a mapper gives the opening times in both 
calendar_X and calendar_Y
and they disagree?  Consumers will have to have rules like: in country_Z use 
calendar_X if given,
otherwise use standard opening_hours if given, otherwise use calendar_Y if 
given, otherwise
pick at random from what is left.

--
Paul

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



___
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] Wiki changes for police tag

[Martin Koppenhoefer]

sent from a phone

> On 19. May 2019, at 10:25, Jan S  wrote:
> 
> I'd think so, as long as the police (or other government offices) occupy the 
> entire building. Otherwise it would just be a node on the building.
> 
> Could anyone take that into the wiki?


while it is often done like this, there are also alternatives which are cleaner 
in the way it is represented:

1. differentiation of building and user (distinct objects also when the whole 
building is occupied by one user)

2. polygon for the user rather than a node (if you know it well). This gives a 
whole lot more of information (size, shape, orientation) and allows to add 
other things inside.

Btw: other possibilities would be police facilities consisting of no building 
or more than one building, or a building with a dedicated area around it 
(‚grounds‘).

This is a general consideration and not specifically referring to police 
facilities. Not sure we should add this to the wiki for each and every feature, 
or maybe just link it?

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

Re: [Tagging] Wiki changes for police tag

[Jan S]

Am 19. Mai 2019 06:10:21 MESZ schrieb Graeme Fitzpatrick 
:

>Would the police then work under building=government (which was
>discussed a
>while back) + police=xxx?

I'd think so, as long as the police (or other government offices) occupy the 
entire building. Otherwise it would just be a node on the building.

Could anyone take that into the wiki? I won't find the time soon...

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