[Tagging] RFC - Hazards - Pedestrian hazard

[Brian M. Sperlongano]

The hazard proposal [1] currently proposes hazard=cyclists as a way to tag
a signed area in which motorists should watch for or share the road with
cyclists.  Note that this is explicitly different from a cyclist crossing,
which is currently covered by highway=crossing.

It was suggested by a commenter on the talk page that hazard=pedestrian
(which has a few hundred usages) should be added as well, to indicate a
hazard of pedestrians sharing the road with cars.  Is anyone aware of
examples of this that are NOT pedestrian *crossings*?  The searching I've
done for pedestrian hazards all seem to turn up with crosswalk signs, which
I feel are out of scope for the hazard= key.

[1] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hazard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

[Brian M. Sperlongano]

Yes, and while we're at it, let's throw in multinational bases as well:

https://en.wikipedia.org/wiki/NATO_Air_Base_Geilenkirchen


On Sun, Dec 6, 2020 at 11:17 AM Paul Allen  wrote:

> On Sun, 6 Dec 2020 at 16:01, Brian M. Sperlongano 
> wrote:
>
>> This is probably a US-centric viewpoint, but I note that there is a
>> general lack of tagging under the military= key to indicate the military
>> branch associated with a military base.
>>
>
> Branch or branches.   There are an increasing number of joint bases.
> https://en.wikipedia.org/wiki/Joint_base
>
> --
> 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

Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

[Brian M. Sperlongano]

This is probably a US-centric viewpoint, but I note that there is a general
lack of tagging under the military= key to indicate the military branch
associated with a military base.  For example, we have military=naval_base,
but no equivalent tagging for army, air force, amphibious, (dare I say
space force?) bases.  In places where the coast guard IS part of the
military, tagging it under landuse=military + military=* is appropriate.
However, I also support the need to tag coast guard areas in places where
they are considered non-military and thus landuse=military would not be
appropriate.

On Sun, Dec 6, 2020 at 10:38 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 6. Dec 2020, at 03:23, Graeme Fitzpatrick 
> wrote:
>
> Please visit https://wiki.openstreetmap.org/wiki/Marine_rescue & have a
> look.
>
> All comments welcome either here or on the Talk page.
>
>
>
> it makes it look a either military or rescue decision, but many coast
> guards will be seen as part of the police or border patrol, rather than
> military.
>
> E.g. https://en.m.wikipedia.org/wiki/German_Federal_Coast_Guard
>
> https://en.m.wikipedia.org/wiki/Federal_Police_(Germany)
>
> https://en.m.wikipedia.org/wiki/Corps_of_the_Port_Captaincies_–_Coast_Guard
>
> Cheers Martin
>
> ___
> 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 - Hazards

[Brian M. Sperlongano]

I want to address the points that were raised on crossings.

As we already have highway=crossing, I have resisted adding new hazard=*
values for crossing hazards, as that is properly the domain of the
highway=crossing tag.  For golf cart crossing, there is already an
established tag combination highway=crossing + golf_cart=yes.  This was
already described on the wiki page for golf_cart, and I edited the wiki
page for highway=crossing to match this.

Considering this, I've updated the text on hazard=bicycle to reflect that
it is specifically about the hazard of cyclists in the roadway, and not for
bicycle crossings, which also has its own existing tagging.

This leaves hazard=school_crossing as the sole remaining "crossing"
hazard.  There are only a few usages of it, and I am leaning strongly
towards removing from the proposal entirely as it seems that a school
crossing belongs more properly within the scope of highway=crossing.

Lastly, the specific case of hazard=low_flying_aircraft is not a crossing
hazard, as the hazard is a distraction to motorists or perhaps jetwash
rather than collision, as with a crossing.  The only actual "airplane
crossing" that I am aware of is the case of the Gibraltar airport which has
a road that crosses the airport runway.  However, this is an exceptionally
rare case, and in any case, it too would belong under highway=crossing.

On Sat, Dec 5, 2020 at 12:43 PM Volker Schmidt  wrote:

> Hi,
> I have been following this proposal with interest. I often have tried to
> tag hazards, and not found a good ways of doing it.
> We are now compiling a long list of hazards, including golf players
> crossing the road, but I see some basic aspects which are not being
> addressed (unless I missed something):
>
> I would like to see signposted hazards completely separately tagged from
> hazards that the mapper perceives in a place, but which are not signed.
>
> Signed hazards should be mapped.
>
>- on nodes, if the extension of the hazard is point-like (example:
>dangerous railway crossing)
>- on ways, if the hazard exists along a highway (example: animals
>crossing zones)
>- (possibly) on areas, if the hazard is present in an area (example:
>landslides)
>
> In the case of signed hazards, I see two alternative ways of tagging the
> signing:
>
>- (only for nodes and ways highway segments) by adding source:xxx=sign
>like we do with speed limits
>- by mapping the relative signs as nodes
>
> Insertion of signposted hazards do not require any assessment of the
> presence of the hazard by the mapper.
>
> Signposted hazards are most often signalling dangers for vehicle drivers.
> Let's take the sign for hazard=cyclists (crossing), which warns clearly the
> vehicle drivers on the carriageway, that there could be cyclists crossing.
> There is normally no such warning on the crossing cyclists' path.
> There are exceptions of hazard warnings for both parties like a "cyclists
> sharing the road" sign, but that's the only one that comes to mind.
>
> Another aspect that should be defined: Are writings or pictograms on the
> road surface equivalent to vertical traffic signs?
>
>
> A completely different story are unsigned hazards with no signs on the
> ground, i.e. situations perceived as a hazard by the mapper.
> These are the tricky ones. I map cycling infrastructure, hence my examples
> come from that perspective.
> Examples:
>
>- foot-cycle crosswalks where there is a sign-posted speed limit of
>30km/h, but where 90% of the cars pass with speeds far exceeding that value
>and making the place really dangerous
>- a two-way cycle path that is parallel to a main road and crosses  a
>side road with a foot.bicycle crosswalk - car drivers entering the side
>road regularly overlook cyclists which ride in the same direction as they
>drive (to my knowledge the major cause of cyclists being killed in many
>countries. These in most cases in my part of the world have no danger
>signs.
>- And now consider the same situation with a row of trees between the
>cycle path and the main carriage way.
>- In my part of the world authorities put all kinds of bollards,
>arches, chicanes on cycleways (supposedly for the safety of cyclists, but
>in reality to keep car drivers from parking there). Many of these are grey
>metal objects that become invisible at night even if you have a good cycle
>light, as they have no reflective markers on them.
>
> The problem here is that the tagging will be based on my perceived version
> of ground truth. If I am a cyclist, I may be good at spotting hazards for
> cyclists. If I am a horse rider I will be good at mapping hazards for horse
> riders.
>
> Then we have also the asymmetric situations: e.g. car drivers are warned
> by a sign that there will be cyclists crossing, but the (bigger) hazard of
> cars hitting the cyclists on the same crossing is not signposted for
> cyclists.
>
> Volker
>
>

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

[Brian M. Sperlongano]

This was a concern of mine as well.  I did not want someone micromapping
every bend in a road with hazard=curve for example.  The intent is for
officially declared hazards rather than vague interpretations.  However, I
also recognize that, particularly in the developing world, formal signage
or declaration may not exist and that unsigned hazards should be allowed.
I specifically wrote the paragraph below (from the proposal) to address
this issue.

Does that satisfy your concern?

=== Proposal text below ===

Hazards are verifiable via the following means:

* Hazards to drivers indicated by roadside traffic signs.
* Hazards to health and safety indicated by fences or other barriers with
posted signs
* Government-declared hazardous areas as marked on government maps and/or
GIS systems
* For countries which routinely sign traffic hazards (such as "dangerous
curve" or "school zone"), mappers should only tag these hazards when they
are actually signed. However, in some cases, notably in the developing
world, these types of hazards may be tagged even if unsigned.

On Fri, Dec 4, 2020 at 3:56 AM Jez Nicholson 
wrote:

> As long as your frost heave conforms to verifiability guidelines by being
> either:
> a) signposted (possibly)
> b) fenced off, with a sign (no, because it's in the road)
> c) a government-declared hazardous area (no)
>
> I'm concerned that this hazard tagging proposal will encourage subjective
> tagging over what constitutes a 'hazard'.
>
>
> On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano 
> wrote:
>
>> I'd think that frost heaves (which are seasonal and conditions-based)
>> versus permanent bumps are different.  If there aren't objections, I'd
>> propose both a hazard=bump (which has a few trace uses) and a new value
>> hazard=frost_heave to cover frost heaves specifically.
>>
>> On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:
>>
>>> *hazard=frost_heave, hazard=bump?*
>>>
>>> One of the common road hazards I encounter and would like to tag are
>>> large frost heaves that occur at consistent locations every year. A few
>>> roads in my region like VT-17 and NY-8 have poor roadbeds and get damaged
>>> by frost heaves the first winter after repaving. These roads often have
>>> several hundred yards of nice smooth and fresh pavement, then 2"-8" frost
>>> heaves with cracks that reappear in the same places year after year.
>>>
>>> Some examples:
>>>
>>>- VT-17: section A
>>><https://www.mapillary.com/map/im/Nisd3iuj_bCdnuSwVBh5zA>, section B
>>><https://www.mapillary.com/map/im/O-kqJL5OPJI-_RVor2rv4A> (with
>>>"BUMP" sign), section C
>>><https://www.mapillary.com/map/im/MzW49dK2S78l2ewhhpg5PQ>
>>>- NY-8: section A
>>>
>>> <https://www.google.com/maps/@43.5567706,-74.120767,3a,75y,60.66h,62.7t/data=!3m6!1e1!3m4!1s8wGqO4YlGLPO2JfLpTG7ug!2e0!7i13312!8i6656>,
>>>section B
>>>
>>> <https://www.google.com/maps/@43.5548342,-74.1233648,3a,75y,41.82h,60.46t/data=!3m6!1e1!3m4!1sWntAQT_Hwb2BVYwM5shNRg!2e0!7i13312!8i6656>
>>>
>>> This has been previously mentioned in an OSMUS Slack thread
>>> <https://osmus.slack.com/archives/C2VJAJCS0/p1584560161247300> in
>>> regard to smoothness=*, but tagging particularly bad (and often
>>> permanent) heaves may be preferable as other sections of the roadway may be
>>> smooth and freshly paved.
>>>
>>> Signage on these tends to be inconsistent, often using phrasing like
>>> "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
>>> phrases. In some locations the signs are permanently mounted, while other
>>> locations get folding signage. As these are point features with varying
>>> placement of signage, I would suggest mapping them as nodes on a roadway at
>>> the heave position with something like hazard=frost_heave.
>>> Alternatively, hazard=bump may be applicable to other situations
>>> worldwide for dangerous bumps caused by something other than freeze/thaw
>>> cycles.
>>>
>>> Best,
>>> Adam
>>>
>>> On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano <
>>> zelonew...@gmail.com> wrote:
>>>
>>>> Comment is requested on the proposal "hazard", which describes
>>>> hazardous or dangerous features.  This tagging was first proposed in 2007,
>>>> and I have adopted the proposal with permission from the original author.
>>>> Thanks to the various folks that assisted

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

There's a few usages of hazard=golf_balls, which is more like what you're
describing and actually a hazard.  It seems a bit nebulous, but perhaps the
sign could be mapped.  That's different from a golf crossing, which is a
place where golfers and golf carts would cross a road.

I've already added hazard=low_flying_aircraft as was previously suggested.

And with regard to the generic hazard sign, there is always the generic
catch-all of hazard=yes!

Thanks for the link to the directory of German signs.  I think most of them
are covered, though there's a few outliers.  I'm trying to err on the side
of defining fewer values to make sure that we don't end up duplicating
something that exists elsewhere (for example, in the cases of
highway=crossing and traffic_calming=* which are both often signed as
hazards).  Essentially my net is "values that have high existing usage plus
values that people feel strongly about including".



On Fri, Dec 4, 2020 at 2:56 PM Martin Koppenhoefer 
wrote:

> sent from a phone
>
> > On 4. Dec 2020, at 17:42, Brian M. Sperlongano 
> wrote:
> >
> > I am thinking this case (crossing golfers) is more of a highway=crossing
> rather than a hazard?
>
>
> I think it is a warning that a golf ball might eventually hit your
> vehicle, and if you’re prepared you won’t be startled
>
> There is also the crossing airplane hazard, even 2 variants, airplanes
> from the right:
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101-10_-_Flugbetrieb,_Aufstellung_rechts,_StVO_2017.svg
> and from the left:
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101-20_-_Flugbetrieb,_Aufstellung_links,_StVO_2017.svg
>
> They do not imply that you have to fear airplanes on the street, they
> are meant to prepare you for low flying aircraft.
>
> A picture list of all German "standard hazards" can be found here:
>
> https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017#Gefahrzeichen_nach_Anlage_1_(zu_%C2%A7_40_Absatz_6_und_7_StVO)
> but with this  sign
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101_-_Gefahrstelle,_StVO_1970.svg
> in combination with a text sign, any hazard can be signposted.
>
> These are only the official road signs, on footways and private
> properties, information signs etc., you might find all kind of other
> hazard warnings. Is the tag only thought for roads and official road
> signs, or is its scope extended to other official signs (e.g. in some
> forests, there are "Rabies prone area" official signs, military areas
> might warn with "restricted area, armed guards", and a property owner
> might allude their dog is snappish.
>
> Cheers
> Martin
>
> ___
> 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 - Hazards

[Brian M. Sperlongano]

I am thinking this case (crossing golfers) is more of a highway=crossing
rather than a hazard?  There appear to be no existing values of hazard for
indicating crossing golfers to lean on here.

On Fri, Dec 4, 2020 at 11:23 AM Niels Elgaard Larsen 
wrote:

> Brian M. Sperlongano:
> > Niels, thanks for the list.
>
>
> I found another Danish hazard
> Crossing golfers:
> https://hopcycling.pl/wp-content/uploads/2019/06/L9720954.jpg
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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] RFC Update - Hazard Proposal - rock/land fall/slide

[Brian M. Sperlongano]

I poked into the existing usages of hazard=landslide, and they seem to
mostly be on hiking trails or at best track roads, rather than regular
roads.  I don't think anyone would quibble with tagging a landslide hazard
on this [1] for example.

[1] https://commons.wikimedia.org/wiki/File:Landslide_area.JPG

On Thu, Dec 3, 2020 at 8:26 PM Paul Allen  wrote:

> On Fri, 4 Dec 2020 at 01:05, Kevin Kenny  wrote:
>
>> On Thu, Dec 3, 2020 at 1:09 PM Paul Allen  wrote:
>>
>>> That's not to say we don't have landslides in the UK, but it appears
>>> we don't construct roads in places where they are anticipated to
>>> happen.
>>>
>>
>> The idea of "we don't build where the rocks might fall in the road"
>> doesn't work all that well when every mountain pass poses the same risk.
>>
>
> We have quite a lot of falling/fallen rocks hazards.  We seem happy to
> build
> roads there.  Not so many roads by landslide hazards.  Apart from a few
> by colliery spoil tips, but there was no anticipated landslide hazard with
> those.
>
> --
> 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

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

[Brian M. Sperlongano]

On Thu, Dec 3, 2020 at 12:54 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I am not exactly happy about "rock slide" as it seems weird to use it where
> danger is primarily about individual rocks dropping, not about full scale
> rock slide.
>
> Personally I would prefer "failing rocks" for warning used by a standard
> road
> sign.
>
> (difference is minor, but if we have luxury of selecting any value...)
>

Since we do have that luxury, and there is a valid reason for preferring
terminology as actually signed, then we can adopt "hazard=falling_rocks"
(53 usages) and deprecate "hazard=rockfall" (182 usages).  These are small
enough numbers that there shouldn't be any harm in choosing the smaller one.

Can we treat landslide and rock_slide as the same thing?  If so,
"hazard=rock_slide" has 394 usages and "hazard=landslide" has 35 usages.
In that case, I would propose to adopt the more popular "rock_slide" and
deprecate "landslide" as duplicate.

Would this address the concerns?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (frost heave?)

[Brian M. Sperlongano]

I'd think that frost heaves (which are seasonal and conditions-based)
versus permanent bumps are different.  If there aren't objections, I'd
propose both a hazard=bump (which has a few trace uses) and a new value
hazard=frost_heave to cover frost heaves specifically.

On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:

> *hazard=frost_heave, hazard=bump?*
>
> One of the common road hazards I encounter and would like to tag are large
> frost heaves that occur at consistent locations every year. A few roads in
> my region like VT-17 and NY-8 have poor roadbeds and get damaged by frost
> heaves the first winter after repaving. These roads often have several
> hundred yards of nice smooth and fresh pavement, then 2"-8" frost heaves
> with cracks that reappear in the same places year after year.
>
> Some examples:
>
>- VT-17: section A
><https://www.mapillary.com/map/im/Nisd3iuj_bCdnuSwVBh5zA>, section B
><https://www.mapillary.com/map/im/O-kqJL5OPJI-_RVor2rv4A> (with "BUMP"
>sign), section C
><https://www.mapillary.com/map/im/MzW49dK2S78l2ewhhpg5PQ>
>- NY-8: section A
>
> <https://www.google.com/maps/@43.5567706,-74.120767,3a,75y,60.66h,62.7t/data=!3m6!1e1!3m4!1s8wGqO4YlGLPO2JfLpTG7ug!2e0!7i13312!8i6656>,
>section B
>
> <https://www.google.com/maps/@43.5548342,-74.1233648,3a,75y,41.82h,60.46t/data=!3m6!1e1!3m4!1sWntAQT_Hwb2BVYwM5shNRg!2e0!7i13312!8i6656>
>
> This has been previously mentioned in an OSMUS Slack thread
> <https://osmus.slack.com/archives/C2VJAJCS0/p1584560161247300> in regard
> to smoothness=*, but tagging particularly bad (and often permanent)
> heaves may be preferable as other sections of the roadway may be smooth and
> freshly paved.
>
> Signage on these tends to be inconsistent, often using phrasing like
> "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
> phrases. In some locations the signs are permanently mounted, while other
> locations get folding signage. As these are point features with varying
> placement of signage, I would suggest mapping them as nodes on a roadway at
> the heave position with something like hazard=frost_heave. Alternatively,
> hazard=bump may be applicable to other situations worldwide for dangerous
> bumps caused by something other than freeze/thaw cycles.
>
> Best,
> Adam
>
> On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano 
> wrote:
>
>> Comment is requested on the proposal "hazard", which describes hazardous
>> or dangerous features.  This tagging was first proposed in 2007, and I have
>> adopted the proposal with permission from the original author.  Thanks to
>> the various folks that assisted in the development of this proposal prior
>> to this RFC.
>>
>> The key "hazard" has achieved over 28,000 usages, and it is proposed to
>> formalize usage of the most popular values of this key while deprecating
>> less-popular synonyms.  In addition, this proposes to deprecate
>> protect_class=16 in favor of the hazard key.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>> ___
>> 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

[Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

[Brian M. Sperlongano]

Hello,

I've made a number of updates to the "hazard" proposal [1] based on the
input received.  Thanks to those that offered comment and feedback so far
during this RFC.

I request community help on resolving feedback on the proposed tag
hazard=rock_slide and deprecation of three values of hazard: rockfall,
falling_rocks, and landslide.  The feedback was that rock falls, rockslides
and landslides are different and should not be conflated in a single
value.  Indeed, geologically they are different; a "fall" implies material
falling from a cliff while a "slide" implies material sliding down a
slope.  Additionally "rock" versus "land" describes a different type of
material that might fall or slide.

However, in standard road signage, there is a single pictogram for all of
these forms of falling/sliding material that almost universally depicts a
steep slope with pieces of falling debris.  See the referenced wikipedia
articles [2][3] in the row labelled "falling rocks or debris" for examples
in many countries.

In some cases, this pictogram is also combined with text that further
specificies "landslide" [4] or signs might say in words only "rock slide
area" or "slide area".  The "falling rocks or debris" sign is also commonly
used by itself to generally indicate this category of hazard.  In these
cases (the falling rocks/debris pictogram sign used by itself), my thinking
was that a mapper should have a single tag that they can apply, without
having to specifically determine the exact geological character of the
rock/land fall/slide hazard.  Thus, I've proposed to adopt the most common
variant "rock_slide" to cover all of these cases, which a mapper could use
anytime they map a sign with that pictogram, and deprecate the others, in
order to create consistent tagging.

I request community feedback on this specific question of how to tag this
type of hazard for cases of:
(a) When the mapper observes the "falling rocks or debris" sign but is
unsure of whether it is specifically a rock/land slide/fall
(b) When the mapper observes the sign, and knows the specific geological
type
(c) When the mapper observes a sign with specific text that states "falling
rocks", "rock fall", or "landslide"

Do these distinctions need to be tagged differently, and if so, are there
suggestions on how that tagging might be constructed?

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
[2]
https://en.wikipedia.org/wiki/Comparison_of_MUTCD-influenced_traffic_signs
[3] https://en.wikipedia.org/wiki/Comparison_of_European_road_signs
[4]
https://www.pdsigns.ie/product/safety-construction-hazard-warning-risk-of-landslide-on-cliff-edge-sign/
(note: commercial site)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Animal trails

[Brian M. Sperlongano]

On Wed, Dec 2, 2020 at 7:03 AM Martin Koppenhoefer 
wrote:

> Am Di., 1. Dez. 2020 um 18:08 Uhr schrieb Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>> +1, it's unreasonable for mappers to be mind readers about the intent of
>> land managers.  Either the public is allowed to walk on these paths, or
>> they are not.  There isn't really a middle ground here.
>>
>
>
> There is middle ground. For example in many German nature reserves, you
> may enter the reserve, provided you remain on the foot paths.
>

We are saying the same thing.  access=yes for the allowed paths, access=no
for anything else.  The topic of discussion are unofficial/social/animal
paths in places where there are established paths intended for visitors.  I
suppose if there is a middle ground you could muster access=discouraged,
but the documentation says this is for signed roads, not unsigned paths.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Animal trails

[Brian M. Sperlongano]

On Tue, Dec 1, 2020 at 11:59 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Dec 1, 2020, 00:44 by dieterdre...@gmail.com:
>
>
> Am Di., 1. Dez. 2020 um 00:39 Uhr schrieb Lukas Richert <
> lrich...@posteo.net>:
>
> I wouldn't tag this as foot=no or access=no. There are many trails in my
> area that are clearly animal tracks and seldom used by people - but it is
> allowed for people to walk on these and they are sometimes significant
> shortcuts so allowing routing over them in some cases would be good.
>
>
> +1
>
> +1, though in cases of protected areas with "do not leave signed trails"
> rules, access=no
> would be a viable tagging
>

+1, it's unreasonable for mappers to be mind readers about the intent of
land managers.  Either the public is allowed to walk on these paths, or
they are not.  There isn't really a middle ground here.  Though of course,
it is up to renderers to render access=no trails differently to make
access=no actually solve the problem being posed (the public following
paths in OSM that they shouldn't)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Animal trails

[Brian M. Sperlongano]

Note that there is already an animal=* tag for describing things related to
animals, so that probably shouldn't be overridden.  Perhaps a combination
of foot=no and animal=yes satisfies what we're describing?

On Mon, Nov 30, 2020 at 4:16 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Tue, 1 Dec 2020 at 06:54, Yves via Tagging 
> wrote:
>
>> Creating a new tag for this is not a bad idea.
>>
>
> Not a bad idea at all, even if just to stop them being marked as paths,
> but what would you tag them as?
>
> Footpaths etc are currently tagged as highway=xxx, which really isn't
> appropriate for an animal track!
>
> New tag animal=track / trail / path?
>
> &, as in most things OSM, it's been discussed before, apparently with no
> resolution?
>
> Thanks
>
> Graeme
>
> ___
> 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 - Hazards (mine shaft)

[Brian M. Sperlongano]

It seems to me that there is a clear case for there being both hazardous
and non-hazardous examples of man_made=mineshaft.  The question is how to
tag the ones that are hazardous.

I think the right answer is simply man_made=mineshaft + hazard=yes.  If we
were to approve hazard=open_mineshaft, you create ambiguity as to whether a
mappers could tag ONLY hazard=open_mineshaft and omit the
man_made=mineshaft, which is not desirable.  The hazard=yes tag is intended
to mark features that are already properly described by other tagging, but
indicate that it is also hazardous.

On Fri, Nov 27, 2020 at 8:38 AM ael via Tagging 
wrote:

> On Thu, Nov 26, 2020 at 04:01:09PM -0500, Brian M. Sperlongano wrote:
> > On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging <
> tagging@openstreetmap.org>
> > wrote:
> >
> > > On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> > > > I am not opposed to including unsigned hazards
> > >
> > > There are a surprising number of abandoned open mineshafts in the far
> > > West of England which are a hazard, if not an extreme hazard. Not all
> > > of these are signed or fenced. You might have noticed some of them
> when you
> > > trawled through the existing usage.
> > >
> > > It would be absurd to require such cases to be "signed": those are the
> > > least hazardous by virtual of the signage.
> >
> > Ok, I'm convinced that unsigned hazards are acceptable to be signed!
> >
> > In the case of open mineshafts, there is already an approved tag
> > man_made=mineshaft with 10,000 usage (and a similar de facto tag for
> > horizontal shafts, man_made=adit with 12,000 usages).
>
> A mineshaft is not a hazard if it is properly protected or capped or
> whatever. So there is no need for a hazard tag in the majority of cases.
>
> As a result, the
> > hazard key hasn't really been used for this -- there is a
> > hazard=open_mineshaft with 5 usages, and a single use of
> hazard=mineshaft.
> > I'm not sure if all mine shafts are hazardous or only some of them, but
> in
> > any case, I would think that man_made=mineshaft + hazard=yes would make
> > more sense than a a mineshaft-specific value.
>
> Well, that is better than nothing, but I don't see why a more specific
> value is not useful. The hazard might be toxic effluent coming out of
> a (probably disused) mineshaft. There are even cases where there can be
> toxic fumes as the result of bacterial activity.
>
> For back ground, many of the open mineshafts in Cornwall come from the
> long (even pre-historic) undocumented mining history. Many old shafts
> were capped with timber supports that have since rotted away and shafts
> suddenly appear unexpectedly. Other shafts are covered in undergrowth
> and may have never been capped. Pets and people are regularly rescued
> from such places.
>
> Adits are normally much less hazardous by virtue of being approximately
> horizontal. Of course, if an inexperienced person chooses to enter then
> they may well be exposed to many hazards, and maybe that could be tagged
> as well, but apart from perhaps the risk of  rock fall/collapse, I would
> think tagging underground features is at least problematic in OSM.
>
> ael
>
>
> ___
> 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 - Hazards

[Brian M. Sperlongano]

It looks like you're referring to this area:
https://www.openstreetmap.org/query?lat=40.3482=46.5377#map=10/40.3812/46.8347

It seems that this giant border-area polygon was removed recently as it's
only rendered at lower zoom levels.

If the precedent is that military conflict areas are mapped with
landuse=military and possibly also military=danger_area, then it doesn't
sound like there is a need for an additional hazard tag, unless we think
that the type of danger_area needs to be further described by the addition
of a hazard tag.  There does not seem to be any existing usages of the
hazard key that I can find for an active military conflict zone, other than
hazard=minefield.

On Fri, Nov 27, 2020 at 8:28 AM Andy Townsend  wrote:

>
> On 27/11/2020 04:25, Brian M. Sperlongano wrote:
>
> Assuming that the boundary of that area is reasonably permanent, my first
> reaction is that this could be described by military=danger_area.  However,
> that tag requires landuse=military as the primary tag, which probably isn't
> correct here.
>
> On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
> wrote:
>
>> Not wanting to create a bunfight, but just reading the news, & wondering
>> if this sort of thing should be tagged as a hazardous area?
>>
>>
>> https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606
>>
>>
> Yes, there are precedents for having that sort of thing in OSM as military
> areas of some sort - have a look at how the frontline in the recent
> Azerbaijan / Armenia conflict was mapped over the last few months.
>
> Best Regards,
>
> Andy
>
>
> ___
> 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 - Hazards

[Brian M. Sperlongano]

Niels, thanks for the list.

I was able to find examples and existing tagging for most of the values you
noted as missing, and I've updated the proposal to add them.  I did already
have a value listed dangerous intersection (hazard=dangerous_junction, 400
usages).

The one you listed that is not clear is the one that you describe as
"dangerous road edge".  The linked sign looks more like a "soft verge" or
"soft shoulder" sign, and there are no existing tag values that I can find
for this type of hazard.  There is a small number of usages of
hazard=uneven_road, however that sign usually looks something like this:
https://commons.wikimedia.org/wiki/Traffic_sign#/media/File:1.16_Russian_road_sign.svg

There is also a small usage of hazard=cliff, which has particularly fun
signs, notably:
https://commons.wikimedia.org/wiki/File:Ireland_road_sign_W_160.svg
https://commons.wikimedia.org/wiki/File:Don%27t_fall_off_the_Cliff!_(16841837743).jpg

On Fri, Nov 27, 2020 at 8:06 AM Niels Elgaard Larsen 
wrote:

> På Thu, 26 Nov 2020 09:11:25 -0500
>
>
> I am missing values for:
>
> horse riding:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_47.png
> hazard:animal=horse should only be for wild horses
>
> Crossing bicyclists:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_45.png
>
> Slippery road:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_50.png
> How do we map "slippery when wet"? Or ice?
>
> Loose rocks on the road:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_52.PNG
>
> Dangerous road edge:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_54.png
>
> low airplanes and helicopters:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_82.png
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_83.png
>
> Queue risk:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_44.png
>
> Dangerous intersections
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_85.png
>
> "Brian M. Sperlongano"  skrev:
> >I am not opposed to including unsigned hazards, if that's the
> >consensus.  I was trying to address anticipated concerns about tagging
> >unverifiable things.
>
> It could be verified in other ways. For example official reports based
> on statistics. Or newspaper articles on accidents caused by crossing
> animals on a certain stretch of road.
>
> > For example, someone in a western country
> >tagging a curve hazard on every instance of a bend in the road and not
> >just the signed parts.
>
> I agree. In fact there is not much point in tagging even the signed
> parts.
>
> The reason for those signs is that the driver cannot see road ahead or
> that it is difficult to judge the sharpness from the perspective of a
> car.
> But with a map it can be done. A data consumer is in a better position
> to decide if turns are hazards. When using a navigation system, I can
> look at the screen and judge if the next turn could be a problem.
>
> I could also tell my navigation software which vehicle I am driving and
> it could use that information together with my current position, my
> actual speed and the data on the road ahead to decide if I should be
> alerted.
>
> For the same reason there is also no reason to tag signed hazards for:
>
> Tunnels:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_68.png
>
> Steep inclines/declines:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_69.png
>
> level crossing without gates:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_71.png
>
> bridges that open:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_79.png
>
> Quays without guards:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_80.png
>
> because all those can be inferred from other tags.
>
> >On Thu, Nov 26, 2020, 8:06 AM Yves via Tagging
> > wrote:
> >
> >> And hazards for niche practices (climbing, whitewater sports, ski
> >> touring,...) that are actually mapped in OSM are not generally
> >> signposted or 'official'.
> >> Maybe we can't expect this proposal to cover them, but you can't
> >> prevent users to use the tag hazard to map them.
> >> Yves
> >>
> >> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> >> dieterdre...@gmail.com> a écrit :
> >>>
> >>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via
> >>> Tagging < tagging@openstreetmap.org>:
> >>>
> >>>>
> >>>>- It is not explicitly mentioned, but it would be a good idea to

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

Assuming that the boundary of that area is reasonably permanent, my first
reaction is that this could be described by military=danger_area.  However,
that tag requires landuse=military as the primary tag, which probably isn't
correct here.

On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
wrote:

> Not wanting to create a bunfight, but just reading the news, & wondering
> if this sort of thing should be tagged as a hazardous area?
>
>
> https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606
>
> Thanks
>
> Graeme
>
> ___
> 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 - Hazards (rock slide etc)

[Brian M. Sperlongano]

It looks like the vast majority of the uses of hazard=erosion is in
Bolivia, where it appears (from overhead imagery) to be used to tag
locations where these dirt roads are near or intersected by intermittent
streams which tend to wash the road out.  Often they are combined with
ford=yes when the stream actually crosses the road.  That seems like it
could be a reasonable thing to tag, and not at all like the various
"falling rocks/landslide/rockslide" variants which are all versions of
"land falling from above".

On Thu, Nov 26, 2020 at 3:05 PM Martin Koppenhoefer 
wrote:

> Am Do., 26. Nov. 2020 um 17:48 Uhr schrieb Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>>  This is good feedback, and I would potentially toss another into the
>> mix: hazard=erosion which has about 300 tags.  Do we think these four tags
>> (rock_slide, falling_rocks, landslide, erosion) represent four distinct and
>> separate things that are properly tagged separately?
>>
>>
>
> I would see erosion as the parent category for all of the other 3,
> possibly too generic to get an idea what particularly is happening there.
> I'd rather deprecate it than encourage its use.
>
> Cheers
> Martin
>
> ___
> 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] Feature Proposal - Vote Result - Special Economic Zone

[Brian M. Sperlongano]

The result of voting on the proposal "Special Economic Zone" is:
25 in favor
2 opposed
0 abstentions

The two votes in opposition expressed a preference for the use of
protect_class=23 for tagging these areas.

The community consensus is to approve boundary=special_economic_zone and
deprecate protect_class=23 as described in the proposal [1].  Thank you to
all that participated in the discussions and vote on this proposal.

Proposal page
[1]
https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

[Brian M. Sperlongano]

On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging 
wrote:

> On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> > I am not opposed to including unsigned hazards
>
> There are a surprising number of abandoned open mineshafts in the far
> West of England which are a hazard, if not an extreme hazard. Not all
> of these are signed or fenced. You might have noticed some of them when you
> trawled through the existing usage.
>
> It would be absurd to require such cases to be "signed": those are the
> least hazardous by virtual of the signage.


Ok, I'm convinced that unsigned hazards are acceptable to be signed!

In the case of open mineshafts, there is already an approved tag
man_made=mineshaft with 10,000 usage (and a similar de facto tag for
horizontal shafts, man_made=adit with 12,000 usages).  As a result, the
hazard key hasn't really been used for this -- there is a
hazard=open_mineshaft with 5 usages, and a single use of hazard=mineshaft.
I'm not sure if all mine shafts are hazardous or only some of them, but in
any case, I would think that man_made=mineshaft + hazard=yes would make
more sense than a a mineshaft-specific value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Brian M. Sperlongano]

This [1] testing site in my state opened back in July (five months ago) and
is dedicated to COVID testing only.
These sites[2] opened in May (seven months ago) and are still going
strong.  They are co-located with a pharmacy (usually in the parking lot).

While they may be "temporary" as in "when the pandemic is over, they will
be disassembled and the area will revert to its natural state", we are
already hitting the six month threshold that is usually offered as the
minimum standard for permanence.  If anyone thinks they know how long these
will be here, they are frankly just guessing.  These places are useful to
tag, and they could be here for...months? a year or more?

It's anybody's guess as to whether vaccination centers will follow a
similar pattern as testing, but it is reasonable to figure out now, while
the issue is topical, how such a thing should be tagged given the potential
for a sufficient level of permanence.  Anti-vaccine sentiment is a real
thing in the United States, and there is every reason to believe that a
mass vaccination will start slowly and take months or more, and not just a
few weeks as has been suggested.

[1]
https://www.providencejournal.com/story/news/coronavirus/2020/07/21/new-drive-up-coronavirus-test-site-opens-at-ri-convention-center/42521793/
[2]
https://www.providencejournal.com/news/20200528/cvs-to-open-10-new-coronavirus-testing-sites-in-ri

On Thu, Nov 26, 2020 at 9:59 AM Paul Allen  wrote:

> On Thu, 26 Nov 2020 at 02:35, stevea  wrote:
>
>> I'm in California, where it's almost cliché we love our cars and car
>> culture, but it is true that not only here but in many USA states, we have
>> "drive-thru" COVID-19 testing centers.
>
>
> In the UK we don't have much of a drive-thru anything except maybe some
> fast-food outlets of American origin.  Yet all the covid-19 testing
> centres I'm
> aware of are strictly drive-thru.  As in you're not allowed to turn up on
> foot,
> because if you're infected you may pass it on to other pedestrians you walk
> near.  And they're drive-thru because the swabs are taken in the open.
> The swabs are taken in the open because there is far less risk of
> transmission outdoors than indoors.
>
>
>>   I would guess that vaccination centers that are also "drive-thru" are
>> likely soon (early 2021?), too.
>
>
> The same reasons that make the test centres drive-thru apply to
> vaccination centres.  Eventually, when we have herd immunity
> (one way or another) indoor vaccination may be feasible (but
> probably undesirable).  The health workers will be vaccinated
> first so they won't be at risk either way, but these places will
> be handling large numbers of people and having them all wait
> indoors is a good way of infecting lots of people.
>
>
>>   These being mapped with "indefinite duration" seems a bit much (sorry,
>> Brian), but they are usually more of a "pop-up" kind of thing:  one-time or
>> "only on Saturdays" or something like that.
>
>
> There is a temporary, short-duration, won't be there for long, test centre
> just
> popped up in my town because a couple of weeks ago some idiots decided
> to celebrate the end of firebreak restrictions by going to the pubs and
> ignoring social distancing completely.  Fifty-five cases came of that, and
> three hundred contacts have been traced.  I expect it to go away in a few
> weeks if the outbreak gets under control.  I'm not confident the outbreak
> will be under control very soon because a lot of the celebrants were
> shop workers.
>
> But as well as that pop-up test centre because of the sudden surge, there
> is an existing test centre.  That's based at the leisure centre that was
> converted to an emergency overflow hospital several months ago. I only
> found out the test centre was there a few days ago because we try to
> keep their locations secret, so I probably won't map it.
>
> Vaccination centres are going to handle more people than test centres
> do because nearly the entire population will have to be vaccinated but
> only a very small fraction of the population is tested (we ought to be
> testing everyone at least once a week, but my country's government
> is somewhat incompetent).
>
> --
> 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

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

[Brian M. Sperlongano]

>
>
>- The use of hazard =
>rock_slide
>
> 
>is more popular than several alternatives,
>- which are essentially describing the same thing: a hazard where
>rocks, earth, or mud might fall from above.
>-
>- There is a big difference between rock slide, failing rocks and
>landslide.
>-
>- I do not thing that deprecation of failing_rocks and landslide is a
>good idea,
>- I would keep them (I have seen signposted sign about landslide
>exactly once,
>- many, many signs of failing rocks - tagging rock_slide for either of
>them would
>- be incorrect).
>
>  This is good feedback, and I would potentially toss another into the mix:
hazard=erosion which has about 300 tags.  Do we think these four tags
(rock_slide, falling_rocks, landslide, erosion) represent four distinct and
separate things that are properly tagged separately?  I can see erosion
being "the ground may fall from under you at the cliff's edge" but the
others sounded like "the ground may fall from above".

The signs that I have found for landslide look exactly the same,
pictorally, as falling rocks, although I have found some with the actual
words "landslide".  It would be helpful someone can offer this flat-lander
examples where there are clear signage differences between these, or offer
clear definition differences between these values - especially if we go in
the direction of tagging unsigned hazards also.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (animals)

[Brian M. Sperlongano]

On Thu, Nov 26, 2020 at 2:25 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>- Why hazard:animal and hazard:species is needed instead of animal and
>species?
>
> I initially had it as just animal and species as you suggest.  However,
for hazards along a stretch of road (for example, "moose crossing next 5
miles"), you would end up tagging a way with animal=moose.  This creates
ambiguity in the tagging as to whether the road is *for* moose or contains
a *moose hazard*.  Thus, I invented hazard:animal to explicitly draw a
distinction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

I knew when I started this that it would be impossible to address every
single possible hazard that may exist in the world.  I tried to curate a
list of the most popular hazards that people were actually actually tagging
with the 28,000 existing usages of the hazard key, and that I felt I was
able to adequately understand, describe, and provide examples for.
However, if people believe I'm missing something, I would be more than
happy to add to the list!

On Thu, Nov 26, 2020 at 8:06 AM Yves via Tagging 
wrote:

> And hazards for niche practices (climbing, whitewater sports, ski
> touring,...) that are actually mapped in OSM are not generally signposted
> or 'official'.
> Maybe we can't expect this proposal to cover them, but you can't prevent
> users to use the tag hazard to map them.
> Yves
>
> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> dieterdre...@gmail.com> a écrit :
>>
>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org>:
>>
>>>
>>>- It is not explicitly mentioned, but it would be a good idea to
>>>have explicit mention
>>>- is it OK to tag hazard that
>>>-
>>>- - exists
>>>- - is unsigned
>>>- - government has not declared that it exists (maybe government is
>>>dysfunctional/missing like
>>>- in Somalia, or it is covering-up the problem, or it has higher
>>>priorities - for example during war)
>>>
>>>
>>
>> +1. This may also depend on the context. The same kind of hazard on a
>> road may well be signposted, but not on a hiking trail in a forest.
>>
>> Cheers,
>> Martin
>>
> ___
> 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 - Hazards

[Brian M. Sperlongano]

I am not opposed to including unsigned hazards, if that's the consensus.  I
was trying to address anticipated concerns about tagging unverifiable
things.  For example, someone in a western country tagging a curve hazard
on every instance of a bend in the road and not just the signed parts.

On Thu, Nov 26, 2020, 8:06 AM Yves via Tagging 
wrote:

> And hazards for niche practices (climbing, whitewater sports, ski
> touring,...) that are actually mapped in OSM are not generally signposted
> or 'official'.
> Maybe we can't expect this proposal to cover them, but you can't prevent
> users to use the tag hazard to map them.
> Yves
>
> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> dieterdre...@gmail.com> a écrit :
>>
>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org>:
>>
>>>
>>>- It is not explicitly mentioned, but it would be a good idea to
>>>have explicit mention
>>>- is it OK to tag hazard that
>>>-
>>>- - exists
>>>- - is unsigned
>>>- - government has not declared that it exists (maybe government is
>>>dysfunctional/missing like
>>>- in Somalia, or it is covering-up the problem, or it has higher
>>>priorities - for example during war)
>>>
>>>
>>
>> +1. This may also depend on the context. The same kind of hazard on a
>> road may well be signposted, but not on a hiking trail in a forest.
>>
>> Cheers,
>> Martin
>>
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

[Brian M. Sperlongano]

Unless somebody has a crystal ball, it's at least plausible that these
could be around for quite some time.  If we're lucky and they go away
quickly, it's easy enough to remove the tagging later.  But, "indefinite
duration" seems like a sufficient level of permanence for an OSM feature.

On Wed, Nov 25, 2020 at 5:20 PM Peter Elderson  wrote:

> We (Nederland) will likely use the flu vac system of local practitioners
> and old people's homes to do groups at risk first, and health care
> personnel will take care of themselves while administering.Will take two to
> three weeks for the first shot, and if a second shot is needed, 6 weeks.
>
> The rest will probably need to apply, and I think the Covid testing
> facilities will be used for the mass vax. This will probably take months,
> mainly because of supply chain and cold chain problems. Everybody will
> turn into an opportunist, politicians will literally lose their voices
> because of all the yelling at each other. Then it will become a standard
> yearly vaccination and we will all return to normal. O, the stories we will
> tell our grandchildren when they really just want to hang out with each
> other and play games...
>
> Best, Peter Elderson
>
>
> Op wo 25 nov. 2020 om 22:33 schreef Paul Allen :
>
>> On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:
>>
>> Although in this case I would expect the approach to be to set up
>>> sessions for schools, universities and at larger employers and for the
>>> general population it will simply attend an appointment at their local
>>> medical centre.
>>>
>>
>> Even back in the Before Times, flu jabs were not given at the local
>> medical
>> centre but in a large exercise hall.  I think that was more to do with
>> numbers
>> than anything else.  Covid is more infectious than flu (but less so than
>> measles)
>> and the indications are strong that you're at a lot greater risk indoors
>> than
>> outdoors.
>>
>> I doubt that testing or vaccination will take place at local medical
>> centres.  All
>> the testing centres I know of, whether short-term or longer-term have the
>> testing conducted outdoors.
>>
>> Right now, because of a recent surge in cases in my town the medical
>> centre is only permitting people to turn up if they get an appointment
>> because it is "absolutely necessary" (their words, not mine) they see
>> a doctor.
>>
>> I've been paying a lot of attention to this stuff (because of underlying
>> health conditions which mean I'm very unlikely to survive it) and I
>> seriously doubt we'll see testing or vaccination conducted indoors
>> until all medical staff have been vaccinated and enough of the
>> general population have been vaccinated to achieve herd
>> immunity.
>>
>> --
>> 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

[Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

Comment is requested on the proposal "hazard", which describes hazardous or
dangerous features.  This tagging was first proposed in 2007, and I have
adopted the proposal with permission from the original author.  Thanks to
the various folks that assisted in the development of this proposal prior
to this RFC.

The key "hazard" has achieved over 28,000 usages, and it is proposed to
formalize usage of the most popular values of this key while deprecating
less-popular synonyms.  In addition, this proposes to deprecate
protect_class=16 in favor of the hazard key.

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

Re: [Tagging] coastline v. water

[Brian M. Sperlongano]

> there were some attempts to suggest universally mapping bays with polygons
> rather than nodes previously:
>
>
> https://lists.openstreetmap.org/pipermail/tagging/2014-October/thread.html#19775
>
> which however never reached consensus because of the weighty arguments
> against this idea and because it was always clear that this would be a
> non-sustainable strategy for OSM in the long term.
>

It seems to me that consensus is achieved via three, often overlapping
methods, in no particular order:

1.  The proposal process
2.  What's documented on the wiki
3.  How tagging is actually used by mappers and data consumers

Specific discussions on the tagging lists are not necessarily good
indicators of consensus because they are often dominated by whomever
happens to be shouting the loudest and subscribed to the tagging list at
that moment.

With regard to mapping named bodies of water, possibly with fuzzy
boundaries, using polygons, the wiki documents that this is an acceptable
practice, as long as those polygons aren't too large (though, unhelpfully,
without defining what "too large" means).  As you note, osm-carto supports
this method of tagging for marginal seas, and mappers have adopted such
tagging.

Thus, by wiki, and by actual tagging, and by data consumer usage, there IS
consensus - it is acceptable but not required to tag such things as
polygons.  We should not expect mappers to read the minds of people that
are subscribed to this list or comb through years of mailing list archives
to understand how tagging standards have evolved.  The history of how we
got here is irrelevant -- what matters is what exists now, what problems it
may or may not be causing, and what to do about it going forward.

Since you note that there is not a technical limitation, the argument seems
to boil down to "I don't like the standard of verifiability that other
mappers are using."  That is a perfectly valid opinion to have, but it does
not trump de facto, documented usage.  Given the community acceptance of
polygon mapping for smaller marginal seas, it would seem that a formal
proposal is the minimum standard required for documenting that there is
consensus to change de facto usage.

If this is a truly bad idea, and the arguments against such mapping are so
strong, it should be a no-brainer to draft a proposal laying out such
arguments so that the broader community can consider them and demonstrate
true consensus.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Brian M. Sperlongano]

t; San Francisco Bay and connected bays:
> https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
> - outside of the coastline
> > >
> > > Puget Sound - while Lake Washington on the east side of Seattle is
> natural=water, also most of the ship canal connecting them:
> https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000
> > >
> > > I would like to request that the tidal channels and estuaries around
> Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the
> natural-water polygons for the estuaries that is not a problem.
> > >
> > > But it would be contrary to normal practice to map the main body of
> Chesapeake Bay as natural=water because it is clearly part of the sea -
> there is no barrier between it and the open ocean, since there is an open
> channel through US 13 where the tunnel is. While it is an estuary by
> hydrological definitions, so are the Baltic Sea and all fjords and Puget
> Sound and San Francisco Bay - all of which are mapped as outside of the
> natural=coastline.
> > >
> > > Also please consider that the community here approved the proposal for
> waterway=tidal_channel which said that the area of tidal channels (aka
> tidal creeks) should be mapped with natural=coastline at their edges - see
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map
> and
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
> - most of the "creek" features along the Bay are tidal channels.
> > >
> > > -- Joseph Eisenberg
> > >
> > > On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging <
> tagging@openstreetmap.org> wrote:
> > >
> > >> ‐‐‐ Original Message ‐‐‐
> > >>
> > >> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano <
> zelonew...@gmail.com> wrote:
> > >>
> > >>> This was fascinating reading. I do agree that we ought to have a
> definition for what gets tagged natural=coastline, and I think it's fine if
> that definition has some subjectivity.
> > >>>
> > >>> I would offer something as simple as:
> > >>>
> > >>> "The coastline should follow the mean high tide line. In some cases
> this rule would result in the coastline extending an unreasonable distance
> along the banks of tidal rivers. In those cases, mappers should identify a
> reasonable choke point at which to terminate the inland extent of coastline
> tagging."
> > >>
> > >> I would just classify it as "where the ocean meets the land". Any
> other water that isn't ocean should be mapped as water and tagged
> appropriately. That makes the map more accurate and detailed.
> > >>
> > >> R,
> > >> Eric
> > >>
> > >> ___
> > >> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

As time goes on, we will encounter increasingly accurate and resolute
mechanisms for surveying things like coastlines and land cover.  For
example, there are discussions about whether to use things like AI and
machine learning to produce such data.  The demand for ways to deal with
larger objects will only grow in the future

Therefore, a holistic solution is needed for large objects.  Setting an api
limit is good because it gives consumers a guarantee about the worst-case
object they might have to handle.  However, it must also be combined with a
replacement mechanism for representing large objects.  The 2,000 node limit
for a way is fine because longer ways can be combined via relations.  If
the relation member limit were capped, you create a class of objects that
cannot be represented in the data set.

What I think is missing is a way to store huge multipolygons in such a way
that they can be worked with in a piecemeal way.  The answer that
immediately comes to mind is a scheme where large objects are represented
as relations of relations, where portions of a huge multipolygon are
chopped up into fragments and stored in subordinate multipolygon
relations.  This hierarchy could perhaps nest several levels if needed.
Now a 40,000 member relation could be composed of 200 relations of 200
members each, with each subordinate relation member being a valid
multipolygon with disjoint or adjacent portions of the overall geometry.

Then, an editor could say "here is a large relation, I've drawn bounding
boxes for the 200 sub-relations, if you select one, I'll load its data and
you can edit just that sub-relation".

This could *almost* work under the current relation scheme (provided new
relation types are invented to cover these types of data structures, and
consumers roger up to supporting such hierarchical relations).  The thing
that makes this fail for interactive data consumers (such as an editor or a
display) is that *there's no way to know where relation members are,
spatially, within the relation*.  The api does not have a way to say "what
is the bounding box of this object?"  A consumer would need to traverse
down through the hierarchy to compute the inner bounding boxes, which
defeats the purpose of subdividing it in the first place.


On Sun, Nov 22, 2020 at 1:44 PM Simon Poole  wrote:

>
> Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:
> > ..
> >
> > I like the idea of an api limit, though we would need a strategy to
> > deal with existing large objects.
> > ..
>
> This is, "surprise", not a new topic. There are certain issues with the
> semantics of relations which make this slightly more involved as the
> maximum node limit on ways.
>
> See
>
> - https://github.com/openstreetmap/openstreetmap-website/issues/1711
>
> - https://github.com/zerebubuth/openstreetmap-cgimap/pull/174
>
> With the later giving some insights in to why simply declaring a limit
> is not a good idea. But putting a bound in place and expecting all tools
> to be handle relations up to that size (just as we currently do with
> ways) would be a good thing to improve robustness of the whole system.
>
> Simon
>
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

I agree.  I removed such duplicate tagging from my area some time ago, and
it has not affected anything.

I even went so far as to draft a proposal to change that recommendation.

https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members

On Sun, Nov 22, 2020, 11:37 AM Christoph Hormann  wrote:

>
>
> > Dave F via Tagging  hat am 22.11.2020 17:08
> geschrieben:
> >
> > [...] OSM-carto demanding boundaries on ways
>
> ???
>
> I am smelling fake news here.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

Super relations could also solve problems like the Tongass National
Forest.  By crafting a relation of relations, you still preserve the
ability to have one tagged super-object represent one complex thing in real
life, but with natural cut points so that any consumer can choose to deal
with in in manageable stages.  No different from the 2000 node limit on
ways.  There should still be a top level object that represents the whole
thing.

I like the idea of an api limit, though we would need a strategy to deal
with existing large objects.

On Sun, Nov 22, 2020, 11:24 AM Seth Deegan  wrote:

> I recently found out about the Extremely long Amtrak route relations from
> clay_c.
>
> Your message is a bit confusing at first but I think you are proposing
> that relations and super-relations should be used more-often to reduce the
> complexity of processing data for data consumers?
>
> In that case, I would support an API limit on the number of members in a
> relation.
> I agree that developers shouldn't have to handle this burden.
>
> In response to DaveF's comment:
>
>> Actually, splitting way because software can't handle it, is making the
>> database more complex.
>
>
> Yes, but benefits outweigh the costs.
> If the editors did this automatically and still made the data
> interpretable, this wouldn't be an issue.
>
> Sorry if I misinterpreted the conversation.
>
> On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst 
> wrote:
>
>> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
>> wisely]
>>
>> Brian M. Sperlongano wrote:
>> > It seems that we are increasingly doing things to simplify the
>> > model because certain tooling can't handle the real level of
>> > complexity that exists in the real world.  I'm in favor of fixing
>> > the tooling rather than neutering the data.
>>
>> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
>> fix", though I fear I may be disappointed.
>>
>> More broadly, we need to nip this "oh just fix the tools" stuff in the
>> bud.
>>
>> OSM optimises for the mapper, because mappers are our most valuable
>> resource. That's how it's always been and that's how it should be.
>>
>> But that does not mean that volunteer tool authors should rewrite their
>> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
>> make stuff ever more complex and expect developers to automatically fall in
>> line; nor that any given map has a obligation to render this 0.1%, or
>> indeed, anything that the map's creator doesn't want to render.
>>
>> The Tongass National Forest is not "in the real world", it is an
>> artificial administrative construct drawn up on some bureaucrat's desk.
>> It's not an actual forest where the boundaries represent a single
>> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
>> several relations (with a super-relation for completeness if you insist),
>> just as nothing is lost by tagging Chesapeake Bay with the series of
>> letters "c","o","a","s","t","l","i","n" and "e".
>>
>> Richard
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Thanks,
> Seth
> ___
> 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] surface=rock

[Brian M. Sperlongano]

We call them stone walls, but every so often a pedantist comes along and
reminds us that they're actually stone fences.

On Fri, Nov 20, 2020, 5:56 PM Paul Allen  wrote:

> On Fri, 20 Nov 2020 at 22:35, Graeme Fitzpatrick 
> wrote:
>
>> I was having similar thoughts just a couple of days ago, about what to
>> call a pile of rocks that a farmer has cleared from, then piled up in, a
>> field?
>>
>
> In the part of the world I was raised, rocks cleared from fields were used
> to build drystone walls.  Solves two problems with one stone.
>
> --
> 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

Re: [Tagging] surface=rock

[Brian M. Sperlongano]

There is also an undocumented surface=stone, which I tend to thing is
identical to bare_rock.  Though I could see "rock" meaning a rougher
surface than stone/bare_rock.

On Fri, Nov 20, 2020, 5:22 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Nov 20, 2020, 23:14 by dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 20. Nov 2020, at 23:01, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> surface=rock
> surface=bare_rock
>
>
>
> these seem both explicit and ok, although bare rock is a bit redundant
> and rock alone has 5 times the usage:
> https://taginfo.openstreetmap.org/tags/surface=rock
>
> Both for exposed natural rock and steps/footways made of rock pieces?
> ___
> 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] coastline v. water

[Brian M. Sperlongano]

This was fascinating reading.  I do agree that we ought to have a
definition for what gets tagged natural=coastline, and I think it's fine if
that definition has some subjectivity.

I would offer something as simple as:

"The coastline should follow the mean high tide line.  In some cases this
rule would result in the coastline extending an unreasonable distance along
the banks of tidal rivers.  In those cases, mappers should identify a
reasonable choke point at which to terminate the inland extent of coastline
tagging."

This would clearly include bays and coves on the marine side of the coast.
For rivers, local mappers could decide on where the coastline stops by
consensus, and the decision space is limited to a discrete set of
chokepoints in the river geography (or when the river stops being tidal if
the tidal portion is reasonably short).

An objective definition that we can all live with is probably not
achievable, but a partially-subjective one would at least minimize the
arbitrary decision-making while still allowing flexibility for edge cases.


On Wed, Nov 18, 2020 at 5:07 PM Christoph Hormann  wrote:

> > Eric H. Christensen via Tagging  hat am
> 18.11.2020 21:19 geschrieben:
> >
> > [...]
>
> First: the matter has been discussed at length previously so i would
> advise anyone who wants to form an opinion on the matter to read up on past
> discussion where essentially everything relevant has been said already.
> Most relevant links:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-July/054405.html
> and resulting discussion:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-August/thread.html#54434
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
>
> Second:
>
> >
> > Now, some of the feedback that has been presented[2] is that because it
> is tidal it is part of the sea.  [...]
>
> As you can read in the proposal linked above the range of tidal influence
> forms the upper limit of the range practical coastline mapping in areas
> with significant tidal range but as it is in practical mapping not the
> universally used limit.
>
> Third:
>
> While this is ultimately not relevant because the delineation of tags in
> OSM should be based on verifiable criteria obviously i have never seen any
> map that displays ocean water and inland waterbodies in differentiated form
> that shows the Chesapeake Bay as inland water.
>
> Classical examples with differentiated rendering are TPC/ONC (caution:
> links go to large images):
>
> http://legacy.lib.utexas.edu/maps/tpc/americas-pacific-index.html
> http://legacy.lib.utexas.edu/maps/onc/txu-pclmaps-oclc-8322829_g_21.jpg
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Tagging Cycle Route Relations vs. Ways

[Brian M. Sperlongano]

The classic case for a "source" tag is for imports.  It's useful to know
that something came from a TIGER import, or from some public database or
wherever.  I think source=* makes sense when the data is literally coming
from some defined external place.

On Tue, Nov 17, 2020 at 10:36 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> On 17/11/2020 03:09, Seth Deegan wrote:
> > May I ask why not source=*?
>
> TBH. I'm not a fan of the tag. I don't think it adds much value. It's
> too subjective/variable, but...
>
> It relates to the individual contributor editing individual objects. A
> contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
>
> >  many times I find myself wondering where past mappers got the info
> > for a route (this happened just today).
>
> Anecdotal guesstimate: For cycle route - on the ground via signage for
> the vast majority. I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.
>
> DaveF
>
>
> ___
> 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] Tagging Cycle Route Relations vs. Ways

[Brian M. Sperlongano]

I don't map cycle routes, but the issue sounds similar to hiking routes and
administrative boundaries.

Long-distance hiking trails often traverse regular roads in between
stretches of woods.  So the trail's route relation is named "Such and Such
long distance trail" or whatever, but the parts on the road would have the
ways named according to whatever the road's name is.  For sections of trail
that are dedicated to the long distance trail, it may or may not have the
long distance trail's name repeated on the way.

For administrative boundaries, it is common (but not universal) to
duplicate relation tagging on member ways.  Both the relation AND the
member ways might have boundary=administrative, admin_level=, place=, etc.
This is something I run into because I develop an application that consumes
boundary data.  The duplication is unnecessary and just contributes to
database bloat.  I've actually gone as far as drafting a proposal [1] to
change the documentation that currently suggests this duplication.

[1]
https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members


On Mon, Nov 16, 2020 at 11:50 AM Volker Schmidt  wrote:

> The ways making up a cycle route typically have names themselves, and the
> Route name normally is not the name of the way,
> Hence in many cases this would be a mapping error, i.e. the name of the
> way is not correctly tagged in the database.
>
> There may be exceptions to this general, abstract statement, so it would
> be useful if you could five pointers to specific examples.
> For example it is well possible that a local administration assigns the
> name of the Route as name to a specific way that is part of the Route, so
> certainly any corrections need either local knowledge or street level
> photos that show name signs (e.g. Mapillary)
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4670866037759433494_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, 16 Nov 2020 at 17:22, Seth Deegan  wrote:
>
>> The Cycle Routes Wiki Page
>> 
>> states:
>> "It is preferred to tag the cycle routes using relations instead of
>> tagging the ways."
>>
>> If I come across a route that has the Ways already tagged with the name
>> =* of the route, can I
>> delete the name =*s in the
>> Ways and just create a Route Relation with the name?
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>>=* and source
>>=* (like the official
>>map of the route).
>>- Ways with two or more routes wouldn't be tagged name
>>=route 1 & route 2
>>
>> 
>>  and
>>instead have their respective Relations. This could help with preferred
>>routing/data usage in general.
>>
>>
>> I would propose that *all* routes and their names should be tagged in a
>> Relation and *never* the Ways, even if the Route Relation only has *one
>> member*.
>>
>> This way data consumers know that all Routes are going to be relations.
>> Also future Routes mapped that share the Way of a Route that does not have
>> Relation, won't require the mapper to shift all of the data stored in the
>> Way to a new Relation.
>>
>> Also, if Proposed features/Relation:street
>>  is
>> ever approved, this would help establish a consistent OSM-wide routing
>> standard.
>>
>>
>> *As for now*, I do not think that we should be deleting the name
>> =*s of Ways. However, I
>> think osm-carto *should* render and *prefer* to render Relation names
>> for Cycle routes over the names of the Ways. The Editors should also
>> somehow influence users to map Relations for Cycle routes instead of naming
>> them.
>>
>>
>> Thoughts?
>> Seth Deegan (lectrician1)
>> ___
>> 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] Deprecate water=pond?

[Brian M. Sperlongano]

Is a water= tag even needed at all in these cases then? natural=water +
name="Foobar Pond" seems to cover it.  I'm not sure what specific added
information is conveyed by "lake", "pond", or even "lake_pond".  It's a
natural body of water with a name.  If we need tagging to indicate
freshwater vs brackish vs saltwater, or depth, or murkiness, those seem
like separate tags.

On Thu, Nov 12, 2020, 12:26 PM Clifford Snow 
wrote:

> Out of curiosity I decided to look at how USGS defines lakes and ponds
> after noticing that their Feature Code is listed as lake/pond. Here is how
> they define the two, as well as rivers and streams and mountains and hills.
>
>
>
>
>
>
>
> *There are no official definitions for generic terms as applied to
> geographic features. Any existing definitions derive from the needs and
> applications of organizations using those geographic features. The
> Geographic Names Information System (GNIS) database utilizes 63 broad
> categories of feature types defined solely to facilitate retrieval of
> entries with similar characteristics from the database.These categories
> generally match dictionary definitions, but not always. The differences are
> thematic and highly subjective. For example, a lake is classified in the
> GNIS as a "natural body of inland water”, which is a feature description
> that can also apply to a reservoir, a pond, or a pool. All "linear flowing
> bodies of water" are classified as streams in the GNIS. At least 121 other
> generic terms fit this broad category, including creeks and rivers. Some
> might contend that a creek must flow into a river, but such hierarchies do
> not exist in the nation's namescape. The U.S. Board on Geographic Names
> once stated that the difference between a hill and a mountain was 1,000
> feet of local relief, but this was abandoned in the early 1970s. Broad
> agreement on such questions is essentially impossible, which is why there
> are no official feature classification standards.*
>
>
> I think they are smart to not try to classify lakes and ponds separately.
> Back to the original discussion started by Joseph Eisenberg, I'd be in
> favor of just using water=lake/pond or water=lake_pond.
>
> Best,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] Deprecate water=pond?

[Brian M. Sperlongano]

Subjective, or partially-subjective criteria for tagging are fine.  Several
links to science-based definitions by people that think about such things
were offered earlier in the thread, and they form a fine basis for
documenting what is a lake and what is a pond.  We don't all need to agree
on which tag applies to a specific body of water which might be tagged
either way -- that's a job for a mapper looking at the definition and
making the decision about which is the closest fit, and that's OK.



On Wed, Nov 11, 2020 at 5:17 PM Peter Elderson  wrote:

> There is no "it". Everybody has their own "it", and even that may be
> inconsistent.
> I am not opposed to ponds and lakes - I just don't see a common definition
> coming up without "generally" (but not always), "typically"(but may be
> different), "usually"(except where it's not), "in most countries" (but not
> everywhere) etc etc.
>
> I don't think most bodies of water can be tagged as pond or lake by any
> common standard, in a way that all agree. Nor do I think that is a problem.
>
> Best, Peter Elderson
>
>
> Op wo 11 nov. 2020 om 19:51 schreef Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>>
>>
>> On Wed, Nov 11, 2020 at 12:29 PM Peter Elderson 
>> wrote:
>>
>>
>>> Everybody knows a difference,
>>>
>>
>> If "everybody knows it", then let's define what that difference is and
>> write it down.  That is why this list exists.  It is a bad idea to presume
>> that different cultures and languages share a common understanding and
>> terminology.  The reason we are even discussing this in the first place is
>> precisely because the difference between pond and lake is not universally
>> clear.
>> ___
>> 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] Deprecate water=pond?

[Brian M. Sperlongano]

On Wed, Nov 11, 2020 at 12:29 PM Peter Elderson  wrote:


> Everybody knows a difference,
>

If "everybody knows it", then let's define what that difference is and
write it down.  That is why this list exists.  It is a bad idea to presume
that different cultures and languages share a common understanding and
terminology.  The reason we are even discussing this in the first place is
precisely because the difference between pond and lake is not universally
clear.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate water=pond?

[Brian M. Sperlongano]

If the consensus is to go with a limnological definition - I think that's
fine.  Let's lay out the limnological description of "pond" and "lake" and
let mappers sort out edge cases based on their best interpretation of the
definitions provided.  That's no different than the wetland= tag in which
there are lots of edge cases in the real world that are not quite one or
the other.  I assume there will be cases where "such and such pond" is
properly tagged water=lake and vice versa, but that's fine if there's a
definition to stand on.

If we are going with a "what people call it" definition, then the
distinction is purely redundant and worse may not translate appropriately
into other languages which might have a different array of terms for such
bodies of water.

On Wed, Nov 11, 2020 at 8:30 AM Paul Allen  wrote:

> On Wed, 11 Nov 2020 at 13:12, Brian M. Sperlongano 
> wrote:
>
>> Is it actually desirable to distinguish a "lake" from a "pond"?  If so,
>> what is the difference?  Is it just that a body of water is named "XYZ
>> Pond" versus "XYZ Lake"?  If so, isn't water=pond versus water=lake derived
>> from and redundant with name?
>>
>
> It's possible to make the distinction.  It's not clear-cut.  There are
> several
> definitions which are not entirely compatible with each other, but they
> have more similarities than differences.  Edge cases are hard.
>
> See, for example:
>
> https://lakes.grace.edu/ponds-vs-lakes-whats-the-difference/
> https://www.lakemat.com/whats-the-difference-between-a-lake-and-a-pond/
>
> https://www.des.nh.gov/organization/commissioner/pip/factsheets/bb/documents/bb-49.pdf
> https://www.lakescientist.com/lake-facts/how-lakes-differ/
>
> Most of them agree that lakes have aphotic zones (deep areas that receive
> no sunlight, preventing plants from growing there).  But wave height,
> uniformity
> of temperature, and area of water may play a part.  And, of course,
> there's what
> the locals call it.
>
>>
>> Is there a conceivable scenario where a data consumer or renderer would
>> care about the distinction between these two tags?
>>
>
> Renderers will probably treat them identically  A limnologist would find
> the
> distinction useful.
>
> There is also a distinction between pools and ponds.  However, since pools
> are supplied by a spring or a stream, most can be distinguished by other
> water=* occurring in conjunction with them (a lot of the ponds I've mapped
> are actually pools).
>
> https://www.askdifference.com/pool-vs-pond/
>
> --
> 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

Re: [Tagging] Deprecate water=pond?

[Brian M. Sperlongano]

>
> This doesn't seem like a good idea to me. The boundary between a lake and
> a pond may be hard to measure sometimes, but that doesn't mean it is useful.
>
>  In what way is this distinction useful?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate water=pond?

[Brian M. Sperlongano]

Is it actually desirable to distinguish a "lake" from a "pond"?  If so,
what is the difference?  Is it just that a body of water is named "XYZ
Pond" versus "XYZ Lake"?  If so, isn't water=pond versus water=lake derived
from and redundant with name?

Is there a conceivable scenario where a data consumer or renderer would
care about the distinction between these two tags?

Whether it is called "lake" or "pond" or "hole" or "tarn" or "loch" or even
"sea", these seem to be customary terms rather than distinct features with
definable characteristics.

On Wed, Nov 11, 2020 at 7:35 AM Martin Koppenhoefer 
wrote:

> From what I understood to me it also seems desirable to distinguish a
> "lake" from a "pond", although there may be edge cases and no clear cut
> between both, for many cases it will be clear which one to choose. Maybe
> most could be solved by depth and surface dimensions, but we are generally
> missing the depth information so in practise we can not rely on it.
> I am still not completely sure which water bodies can be characterized as
> a pond (e.g. do all these German words apply: "Teich", "Tümpel", "Weiher"?
> What about "Lache" and "Soll"?) May a pond fall dry? Is there a minimum
> dimension?
>
> Cheers,
> Martin
>
>
>
> ___
> 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] Deprecate water=pond?

[Brian M. Sperlongano]

I normally use the name of the body of water, e.g. Foo Pond gets water=pond
and Bar Lake gets water=lake.  It's not clear to me that they have a
distinction beyond customary naming, and in my area there are ponds bigger
than lakes, though usually the lakes are larger.  If there is no
distinction beyond size, I agree that these tags are redundant, much in the
way that place=island and place=islet are: the comparative size can be
obtained from the geometry.

On Tue, Nov 10, 2020, 12:30 AM Joseph Eisenberg 
wrote:

> The tag water=pond was added with a large number of other types of
> "water=*" in 2011, but it has a poorly defined description.
>
> "A pond : a body of standing water,
> man-made in most cases, that is usually smaller than a lake. Salt
> evaporation ponds should be tagged with landuse
> =salt_pond
> , open-air
> swimming pools — with leisure
> =swimming_pool
> ."
>
> So it might be artificial, like a landuse=reservoir or water=reservoir,
> but smallish. Or it might be natural like a water=lake, but smallish.
> However, nothing on the water=lake page defines a lower limit for the size
> of a lake.
>
> This is a shame, because all the other values of water=* are clearly
> defined as only natural, or only artificial, and waterway=* features are
> also clearly divided. Furthermore, the original lags landuse=reservoir and
> landuse=basin were also clearly artificial, while lakes were natural.
>
> But the biggest problem is that there is no way to define a lower size for
> a lake or reservoir, or an upper size for a pond. And the size of the area
> is easier available from the geometry of the feature, so it doesn't need to
> be mentioned in the tag.
>
> I think the best option is to deprecate water=pond and suggest using
> water=lake for natural lakes, even small ones, and use water=reservoir or
> water=basin (or landuse=reservoir or =basin if you prefer) for the
> artificial ones.
>
> -- Joseph Eisenberg
> ___
> 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] Feature Proposal - Voting - Special Economic Zone

[Brian M. Sperlongano]

The proposal for boundary=special_economic_zone is now open for voting.

Thank you to those that have offered comments and feedback on this
proposal.  Community input has been incorporated into the current version
of the proposal.

Voting link:
https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone#Voting
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Brian M. Sperlongano]

I note that "visitation room" is a term that describes "A room designated
in the funeral home for the deceased to lie before the funeral so that
people can view the deceased."  Conveniently, it carries no religious
connotation.

Some cursory searching indicates that this term is in use both in the US
and the UK:

https://www.lymn.co.uk/funerals/visiting-the-deceased
https://www.us-funerals.com/funeral-articles/funeral-glossary-of-terms.html

On Thu, Nov 5, 2020 at 8:14 AM Paul Allen  wrote:

> On Thu, 5 Nov 2020 at 08:46,  wrote:
>
>>
>> amenity=mourning
>>
>
> Barely acceptable.  It's a verb not a noun, an activity not a place.
>
> amenity=place_of_mourning
>>
>
> Acceptable.  Some would say mourning could happen anywhere, and
> not necessarily for the dead.  But those people miss an important
> fact about English: an arrangement of words may have a
> different meaning from the literal interpretation of the
> individual words.  Compare with "listed building" which
> means a structure (not necessarily a building) which is
> under the legal protection of a national heritage
> organization.
>
> amenity=mourning_room
>>
>
> Unacceptable.  "Mourning room" was the old name for what is now
> known as a "living room" (and was also known as a "parlour"),  A
> room in somebody's house which was pressed into use for the
> display of a corpse when needed.
>
> amenity=viewing_arrangements
>>
>
> This is a verb, not a noun.  It is the process by which plans are
> made to look at a corpse, not the place where the corpse is
> viewed.  In American English it has taken on a meaning
> different from a literal interpretation of the individual words,
> but we use British English in OSM.
>
> amenity=deceased_viewing
>>
>
> That almost works.  But it's a verb not a noun, an activity not a place.
> With additional words it could work, but it would be rather inelegantly
> named.
>
> --
> 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

Re: [Tagging] Basic cartography features missing, why?

[Brian M. Sperlongano]

Welcome!

If you do choose to go down the path of the proposal process, I would
potentially be willing to assist in the proposal drafting.  It is certainly
a bunch of work to get a proposal through, but it's hard because it's worth
doing.  I have a proposal in process now and a few others (hopefully) in
the pipeline.

https://wiki.openstreetmap.org/wiki/User:ZeLonewolf
-Brian

On Fri, Nov 6, 2020 at 4:53 PM Anders Torger  wrote:

> I'd love to help out if the workload and chance of success was reasonable,
> but I'm a bit wary about the tagging proposal process. Most of my mapping
> contributions is simple things like correcting and adding roads so all the
> various online route planners (and indeed bike computers) that use OSM in
> one way or another can work in the areas I spend time. For that the map
> does not need to be complete at all, I just need a graph of roads, and I
> use the regular government-provided maps to actually scout the area.
>
> Recently I got more interested in trying to make actual complete and good
> cartography, make maps that accurately describes the area (to a certain
> detail level) and doesn't require "a real map" on the side for scouting, in
> other words make OSM to be a real map in the areas I live. It would also be
> nice if one could make hiking maps for the mountains. This is an extremely
> ambitious goal, in Scandinavia, and probably many more countries, we are
> used at having really great cartography from a special cartography
> institute which is a part of the government. Previously the maps were
> expensive to get and you could only get it on paper. Today the main aspects
> exists for free in digital form (which is a good thing, it's made with tax
> payers' money after all). Here, this is the gold standard for a
> general-purpose map.
>
> However, when I see there are some key features missing in OSM to be able
> to reach that level, and each of those little features may take years of
> processing from proposal to actual implementation in a renderer (and even
> if a proposal goes through, I suppose it's not guaranteed that it may be
> implemented), then it feels like it's just too much for me, as I'm involved
> in many other volunteer projects too. Mapping is not even my main project.
>
> To make this happen it seems like I will end up with having to implement
> my own style and have my own tile server and using my own tags... it's just
> not feasible. What I have done so far in my own mapping applications which
> works sort of fine is to use ready-made government maps in a custom layer
> for the more zoomed out map (and indeed have an own tile server for that),
> and then switch to OSM for the most zoomed in levels. The limitations in
> name handling and missing names for large areas is less noticed when fully
> zoomed in. But it would be really cool if one could use OSM for the whole
> cartography experience.
>
> As far as I understand, OSM is supposed to be a decentralized and
> semi-anarchistic consensus community that's why the proposal process looks
> like it does, but somehow I was hoping for that there was a strategic work
> group with access to professional cartography expertise that on their own
> could recognize, pick up, and implement both the feature and the guideline
> for baseline type of "must have" features, while tagging proposal process
> would be for more exotic things.
>
> I'm afraid that with this thorough long-haul process and still pretty
> basic cartography features lacking, we may never see them. I understand
> that OSM is a geo database, not a map as such, and it seems like the actual
> map-making hasn't been a top priority but left to third parties, and this
> may be a reason that features required for top quality cartography has been
> left unimplemented for so long.
>
> Another thing with these naming features is while they are indeed
> important to reach professional-grade maps, you need to be a very patient
> and persistent perfectionist to actually care (sort of like an old-school
> cartographer), and have the endurance to continue to care. It's much easier
> to just skip the names that can't be mapped, or make them as a point and
> not care that zoomed out maps don't work well. We've seen plenty of
> desperate/chaotic use of place=locality tag just to get names when there is
> no real support.
>
> If that's the case, then it maybe is better to just relax, let go, and let
> OSM be what it is today and not try achieve what it can't do. For me this
> means going back to just doing road work, and switch to the government maps
> anytime I need a real map. I'm fine with that.
>
> On 2020-11-06 20:19, Andrew Harvey wrote:
>
> All great points there, I've ran into many of those myself. If you're
> interested in helping work on solutions to these, discussion here is
> probably the best place to start, once ideas gain some momentum you can
> start a tagging proposal
> https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that
> 

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Brian M. Sperlongano]

I agree that my examples are outliers in the key.  However, I was pointing
out the existence of a small collection of outliers for cases where the
*place* was too hard to describe and therefore the *thing *or *service *was
described instead.  So if we find ourselves in the position where the place
is too hard to describe, there is precedence in describing the service
being provided.

On Thu, Nov 5, 2020 at 8:43 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 5. Nov 2020, at 16:47, Brian M. Sperlongano 
> wrote:
> >
> > We use amenity=ice_cream and not amenity=ice_cream_parlor, because "ice
> cream" is the amenity being offered.
>
>
> ice cream is more outlier than regular though. And amenity=ice_cream is
> not just for ice cream parlors, it’s also for ice cream stands. And there
> is another tag, amenity=cafe with cuisine=ice_cream, that follows the main
> way of amenity tagging.
>
>
> Cheers Martin
> ___
> 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] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Brian M. Sperlongano]

That is clear and unambiguous terminology that is not religion-specific.  I
would support this.

On Thu, Nov 5, 2020, 2:10 PM António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> In many modern places near cemeteries there's not a room, but several.
> So, I would prefer amenity=place_of_mourning
>
>
> Às 12:39 de 05/11/2020, Peter Elderson escreveu:
>
>
>
>> rate the following "favourable", "acceptable" or "unfavourable"?
>>
>> amenity=mourning
>>
>
> acceptable, though I think an amenity should be a feature, not an activity
>
>
>> amenity=place_of_mourning
>>
>
> favourable. Secondary tags could add details if necessary
>
>
>> amenity=mourning_room
>>
>
> unfavourable. Too specific.
>
>
>> amenity=viewing_arrangements
>>
>
> unfavourable. I think an amenity should describe a feature, not
> arrangements.
>
>
>> amenity=deceased_viewing
>>
>
> unfavourable.
>
>
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Brian M. Sperlongano]

>
>
> amenity=deceased_viewing
>>
>
> That almost works.  But it's a verb not a noun, an activity not a place.
> With additional words it could work, but it would be rather inelegantly
> named.
>

We use amenity=ice_cream and not amenity=ice_cream_parlor, because "ice
cream" is the amenity being offered.  A similar argument for
amenity=fast_food, amenity=bicycle_rental, amenity=fuel, amenity=gambling,
etc.  While I agree that "most" of the values in amenity describe the
place-noun, a decent minority are describing the specific service on
offer.  So, if the place we are describe is "a place where the deceased can
be viewed", deceased_viewing would seem to be a neutral descriptor that
works.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

[Brian M. Sperlongano]

Perhaps deceased_viewing then?  If that's the actual amenity that we are
describing?

On Wed, Nov 4, 2020 at 6:20 PM Peter Elderson  wrote:

> place_of_mourning then? Just like place_of_worship?
>
> One could argue that this misses the point, because it's about viewing the
> deceased and you can mourn anywhere. Then again, you can worship anywhere,
> but in these special places the worshipped entity is usually represented
> and highlighted by objects and decorations, and often actually presumed
> present. The deceased may also be just represented.
>
>
> Peter Elderson
>
>
> Op wo 4 nov. 2020 om 23:30 schreef Paul Allen :
>
>> On Wed, 4 Nov 2020 at 20:50, Tom Pfeifer  wrote:
>>
>>> I was surprised that this tag is rushed into voting despite the
>>> arguments against it even here in the tagging list discussions.
>>>
>>
>> The proposal itself contains paragraphs indicating it is a work in
>> progress
>> rather than a finished proposal.  I would have commented but the wiki
>> is using a black-hole service that has blocked a large chunk of
>> addresses belonging to my mobile network because some open
>> proxies were detected.  This is not really ideal for a mobile
>> service where IP addresses are very volatile.
>>
>>>
>>> Let's summarize the criticism first, and look into the alternative
>>> "mourning room"
>>>
>>
>> Not in current use in British English.  And even when it was used, it
>> generally referred to the room in a house that we now call the
>> "living room."  See
>> https://www.vintag.es/2018/01/living-room-what-we-call-today-was.html
>> Also not really suited to a large, dedicated building with more than one
>> room
>> for this purpose.  It's that "room" bit that is the problem.
>>
>> * Vollis (the proposer) 18 Sep: ""chapel" will be opposed by some for
>>> being religiously connotated"
>>>
>>
>> He was correct.  But it's rare for a proposal to get unanimous approval.
>>
>>>
>>> * Peter Elderson 21 Sep: "I have heard mourning chapel, mourning room,
>>> funeral chapel, funeral room.
>>> Chapel of rest does not seem right to me"
>>>
>>
>> As I understand it, English (British, American or any other variety) is
>> not
>> Peter's first language.
>>
>>>
>>> * Clifford Snow 24 Sep: "Chapel of Rest" sounds to me more like a
>>> marketing term not something we should be using in OSM.
>>>
>>
>> What something "sounds like" to an individual is not a strong determinant
>> of
>> its propriety.
>>
>>>
>>> * Michael Patrick 24 Sep: 'Chapel of Rest' seems to be a dated UK
>>> specific term.
>>
>>
>> It's what they're known as in my part of the UK.  So still contemporary
>> in at least
>> parts of the UK.
>>
>>
>>> ... The euphemistic 'Chapel of Rest' is more generically known as
>>> 'Viewing /Visitation Service',
>>>
>>
>> "amenity=visitatation_service" makes even less semantic sense than
>> "amenity=mourning_room."  It's not a term I've encountered, anyway.
>>
>>
>>> * 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the
>>> goat to the butcher...
>>>
>>
>> That sentence no sense makes.
>>
>>
>>> * 28 Sep: since OSM is an international project, my practice is to make
>>> it as easy as possible for non-native English users.
>>>
>>
>> That is why editors have translations of their presets.
>>
>>>
>>> Indeed, the proposed value contains 'chapel' which is biased to
>>> christian religion.
>>
>> It might be used in British English, however that is biased itself for
>>> having
>>>
>> Christianity as a cultural background.
>>>
>>
>> Congratulations.  You have successfully argued that we must change from
>> using British English to the language of a country which has no
>> religious cultural background whatsoever.  Offhand, I can't think of
>> such a country but why should that stop us?
>>
>> "Chapel of rest" is an euphemism that avoids death-related terminology,
>>> butmight be mistaken for a chapel where somebody could rest along a hiking
>>> or pilgrim route.
>>
>>
>> Except that the correct name for such a chapel is "chapel of ease" not
>> "chapel of rest."
>>
>>
>>> OSM is a map for the whole world, and it does not improve acceptance
>>> when
>>>
>> a bunch of old white males (such as myself) chose a biased term for a
>>> feature
>>>
>> that naturally exists in other cultural/religious contexts as well.
>>
>>
>> Do other religions have such places?  If so, what do they call them?  And
>> can we then abstract a neutral name from that?
>>
>>
>>> To close with an alternative, "mourning room" would be a neutral
>>> alternative from my perspective, reflecting the process of mourning which I
>>> suppose exists in all cultures.
>>>
>>
>> I object to room being applied to a building which may have many such
>> rooms.
>> I'd have less of a problem with amenity=mourning.
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging 

Re: [Tagging] Update - RFC - Special Economic Zones

[Brian M. Sperlongano]

I appreciate the pointed questions offered here.  See responses in-line:

On Tue, Nov 3, 2020 at 4:37 AM Frederik Ramm  wrote:

> Hi,
>
> my opinion is that stuff that is not visible on the ground and not
> meaningfully editable by mappers needs a very strong reason to be mapped
> at all.
>
> 1. Are SEZ boundaries visible on the ground (signage, physical separation)?
>

Both types of SEZ boundaries exist.  Some are tagged with signage and
physical separation (as in the example photo in the proposal) and others
are legally-defined but invisible lines.  This is the exact same situation
as with all other values of boundary.  boundary=administrative,
boundary=postal_code, boundary=protected_area, and
boundary=aboriginal_lands are all examples of boundaries which sometimes do
and sometimes do not manifest in physical features on the ground.  Mapping
SEZs is consistent with this usage, and has been listed in the wiki under
the tag protect_class=23 for 10+ years.

If SEZs should not be mapped by this criterion, then all 2 million usages
of the key boundary= should also not be mapped.  We have formed a consensus
through usage that boundaries of various types should be mapped, regardless
of whether or not those boundaries physically manifest in features on the
ground.


> 2. If not, do SEZ boundaries usually coincide with existing
> administrative boundaries (counties X and Y as well as the city of Z
> together form the SEZ)?
>

Both cases exist.  Some SEZs are defined in terms of existing boundaries,
and others have dedicated boundaries.  This is similar to the case of
boundary=postal_code.


> 3. If not, how would you get your hands on the SEZ boundary?
>

By definition, an SEZ is an area in which laws are different from outside
the zone.  Implicit in that definition is the requirement that the boundary
be legally defined.  It is in those legal definitions that mappers can plot
such zones.  This is no different from the manner in which we are able to
map boundary=administrative and boundary=postal_code.

4. In how far is it useful for mappers to modify the SEZ boundary based
> on their knowledge or aerial imagery?


In places where the SEZ manifests in physical objects (signs, fences,
entrances, etc.), such knowledge or aerial imagery is indeed useful for
mapping such boundaries.  In the absence of these, mappers can use legal
definitions.  This is again no different from how we deal with
boundary=administrative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Update - RFC - Special Economic Zones

[Brian M. Sperlongano]

I would say that the Chinese mapping community should decide which of these
areas fit the definition of an SEZ, and tag those areas accordingly.  The
Wikipedia article on SEZs (
https://en.wikipedia.org/wiki/Special_economic_zone) has both a definition
as well as a list of sub-categories of SEZs that local mappers can apply to
specific zones.

This proposal does not create a fully-comprehensive tagging scheme for
SEZs.  The different types of SEZs that you note perhaps ought to have new
tagging invented in order to indicate the specific types of SEZ or any
other characteristic.  I would welcome that as a follow-on proposal to
provide further definition and specificity to SEZ tagging.  This proposal
is deliberately and narrowly focused on gaining consensus on the top level
tag only (all SEZs are tagged boundary=special_economic_zone), while
leaving open the question of what further sub-tagging might be necessary to
more specifically tag these areas.

On Mon, Nov 2, 2020 at 11:47 PM Phake Nick  wrote:

> How do you identify different types of soecial ecobomic zones? For
> exmaple, in China, you have Hainan, which is a special economic zone for
> tourism, you have Shenzhen, which is for policy innivation, you have
> Tianjin Binhai new area, which is for logistics, you have a Cloud computing
> special management district in Chongqing for internet, you have Shanghai
> Waigaoqiao free trade zone for tax, you have Pingtan comprehensive
> experiment zone for cooperation with Taiwan, and then you also have Qianhai
> Special economic zone which is a service and industry themed zone within
> the special economic zone of Shenzhen.
>
> Which of them should/shouldnt be tagged as special ecobomic zone? How to
> differentiate between them?
>
> 在 2020年11月3日週二 11:55，Brian M. Sperlongano  寫道：
>
>> Folks:
>>
>> Last week I opened an RFC for the proposed new tag
>> boundary=special_economic_zone.  That announcement generated only minimal
>> discussion, resulting in a minor change to the proposal to address the
>> concern raised.  I am sending this update to ensure that the community has
>> adequate opportunity to provide input.  If no significant comments are
>> received, I intend to proceed to a vote starting on 9 Nov, after the
>> two-week minimum comment period has elapsed.
>>
>> Proposal:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone
>> ___
>> 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

[Tagging] Update - RFC - Special Economic Zones

[Brian M. Sperlongano]

Folks:

Last week I opened an RFC for the proposed new tag
boundary=special_economic_zone.  That announcement generated only minimal
discussion, resulting in a minor change to the proposal to address the
concern raised.  I am sending this update to ensure that the community has
adequate opportunity to provide input.  If no significant comments are
received, I intend to proceed to a vote starting on 9 Nov, after the
two-week minimum comment period has elapsed.

Proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

[Brian M. Sperlongano]

 The use of the proposed access tagging on roads to indicate whether or not
a private hire/rideshare can drive on them I think we can all agree is
straightforward, but it gets muddy when talking about other types of
infrastructure that this might apply to.

I would like to better understand how such access tagging would work in
practice for an example at my local airport.  In that instance, the
designated Uber pickup/dropoff location is a particular spot within a
specific parking garage (tagged with amenity=parking + building=yes).  Do I
add private_hire=designated to the building?  Okay, that can work.  But
then, adding operator=Uber doesn't work -- after all, Uber isn't operating
the parking garage, they just have permission to make pickups at a
particular signed location.  This tells me that a POI that's separate from
the parking garage object is needed to indicate the precise pickup location
within the garage.  Are we saying that's amenity=taxi +
private_hire=designated?  That doesn't work because a taxi stand implies
on-demand transportation.  I would just ask that we consider the full
picture of how designated private hire/rideshare tagging should be done at
airports and other transportation hubs; without that "big picture", merely
focusing very narrowly on the access attribute feels incomplete.

On Sat, Oct 31, 2020 at 4:03 PM Simon Poole  wrote:

> I think there is a bit of a misunderstanding here.
>
> This is not about taxi stands or anything similar, but about access for
> Lyfts, Ubers, Grabs employees to streets and infrastructure that they would
> not be able to utilize if they were driving for themselves (including
> actual ride sharing :-)). Example pick up and drop off access at airports
> and similar, this might include access to taxi dedicated infrastructure
> too. This is quite legit and no beef with the companies wanting to be able
> to model this to improve routing for their drivers and customers.
>
> Simon
> Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:
>
> In the United States at least, there is a very real difference in meaning
> between "rideshare" and "taxi" services when it comes *specifically* to
> access at airports.  And I believe that is the intent of this proposal: how
> do I tag the special area in the airport where I must go in order to be
> picked up by XYZ rideshare company?
>
> At an airport, if you wish to take a taxi, you walk up to a taxi stand
> (amenity=taxi), where the taxi cabs line up, and you take the first taxi
> cab in line.  This is an explicit area where only taxis queue up.
>
> Alternately, if you wish to take a "ride share", you are using an app to
> make an arrangement with a specific vehicle and driver to be picked up at a
> specific location.  In this case, airports often (at this point, probably
> "usually") have a specified location where such ride shares are allowed to
> pick up and/or drop off passengers.
>
> In some cases, the ride share pickup/drop-off locations have specific
> areas that are different for different ride share providers.  For example,
> at my local airport, due to disagreements about how much these companies
> should pay the airport for curb access (really), there is one location
> where you can pick up a Lyft, and a separate location 100 meters away off
> the airport property where you can pick up an Uber!
>
> The point here is that in the US there is a very real distinction between
> these two classes of objects, and the information someone traveling through
> the airport looking for ground transportation would want to know is:
> 1. Is it a ride share (pre-arranged pickup) or taxi stand (on-demand
> pickup)
> 2. Is it limited to only specific ride share companies?
> 3. Is it pickup only, dropoff only, or both?
>
>
>
> On Sat, Oct 31, 2020 at 6:36 AM Simon Poole  wrote:
>
>> For starters I would oppose using the term "rideshare" for what is a
>> taxi/chauffeur service. It should be noted that there are actual rideshare
>> organisations and services out there, but uber, grab, lyft etc. are not
>> among them, they are simply trying to co-opt a term with positive
>> associations for their operations.
>>
>> Further, real rideshare services don't get special access treatment
>> anywhere I know of, outside of vehicle occupancy regulations, which isn't
>> surprising as real ride sharing simply involves sharing costs and car on a
>> trip that the driver was going to make anyway.
>>
>> If there are actual legal differences between taxi and chauffeur access
>> somewhere, we could use chauffeur or chauffeur-driven as an access tag
>> (better suggestions welcome).
>>
>> Simon
>>
>> ..
> ___
> 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 - Rideshare Access

[Brian M. Sperlongano]

>
> Actually I quite like "private_hire" as an access value.


Are you suggesting access=private_hire as a tag?  That would not be
consistent with how taxi services are tagged.  We don't use access=taxi, we
use amenity=taxi + taxi=*.  By that logic, the access tagging should use
private_hire=*, and probably with some value of amenity=.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

[Brian M. Sperlongano]

> Also private hire, which need to be booked in advance and have the same
> access rights/restrictions on the public highway as a private car. For some
> reason I cannot fathom, in London private hire are called minicabs.
>
> Uber and Lyft are legally private hire so whilst there may be a case for
> access tags covering private hire there should not be a separate tag. If
> different companies use different points at an airport that can be covered
> by operator=*.
>

Whether such things are called "private hire", "ride share", "mini cabs",
or any other term, this class of transportation is distinctly different
from what is described in amenity=taxi, which is a place where taxis wait
for passengers.

What is being described here is a place where passengers wait for their
privately arranged transportation.  A new key rideshare= is probably not be
the right way to tag such places (and, it seems from your comments, not
even the right terminology in British English).  Perhaps this better fits
under the amenity key, perhaps as simply as:

amenity=private_hire
operator=Uber
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

[Brian M. Sperlongano]

In the United States at least, there is a very real difference in meaning
between "rideshare" and "taxi" services when it comes *specifically* to
access at airports.  And I believe that is the intent of this proposal: how
do I tag the special area in the airport where I must go in order to be
picked up by XYZ rideshare company?

At an airport, if you wish to take a taxi, you walk up to a taxi stand
(amenity=taxi), where the taxi cabs line up, and you take the first taxi
cab in line.  This is an explicit area where only taxis queue up.

Alternately, if you wish to take a "ride share", you are using an app to
make an arrangement with a specific vehicle and driver to be picked up at a
specific location.  In this case, airports often (at this point, probably
"usually") have a specified location where such ride shares are allowed to
pick up and/or drop off passengers.

In some cases, the ride share pickup/drop-off locations have specific areas
that are different for different ride share providers.  For example, at my
local airport, due to disagreements about how much these companies should
pay the airport for curb access (really), there is one location where you
can pick up a Lyft, and a separate location 100 meters away off the airport
property where you can pick up an Uber!

The point here is that in the US there is a very real distinction between
these two classes of objects, and the information someone traveling through
the airport looking for ground transportation would want to know is:
1. Is it a ride share (pre-arranged pickup) or taxi stand (on-demand pickup)
2. Is it limited to only specific ride share companies?
3. Is it pickup only, dropoff only, or both?



On Sat, Oct 31, 2020 at 6:36 AM Simon Poole  wrote:

> For starters I would oppose using the term "rideshare" for what is a
> taxi/chauffeur service. It should be noted that there are actual rideshare
> organisations and services out there, but uber, grab, lyft etc. are not
> among them, they are simply trying to co-opt a term with positive
> associations for their operations.
>
> Further, real rideshare services don't get special access treatment
> anywhere I know of, outside of vehicle occupancy regulations, which isn't
> surprising as real ride sharing simply involves sharing costs and car on a
> trip that the driver was going to make anyway.
>
> If there are actual legal differences between taxi and chauffeur access
> somewhere, we could use chauffeur or chauffeur-driven as an access tag
> (better suggestions welcome).
>
> Simon
> Am 30.10.2020 um 19:42 schrieb Clare Corthell via Tagging:
>
> Hi Everyone,
>
> Thank you for the input and feedback thus far, any outstanding commentary
> is welcome. Amendments to the proposal include a definition of rideshare,
> example companies, and comment responses on the Discussion page. In-line
> comments here.
>
> Anyone who would like to comment or bring up outstanding questions, please
> do so for another week. At the end of next week, this proposal could move
> to voting.
>
> Best,
> Clare
>
> On Thu, Oct 15, 2020 at 2:41 AM nathan case 
> wrote:
>
>> Clare: this is a good discussion to have.
>>
>>
>>
>> It seems as though the emergence of rideshare services is still being
>> addressed at various legal levels but, at least in the UK, rideshare
>> vehicles are not classed taxis and so are not ordinarily entitled to use
>> bus/taxi lanes. If situations exist where rideshares are specifically
>> allowed (or not), and that access is distinct from taxi or a regular
>> motor_vehicle, then a key should exist to denote that. I note that the
>> proposal has been updated to reflect such cases.
>>
>>
>>
>> > Joseph Eisenberg: But you will also need to add a definition of a
>> "rideshare vehicle", since this will need to be translated for places where
>> Lyft and Uber do not operate, and where English is not used (e.g.
>> Indonesia). Unfortunately I don't see a good online source for a definition.
>>
>>
>>
>> Perhaps such definitions are dependent upon local/national legislation.
>> In your follow on examples, do those services enjoy the same access rights
>> as PSVs? If yes, then perhaps they should simply be covered by that tag? If
>> they do not, do they have any additional or fewer access rights than simply
>> motor_vehicle/cycle? If not, then perhaps they should simply be covered by
>> those respective tags?
>>
>
> The legal designation could derive from venue/airport, local, county,
> state, or federal law. Just as u-turns are always technically legal in
> California unless prohibited, while in Washington they are prohibited
> unless permitted, there are local laws that are required to fully
> contextualize map data but are not represented within it. I don't foresee
> rideshare being default prohibited, so perhaps the example is too extreme,
> but nevertheless the goal is to encode the specific implications of local
> law for a given rideshare vehicle rather than law generally.
>
>
>>
>>
>> So a definition 

Re: [Tagging] Feature Proposal - RFC - Special Economic Zones

[Brian M. Sperlongano]

That is an excellent point - perhaps a better definition would say:

"A *special economic zone (SEZ)* is a government-defined area in which
business and trade laws are different."

This leaves the scope open and allows for future subtagging for future
specificity.

On Sun, Oct 25, 2020 at 10:39 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 25. Oct 2020, at 15:24, Brian M. Sperlongano 
> wrote:
> >
> > The point is to provide a standard, non-cryptic, foundational tag for
> such areas.  Perhaps future proposals might further propose tagging for
> which level of government has declared the SEZ, or the type of SEZ, or any
> other aspect of an SEZ that might be appropriate for OSM tagging.
>
>
> My questions were aiming at helping you to find a suitable definition,
> because the word “country” limits the scope to specific situations, and
> this is not something that could be fixed later with subtagging.
>
> Cheers Martin
> ___
> 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 - Special Economic Zones

[Brian M. Sperlongano]

SEZs are certainly not de facto.  By definition, they are defined by laws
that apply only to a certain area.  Therefore, they are both defined by a
government, and have defined geographic limits.

As to whether an SEZ is defined by a national government, or a sub-national
government, that question is irrelevant.  The definition works just fine
regardless of which government entity passes the law creating the SEZ.  The
point is to provide a standard, non-cryptic, foundational tag for such
areas.  Perhaps future proposals might further propose tagging for which
level of government has declared the SEZ, or the type of SEZ, or any other
aspect of an SEZ that might be appropriate for OSM tagging.  This proposed
tagging leaves open the possibility for future extensions.

And finally, to the question of "who decides if it is an SEZ", that is a
task correctly left to local mapping communities.  By community editing,
Wikipedia has managed to muster a considerable list of these zones in
https://en.wikipedia.org/wiki/List_of_special_economic_zones, and we should
equally trust that local communities are capable of deciding what tagging
may or may not be appropriate in different countries.

On Sun, Oct 25, 2020 at 6:59 AM Martin Koppenhoefer 
wrote:

>
>
> Am So., 25. Okt. 2020 um 05:34 Uhr schrieb Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>> A special economic zone (SEZ) is an area in which the business and trade
>> laws are different from the rest of the country.  Only a small number of
>> these areas are mapped so far, however, estimates put the total number of
>> SEZ worldwide at between 2,700 and 10,000.  The proposed tagging for these
>> areas is boundary=special_economic_zone, which has minor existing usage.
>>
>
>
> who is it who defines this status, is it defacto or does the national
> government have to define these? What if the business and trade laws are
> not defined on a national level? Which "business and trade laws" are meant
> (does any exception to a "business or trade" law in a are lead to the
> (implicit) constitution of such a zone? Which laws are relevant?). What if
> the national government does not control the area?
>
> I agree that for those cases, where the zone is explicitly defined by a
> national government, this would be easy to determine, but all other cases
> which might fall under the definition, are harder to decide.
>
> Cheers
> Martin
> ___
> 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] Feature Proposal - RFC - Special Economic Zones

[Brian M. Sperlongano]

A special economic zone (SEZ) is an area in which the business and trade
laws are different from the rest of the country.  Only a small number of
these areas are mapped so far, however, estimates put the total number of
SEZ worldwide at between 2,700 and 10,000.  The proposed tagging for these
areas is boundary=special_economic_zone, which has minor existing usage.

In addition, it is proposed to deprecate the tag protect_class=23, which
has near-zero usage, in favor of this named tag.

The proposal can be found here:

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

I look forward to your comments and discussion.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

[Brian M. Sperlongano]

With the exception of the "plurality votes wins" aspect of this, it strikes
me that this can largely be done today.  Someone could post a wiki page
with multiple alternatives and ask the community to vote/comment on
different tagging schemes.  Once a winner emerges, the author could then
move that specific option to a final yes/no vote on the most popular
alternative.

If, after that, a >74% yes vote cannot be achieved, there simply is not
enough community consensus to move forward with the change.

On Mon, Oct 12, 2020 at 6:23 PM Andrew Harvey 
wrote:

> I wrote about changing from a for/against vote to a pick your preferred
> option at https://www.openstreetmap.org/user/aharvey/diary/394419
>
> Interested to hear what others think about this.
> ___
> 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] [Talk-us] Large fire perimeter tagging?

[Brian M. Sperlongano]

On Tue, Sep 29, 2020 at 5:11 AM Warin <61sundow...@gmail.com> wrote:

> We don't mapped parked vehicles unless they are 'permanent', same should
> be adopted for fires, floods, earth quakes and volcanic eruptions.
>
> If there is no permanent effect then mapping it is at best a temporary
> thing.
>

Having lived for awhile somewhere with volcanic eruptions, this is not a
good comparison (at least in the Hawaii sense).  Those volcanic eruptions
cause a permanent change to land cover that remains for centuries.
Eruptions that are over 100 years old are still plainly visible in
satellite view, and do not naturally reforest for centuries.  Generally the
only thing that causes a lava field to disappear is that it gets covered by
a new eruption, and these events are typically years to decades apart.
They are very real things on the ground that would be of interest, e.g.,
for hikers traversing over them.  I'm not sure if anyone has ever mapped
volcanic eruption perimeters, but it would seem perfectly reasonable to me
to map inactive lava fields once an eruption is over.


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