[Tagging] Quarry lakes

2020-12-24 Thread Brian M. Sperlongano
A commenter on the reservoir proposal[1] pointed out the existence of
quarry lakes[2], which is a lake that is formed after a quarry has been dug
after a mining operation.  It was suggested that such bodies of water
should be tagged separately from other lakes with a tag such as
water=quarry.

Should quarry lakes be tagged under a separate value from water=lake?

Should quarry lakes be tagged as a subset of lake, something like
water=lake + lake=quarry?

If there is consensus that quarry lakes should be excluded from water=lake,
obviously that impacts how water=lake is defined.

Existing usages:
water=quarry_lake: 37
water=quarry: 27
water=Quarry: 18
lake=quarry: 1

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
[2] https://en.wikipedia.org/wiki/Quarry_lake
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-24 Thread Brian M. Sperlongano
On Thu, Dec 24, 2020 at 9:00 AM Paul Allen  All of which has drifted somewhat off topic, but until we have a
> reasonable understanding of how different legislations handle
> things we don't have a good model of how we ought to go
> about mapping them (or even if we should map them).
>

I'm not sure I understand this.  It sounds like these questions are
perfectly satisfied by fee=* and access=* (and its derivatives, such as
fishing=*), not to mention related_law=* if you really want to get into it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread Brian M. Sperlongano
That doesn't work if the river/stream is modeled as a way only.  Also, it
assumes that every waterfall has a plunge pool - I'm not sure that's the
case.

On Thu, Dec 24, 2020, 12:25 AM Andrew Harvey 
wrote:

> Mind you, you do need any of these tags to determine that. You can
> automatically measure natural=water size where the way contains a waterfall
> node.
>
> On Thu, 24 Dec 2020, 4:14 pm Brian M. Sperlongano, 
> wrote:
>
>> I could see value in tagging them separately.  I.e. "I'd like to swim in
>> a small pool with a waterfall".
>>
>> On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey 
>> wrote:
>>
>>>
>>>
>>> On Thu, 24 Dec 2020 at 10:26, Paul Allen  wrote:
>>>
>>>>
>>>> Isn't that a plunge pool?  https://en.wikipedia.org/wiki/Plunge_pool
>>>> I didn't even know plunge pools where a thing until Kevin Kenny
>>>> mentioned them.  He knows everything.
>>>>
>>>
>>> Probably, but per wikipedia (again I'm no expert on this) "Plunge pools,
>>> or plunge basins, are stream pools formed by the action of waterfalls", so
>>> plunge pools are just a specific type of stream pool, When I originally
>>> documented stream_pool on the wiki after the mailing list discussion the
>>> intent was that plunge pools would be tagged as water=stream_pool.
>>> ___
>>> 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] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread Brian M. Sperlongano
I could see value in tagging them separately.  I.e. "I'd like to swim in a
small pool with a waterfall".

On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey 
wrote:

>
>
> On Thu, 24 Dec 2020 at 10:26, Paul Allen  wrote:
>
>>
>> Isn't that a plunge pool?  https://en.wikipedia.org/wiki/Plunge_pool
>> I didn't even know plunge pools where a thing until Kevin Kenny
>> mentioned them.  He knows everything.
>>
>
> Probably, but per wikipedia (again I'm no expert on this) "Plunge pools,
> or plunge basins, are stream pools formed by the action of waterfalls", so
> plunge pools are just a specific type of stream pool, When I originally
> documented stream_pool on the wiki after the mailing list discussion the
> intent was that plunge pools would be tagged as water=stream_pool.
> ___
> 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] Definition of lake/pond as applied to stream/plunge pools

2020-12-21 Thread Brian M. Sperlongano
> I think you need to expand a little on how to "conflate" a pool with a
> river.  The
> disadvantage of doing so is that the pool then cannot have a name assigned.
>

Sorry, my words were not clear enough here.  By "conflate" I mean that the
pool would simply be part of the river polygon.  See this example near
Boston:
https://www.openstreetmap.org/way/91082432#map=16/42.2615/-71.2764

Note that I explicitly included the phrase "if they are named or
significant in size" to cover the case where a stream pool has a name.  My
intent is to craft the definition in such a way that it allows either
scheme without preference (i.e. part of the river polygon, or a separate
pond/lake polygon with a name).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

2020-12-21 Thread Brian M. Sperlongano
Would this work for addressing schemes that use a hyphenated prefix?

In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix
in addresses to determine which sector of the island an address is
located.  So an address might be something like "99-123 Kamehameha
Highway".  Would this scheme work for an apartment complex that's addressed
something like 99-100 through 99-200 ?

On Mon, Dec 21, 2020 at 1:15 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I like this new tag.
>
> I had proposing something like that on my TODO list.
>
> I added it in https://www.openstreetmap.org/changeset/96211869
> 
> to mark addr:housenumber=1-3 as a single address, not a range
> (based on survey that I remember well)
>
> Dec 21, 2020, 19:05 by tagging@openstreetmap.org:
>
> Okay. In this case I can rename to proposal page to "addr:range".
>
> This new tag:
>
> - applies to nodes and closed ways that have addr:housenumber
> - "addr:range=n" means every nth house is counted in a range
> - "addr:range=even/odd" means every even/odd house is counted
> - "addr:range=all" means every house is counted (default value for a
> housenumber tag with a hyphen in it if no range is given).
> - "addr:range=no" means that the housenumber tag is NOT a range of values
> but rather a single housenumber.
>
> "addr:range=all" is the default because that is what the wiki says and
> what software like streetcomplete suggests. Many buildings with multiple
> housenumbers are tagged like this.
>
> However, software can create different defaults for different countries.
> For example, in the UK a hypenated address most probably means a range of
> even/odd addresses (so "addr:range=2")
>
> What are your thoughts on this?
>
> Also, I had linked the talk-gb thread, which discusses how
> addr:interpolation on closed ways and nodes is already standard. That is
> the problem with suggesting a new tag. This proposal would now require
> informing multiple mappers to switch up the taggong scheme.
>
> Thanks,
> IpswichMapper
>
> --
>
>
> 21 Dec 2020, 15:19 by lon...@denofr.de:
>
> On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging
> wrote:
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
>
> Quick proposal I just created to accept this form of tagging. This follows
> from a discussion on the Talk-GB mailing list.
>
> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
>
>
> Please comment if there are issues with accepting this form of tagging.
>
>
> I dislike this kind of tagging to the point that I've refused to
> support it in Nominatim in the past. See
> https://github.com/osm-search/Nominatim/issues/565 for the full
> disucssion.
>
> The problem is that it makes the interpretation of addr:housenumber and
> addr:interpolation dependent on the presence of another tag.
>
> Note that addr:housenumber=40-48 can be a valid housenumber. Example:
> https://www.openstreetmap.org/way/285077586 So to know if the tag needs
> to be interpreted as a single housenumber or as a housenumber range
> you need to check if the node/way has a addr:interpolation tag in addtion
> to the addr:housenumber tag.
>
> Similarly, a way with addr:interpolation needs to be processed in two
> different ways: If a addr:housenumber is present, then assume it's a
> building and parse the addr:housenumber tag to get the range. If no
> housenumber is on the way, assume it is a good old interpolation line
> and look at the housenumbers along the nodes of the way.
>
> I find this kind of double meaning for tagging confusing and error-prone.
> But I might be fighting wind mills here.
>
> Sarah
>
>
> ___
> 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] Definition of lake/pond as applied to stream/plunge pools

2020-12-21 Thread Brian M. Sperlongano
Discussion on the current reservoir proposal[1] (which seeks to define the
distinction between reservoirs, lakes, and ponds) has brought up the
question of stream/plunge pools[2,3], and how they fit into the lake/pond
definitions.

I've come up with the following text:

"Occasionally a river or stream will form a stream pool or plunge pool,
which are bodies of water that naturally occur along the course of the
waterway. These waterbodies may either be tagged as a lake or (usually)
pond if they are named or significant in size, or else they can be simply
conflated with the river."

Is this distinction satisfactory?  How are folks tagging these features?


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
[2] https://en.wikipedia.org/wiki/Stream_pool
[3] https://en.wikipedia.org/wiki/Plunge_pool
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21 Thread Brian M. Sperlongano
On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm  wrote:


> Our current data model is not suitable for mapping fuzzy areas. We can
> only do "precise". Also, as you correctly pointed out, or basic tenet of
> verifiability doesn't work well with fuzzy data.
>

The current data model works just fine for fuzzy areas: it requires a
polygon combined with tagging that indicates that the area is "fuzzy".
Since the current data model allows both polygons and tags, fuzzy areas
could be mapped just fine from a technical standpoint.

So the one questions is, do we want fuzzy areas, the other is, if we
> want them, how can they be established - because in our current database
> they cannot.
>
> I think fuzzy areas make a lot of sense for cartography, but I strongly
> object to people adding hand-wavy polygons to OSM for fuzzy areas.
>

"Whether we want fuzzy areas" and "how they can be established" is
certainly an open question that requires additional intellectual thought
and consensus-building to achieve.  However, the statement that they
"cannot" be established in our database is simply an opinion, not a
technical barrier.


> Having a nice lettering across the Alps is certainly not a "higher goal"
> for OSM as a whole; forcing fuzzy polygons for that into OSM is
> irrelevant for most and outright damaging for some use cases, and the
> advantage it would have for the one single use case of map rendering
> does not justify it.
>

There are lots of things mapped in OSM that I don't care about.  For
example, I don't care about building outlines.  However, there are lots of
people that do care about building outlines and so they get mapped.  The
fact that I don't care about building outlines is not a good argument for
preventing others from mapping building outlines.  Likewise, the fact that
some don't care about fuzzy areas is an irrelevant argument to those that
wish to have them.

The statement that fuzzy polygons is "damaging" is an argument not based in
fact.  It is not damaging to me to have building outlines, which I do not
care about.  I can simply ignore them.  Likewise, fuzzy areas cause no
damage to people that do not care about fuzzy areas, provided that there is
tagging that distinguishes them from non-fuzzy areas.


> Please stop trying to frame this as "cartographers have a right to abuse
> the data model, and if someone doesn't want that, they need to present a
> viable alternative". We've come very far in OSM without such abuse and I
> don't see why it should suddenly be introduced.


Since "fuzzy areas" are allegedly harmful to the database and data model,
will the DWG be taking swift and immediate action to delete the 49 objects
currently harming the database by the use of the "fuzzy" key?

https://taginfo.openstreetmap.org/search?q=fuzzy

Further, since we have free tagging, there is nothing preventing mappers
(especially ones not party to these conversations) from adding additional
fuzzy areas to the database, mapped with some invented scheme, and
potentially even creating data consumers to consume such invented tagging.
Many tagging schemes in OSM have arisen in this manner.

I think we need to know whether these comments represent the opinion of the
DWG, and whether the DWG is signaling to the community that they will be
taking a heavy-handed approach against mappers that invent schemes for or
create fuzzy areas through the principle of free tagging.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-20 Thread Brian M. Sperlongano
I agree with this interpretation.  sport=* should always be secondary to
some physical feature that is a location in some way related to the sport
(where it is played, where you can get lessons, a shop, etc).

On Sun, Dec 20, 2020 at 6:32 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. Dec 2020, at 22:45, Warin <61sundow...@gmail.com> wrote:
>
> Some examples;
>
> sportbowlsA place where you can play lawn bowls/lawn bowling.
>
> sportkitesurfingTo mark a spot for kitesurfing
>
> sportmultiA sports facility that is suitable for more than one
> sport
>
> sportracquetRacquetball facilities, such as racquetball courts
>
> sportscuba_divingTo mark a spot for scuba diving
>
> sportsurfingA spot for surfing.
>
>
>
> These do not describe the 'sport'/activity but state it is a
> 'place'/'spot' i.e. a physical thing.
>
>
>
> these descriptions are misguided and should be fixed. The tag “sport” is
> about a sport, it is a property, and unlike the wiki says, its presence
> does not even tell in every case that you can exercise the sport at an
> object with this tag. E.g.
> shop=sports
> sport=surfing
>
> The wiki is explicit: “ A sport should normally also be associated with a
> suitable physical feature where it is performed; often this is leisure
> =pitch
>  or leisure
> =trac
> 
>
>
> 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 - Emergency=Rescue Stations

2020-12-20 Thread Brian M. Sperlongano
> Yes, but all proposals suggest a rendering scheme.
>

The proposal process wiki page says "Not a part of the proposals process as
such, but hints for the renderer maintainer will help them out. maybe a
description of an icon (refer Map Icons), or an example mock-up. Usually
may be safely omitted from proposal."

Remember that, at the end of the day, the output of a successful proposal
is a change to the wiki, no more, no less.  It is still up to mappers,
renderers, data consumers, editors, etc., to choose to adopt the changes
specified by an approved proposal.  In practice, approved proposals have a
strong influence on all of those user communities, but at the end of the
day, a wiki page is documentation, not legislation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-20 Thread Brian M. Sperlongano
Note that the shooting_range hazard is specifically about the zone in and
around a shooting range that you should avoid if you don't want to
accidentally encounter a stray bullet (the area of the hazard) rather than
as a tag for a shooting range itself.

On Sun, Dec 20, 2020 at 3:30 PM Jmapb  wrote:

> On 12/19/2020 5:16 PM, Martin Koppenhoefer wrote:
> > I agree with this, there’s a lot of abuse for “pitch”, and these are
> > not arguments for continuing the line, it’s never too late to learn
> > from past errors ;-)
> >
> > leisure=shooting_range might make sense? There are also 4000
> > military=range (is this about shooting? bombing? )
>
> I've been using leisure=sports_centre + sport=shooting for these,
> possibly combined with a building tag for an indoor range. Makes more
> sense to me to giving them a top-level leisure tag unlike all other sports.
>
> The value "shooting_range" is currently in use for the "hazard" key,
> though, and is part of the hazard=* proposal which is currently being
> voted in with flying colors. (
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard )
>
> J
>
>
> ___
> 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 - Reservoirs, lakes, and ponds

2020-12-20 Thread Brian M. Sperlongano
A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is now
open for comments.

This proposal:

  1. Deprecates landuse=reservoir
  2. Provides definitions for:
 a. water=reservoir
 b. water=lake
 c. water=pond

It is clear from various multiple discussions on this topic that there are
still open questions from the original 2011 water=* proposal, as well as
the exact definition of a reservoir, and how they differ from lakes and
ponds.  Previous discussions indicated that there is community support for
maintaining a distinction between lake and pond, rather than eliminating or
merging these concepts.

The definitions posed in this proposal were developed with the help of
considerable community input over the last week, and I want to thank the
numerous folks that collaborated on this.  The real world presents many
edge cases that make it challenging to come up with clear definitions, but
that should not prevent us from trying.

The goal in these definitions is to *describe* rather than *prescribe* how
reservoir, lake, and pond are actually tagged.  This necessarily involves
some degree of subjectivity between the categories, and the proposed
definitions leave it to mappers to make these subjective decisions when a
body of water exhibits some characteristics of more than one of these terms.

As this topic has been discussed ad nauseam for nearly a decade, I hope
that this proposal, discussion, and subsequent vote will allow us to put
this issue to rest, and/or document the level of community support that
exists for different tagging schemes.

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


Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-20 Thread Brian M. Sperlongano
> "Hillock" is quite common in British English


To describe a traffic control device?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
These guys in Texas will let you drive their tank around and shoot things,
for a price:

https://www.oxhuntingranch.com/activities/hunting-shooting/machine-gun-shooting/



On Sat, Dec 19, 2020 at 6:16 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Dec 2020, at 23:59, Jeremy Harris  wrote:
> >
> > I think rifle-shooting was a component of a triathlon in a recent
> > Winter Olympic, too.
>
>
>
> if rifles are „ordnance“ my perplexity dissolves, I did not know the word
> ordnance and looking it up referred me to artillery. I bet you refer to
> biathlon rather than triathlon though ;-)
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
>
> is firing ordnance a leisure activity somewhere? Or a sport?


Hello, let me introduce to you the United States of America.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-19 Thread Brian M. Sperlongano
Historic or abandoned military features, or military ruins, are clearly not
what this proposal is describing.

On Sat, Dec 19, 2020 at 5:44 PM Graeme Fitzpatrick 
wrote:

> On Sun, 20 Dec 2020 at 02:00, St Niklaas  wrote:
>
>>
>> Your text or proposal seems to be focused on modern times.
>>
>
>  Yes, that's right, as it's intended for current, active, military
> establishments only.
>
> Since every town (vesting) or fortress (fort) has its own barracks in the
>> past
>>
>
> Yes, but they are (usually) no longer a military area, so to my mind
> shouldn't be mapped as landuse=military?
>
> I did earlier raise the question of how to deal with historical sites such
> as the ones you pointed out?
>
> "Ex-military bases, now often either historical precincts / tourist
> attractions / possibly ruins only eg Fort Lytton
> https://www.openstreetmap.org/#map=17/-27.41058/153.15263,
> https://fortlytton.org.au/ & many more similar worldwide. They were, but
> are not now military areas, so how should we tag them?
> museum + tourist attraction + was:landuse=military + was:military=base, or
> ignore all reference to "military"?"
>
> We could also include "historic=fort"
> https://wiki.openstreetmap.org/wiki/Tag:historic%3Dfort but that also
> says "a military fort: a stand-alone defensive structure which differs from
> a castle in that there is no permanent residence. There may have been
> temporary housing for the crew", which I have some issues with?
>
> (& I can already hear Paul saying just because it's old doesn't
> necessarily make it historic! :-))
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
Perhaps simply leisure=range, as this would be generic to any type of
facility where one might fire projectiles or ordnance.  You could then
extend that with something like range= to specify what is being fired,
and/or the existing sport= key if it's considered a shooting sport.

On Sat, Dec 19, 2020 at 5:18 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 19. Dec 2020, at 21:35, Paul Allen  wrote:
>
> Or is it always preferable to use sport=shooting + leisure=pitch?
>>
>
> That's an improvement.  Not ideal, because it's practised at a
> range, not on a pitch.  Just because we have other sports that
> have been shoe-horned into leisure=pitch I don't see a good
> reason to continue making that error.
>
>
>
> I agree with this, there’s a lot of abuse for “pitch”, and these are not
> arguments for continuing the line, it’s never too late to learn from past
> errors ;-)
>
> leisure=shooting_range might make sense? There are also 4000
> military=range (is this about shooting? bombing? )
>
> 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 - Tag:traffic_calming=hillocky

2020-12-19 Thread Brian M. Sperlongano
I've seen these in the US also, but I never knew what they were called.  I
understand that the purpose of them is simply to make noise when a car
drives over them, as they don't slow you down in any appreciable way like a
speed bump/hump.

We already have a tag for "a traffic calming device that makes noise when a
car drives over it", which is a rumble strip
(see: traffic_calming=rumble_strip).  Note, I am talking about the kind
that go all the way across the road, and not the kind in the shoulder of
the road that make noise when you veer out of your lane.

I usually think of rumble strips as grooves in the road, but it strikes me
that these micro-speed-bump things are essentially the same thing -- they
make noise when a car goes over it to alert the driver of something.

I'm uncomfortable with hillock/hillocky as a value.  Cursory searches seem
to indicate that this isn't a term in use, in any flavor of English.

On Sat, Dec 19, 2020 at 5:08 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Dec 2020, at 22:53, Jeremy Harris  wrote:
> >
> > traffic_calming=multi_bump  ?
>
>
> or
> traffic_calming=mini_bumps ?
>
> when they come up with something smaller that could still be micro_bumps
> ;-)
>
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
I understand pitch to mean "a playing field" (as "pitch" is not often used
in US English -- we would say "soccer field" for example.).  I don't know
if a shooting range is a pitch or not, but it definitely isn't a playing
field.

On Sat, Dec 19, 2020 at 3:35 PM Paul Allen  wrote:

> On Sat, 19 Dec 2020 at 19:47, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> Is there some good use for sport=shooting_range?
>>
>
> Not in English as she is spoken.  "Shooting range" is not a sport.
> "Shooting" is a sport.
>
>>
>> Or is it always preferable to use sport=shooting + leisure=pitch?
>>
>
> That's an improvement.  Not ideal, because it's practised at a
> range, not on a pitch.  Just because we have other sports that
> have been shoe-horned into leisure=pitch I don't see a good
> reason to continue making that error.  A few bad ones,
> but no good one.
>
> --
> 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] Tagging sewage treatment basins

2020-12-17 Thread Brian M. Sperlongano
With respect to basins, my understanding is that some of these have water
in them all of the time, some of them have water some of the time, and then
there are some that are almost always dry, but become wet only rarely when
they are needed (e.g. for stormwater handling)

Mappers have used BOTH landuse=basin tag as well as natural=water +
water=basin.  Both methods are documented in the wiki (parallel tagging
scheme).

Should basins be tagged as landuse, water, or both?  Or does it depend on
the type of basin?

On Thu, Dec 17, 2020 at 6:07 PM François Lacombe 
wrote:

>
> Hi Joseph,
>
> Le jeu. 17 déc. 2020 à 20:16, Joseph Eisenberg 
> a écrit :
>
>> I don't think mappers can know the maximum volume or capacity of a water
>> reservoir or water basin, unless it is written on a public sign somewhere?
>> We can map the surface area, but knowing the average depth or maximum depth
>> is quite difficult, especially when it is not uniform. However for
>> man_made=reservoir_covered and =storage_tank we have capacity=* (in cubic
>> meters?) and content=water/sewage/etc.
>>
>
> volume, elevation would be optional and mostly got from local signage.
> You may have opendata, knowledge or sometimes measurements.
> Many tags are already available but not used at the proper extent.
> For example, if we add capactiy (in cubic meters) on a waste water basin,
> we could do the same for man_made=covered_reservoir or even water=reservoir
> (if information is available somewhere)
> Look at this water tower hunting website giving many details from ground
> http://chateau.deau.free.fr/rdef/PagesHTML/Sommaires/GermanDossiers.html
>
>
>> The usage is not often tagged yet, since this might be hard for a mapper
>> to know.
>>
>
> Regarding waste water basins, it could be useful to distinguish
> - sand traps
> - oil separator
> - floccuation
> - decanter basins
> - aeration tanks
> and so on...
> https://www.horiba.com/fileadmin/_migrated/pics/Wastewater_Processing_E_.jpg
> That looks complex but easilly guessable from aerial imagery or even
> clearly explained during public visits of facilities.
> We could define simpler values if it helps
>
>
>> Currently for landuse=reservoir and water=reservoir this is some use of
>> reservoir_type= - https://wiki.openstreetmap.org/wiki/Key:reservoir_type
>> - with values of water_storage, sewage, tailings, evaporator, tank,
>> salt_pan, wastewater, slurry, irrigation, aquicultura, cooling, etc -
>> though only the first 4 are at all common.
>>
>> basin=* is used with landuse=basin or water=basin to describe the form
>> and function of the basin:
>>
>>- basin =infiltration
>> - An 
>> infiltration
>>basin  catches
>>storm water and allows it to seep into an aquifer
>>.
>>- basin =detention
>> - A detention
>>basin  catches
>>storm water and allows it to drain slowly into natural waterways.
>>- basin =retention
>> - A retention
>>basin  catches
>>storm water and retains it, forming an artificial pond.
>>
>>
>> And note that salt ponds (used to evaporate salt from sea-water) are
>> tagged as landuse =
>> salt_pond 
>> Pools for swimming are leisure
>> =swimming_pool
>> 
>>
>> I don't see many combinations with usage=* or another tag that might
>> describe how the reservoir or basin is used, so perhaps this could be
>> proposed?
>>
>
>
> That's right, usage=* corresponds to large familiy of activities and more
> specific tagging would be more suitable to describe precise purpose of a
> particular basin
> reservoir_type and basin looks like to refer to reservoir/basin purpose
> but mixes may concepts that may collide (irrigation is a water_storage as
> well)
> Only some values would match with usage=* ones: usage=irrigation is used
> 12k vs reservoir_type=irrigation 50
>
> Waste water processing could be described with less used water_works=*
> man_made=basin (An artifical structure designed to store some fluid, you
> find basins for storm/rain/radioactive water, sewage, oil, ...)
> content=sewage (Let's put waste water inside)
> usage=industrial (It's part of an industrial process)
> water_works=decanter (It's an actual decanter)
> capacity=
>
> I'd find great to use water=* with content=water, substance=water or
> 

Re: [Tagging] Rapids (whitewater) on rivers

2020-12-17 Thread Brian M. Sperlongano
hazard=yes is neither banned nor discouraged.  It was simply not included
in the list of proposed approved tags due to objections raised during the
RFC.  The goal was to approve the hazard tagging that everyone agreed on.
Since hazard=yes has some existing tagging (>600 uses), it would still be
appropriate to document its use - it would just be listed as "in use"
rather than "approved" on its wiki page.

On Thu, Dec 17, 2020, 12:21 PM ael via Tagging 
wrote:

> On Thu, Dec 17, 2020 at 08:29:52AM -0800, Joseph Eisenberg wrote:
> >
> > Also, currently waterfalls (which can be considered very large and steep
> > rapids!) are tagged waterway=waterfall on a node. Other waterway barriers
> > are also tagged this way, e.g. waterway=dam and waterway=weir. Tagging
> > waterway=rapids on a node allows rapids to be tagged like other waterway
> > barriers to travel and similar to waterfalls.
>
> Noone, AIUI, is suggesting otherwise. But in some cases, there may be a
> case for adding hazard=yes.
>
> Other issue with the current wiki entry is that hazard=yes is
> discouraged (banned?), in which case we get an awkward duplication like
> hazard=rapids. Maybe in such a case, one could be more specific
> like hazard=drowning, hazard=rocks, or whatever.
>
> Weirs are another case where some are much more dangerous than others,
> and some may warrant a hazard tag as well. Again a case where
> hazard=yes would be appropriate.
>
> 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] Tagging sewage treatment basins

2020-12-17 Thread Brian M. Sperlongano
I knew them as sewage treatment ponds, but apparently there's a name for
them:

https://en.m.wikipedia.org/wiki/Waste_stabilization_pond

I feel like this a separate class of object that deserves its own tag,
either within or separate from natural=water, or perhaps even subclassed as
water=basin+basin=waste?

On Thu, Dec 17, 2020, 12:24 PM Joseph Eisenberg 
wrote:

> How should sewage treatment facilities be tagged, then?
>
> Isn't sewage 99% water?
>
> I think that most sewage treatment facilities in the USA include open
> settling basins and I would use landuse=basin or water=basin +
> natural=water for these: https://www.openstreetmap.org/way/420075503
>
> -- Joseph Eisenberg
>
> On Thu, Dec 17, 2020 at 1:55 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 17, 2020, 08:02 by dieterdre...@gmail.com:
>>
>>
>>
>> sent from a phone
>>
>> On 16. Dec 2020, at 17:52, Joseph Eisenberg 
>> wrote:
>>
>> You still have to distinguish marine water (outside of the
>> natural=coastline) from inland waters, and distinguishing rivers from lakes
>> is very important for proper rendering of many maps.
>>
>>
>>
>> and it seems landuse=reservoir is used for sewage as well:
>> https://taginfo.openstreetmap.org/tags/reservoir_type=sewage
>>
>> is this appropriate for natural=water?
>>
>> No.
>>
>> ___
>> 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] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Brian M. Sperlongano
Volker,

Thanks for the comments!  For the specific linked case (winding road for
74(!) miles), it seems that is already covered in the proposal -
hazard=curves and its sub-tags cover this, and if it truly is 74
consecutive miles, that I would think it's just fine to tag 74 miles worth
of ways in this way.

With regard to perceived hazards, and degrees of hazards, these are clearly
interesting and complex topics.  I don't know how to address them, but I
like that you're breaking down the problem in a systematic way.  I'm
intrigued and interested in hearing more and/or collaborating on the
topic.  I think we would need to examine a handful of examples to really
understand the space.

That said, I don't think the lack of a generalized approach towards
signed/unsigned/graded hazards should prevent us from formalizing the
30,000 usages of the hazard key.  Mappers have "voted with their tagging"
and we should respect that unless there is a strong reason not to.

On Wed, Dec 16, 2020 at 6:30 PM Volker Schmidt  wrote:

> Brian,
> I am trying to put order in this also in  my own mind.
> I think we should have an approach which is already clearly structured
> towards two things
> A the difference between
> - signposted hazards
> - unsigned hazards perceived by the mappers
> B for hazards that may have different degrees of hazardness (like the
> difficulty classes of hiking paths, MTB tracks, rapids,...)
> we should have solutions that allow a basic tagging plus the option of
> classes of hazardness for advanced mappers
>
> This approach should be put in the hazard proposal, even if at the moment
> the proposal only covers signposted hazards.
>
> Volker
>
> PS be prepared: how do we tag a hazard like this.
> <https://www.google.com/imgres?imgurl=https%3A%2F%2Fi.pinimg.com%2Foriginals%2Ff8%2F1f%2F81%2Ff81f81a46c423165f1ebf46dd63c9d64.jpg=https%3A%2F%2Fwww.pinterest.se%2Fpin%2F446208275551301611%2F=Lf3Kf2ucFsOb3M=12ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu..i=EcY5sJtmk2sheM=1200=1050=1=california%20highway%201%20curves%20for%20next%2074%20miles=firefox-b-d=2ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu>
>
>
>
>
> On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano 
> wrote:
>
>> As the maintainer of the current hazard proposal - I don't really have
>> strong opinions about signed versus unsigned hazards, though I know others
>> do.  However, signed hazards seem to be something that we all agree should
>> be tagged, and this proposal is attempting to approve the collection of
>> usages that we all agree on.  I knew going in that the topic was too big to
>> be able to address every possible hazard that someone might want to tag but
>> we have to start somewhere.
>>
>> So --- consider this proposal a starting point, not the end of the story!
>>
>> There is no reason why hazard tagging can't be expanded from this current
>> base, and since we have free tagging, there is nothing stopping any mapper
>> from either simply inventing their own new hazard tag values or other
>> usages for things not covered, or offering new proposals to expand the
>> usage.
>>
>> On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
>>> > I see this subject directly related to the "hazard" discussion in the
>>> sense
>>> > that I suggested to clearly define the difference between signposted
>>> > hazards/dangers/warnings and un-signed such situations that are
>>> observable
>>> > on the ground, and therefore are subject also to personal judgement.
>>> With
>>> > other words, beyond the question of how to map it, there is also the
>>> > question of what is a rapid or any other hazard.
>>>
>>> I strongly agree. I was planning to vote against the current hazard
>>> proposal on exactly these grounds. There are clear hazards that
>>> are not necessarily signed. I don't see why we need two different
>>> tags.
>>>
>>> This is slightly off-topic in that I am picking up on the
>>> hazard tag rather than rapids. I see no objection to adding hazard=rapids
>>> although that might be redundant unless there exist rapids that are
>>> not hazardous. I suppose shallow rapids might qualify.
>>>
>>> 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
>>
> ___
> 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] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Brian M. Sperlongano
As the maintainer of the current hazard proposal - I don't really have
strong opinions about signed versus unsigned hazards, though I know others
do.  However, signed hazards seem to be something that we all agree should
be tagged, and this proposal is attempting to approve the collection of
usages that we all agree on.  I knew going in that the topic was too big to
be able to address every possible hazard that someone might want to tag but
we have to start somewhere.

So --- consider this proposal a starting point, not the end of the story!

There is no reason why hazard tagging can't be expanded from this current
base, and since we have free tagging, there is nothing stopping any mapper
from either simply inventing their own new hazard tag values or other
usages for things not covered, or offering new proposals to expand the
usage.

On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging 
wrote:

> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
> > I see this subject directly related to the "hazard" discussion in the
> sense
> > that I suggested to clearly define the difference between signposted
> > hazards/dangers/warnings and un-signed such situations that are
> observable
> > on the ground, and therefore are subject also to personal judgement. With
> > other words, beyond the question of how to map it, there is also the
> > question of what is a rapid or any other hazard.
>
> I strongly agree. I was planning to vote against the current hazard
> proposal on exactly these grounds. There are clear hazards that
> are not necessarily signed. I don't see why we need two different
> tags.
>
> This is slightly off-topic in that I am picking up on the
> hazard tag rather than rapids. I see no objection to adding hazard=rapids
> although that might be redundant unless there exist rapids that are
> not hazardous. I suppose shallow rapids might qualify.
>
> 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] Rapids (whitewater) on rivers

2020-12-16 Thread Brian M. Sperlongano
+1

IMHO these are complementary.  waterway=rapids can be tagged from overhead
imagery, and the additional detail of the rapids can be added later by
people with subject matter expertise.

I see this as equivalent to sac_scale=* for hiking trails - it does not
replace the underlying highway=path, it adds more detail as to the type of
path.

Since both taggings are in use (and one is approved), it is appropriate to
document both.  If someone thinks that waterway=rapids should be
deprecated, I think the burden would be on them to propose that.

On Wed, Dec 16, 2020 at 3:58 PM Joseph Eisenberg 
wrote:

> In the year 2020 waterway=rapids has been added a couple hundred times,
> and the other two tags whitewater:section_grade and whitewater:rapid_grade
> have been used about 100 times each:
> https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
> (zoom in to the most recent yet)
>
> I think both tagging methods have their use. The tag waterway=rapids is
> great to add to a node to specify that there are rapids here, and the
> others are good for expert kayakers and rafters who are able to assess the
> rapid grade.
>
> I don't know enough about the subject to make a proposal to clear things
> up, but the existing tags seem to be fine.
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>>
>> The last time I looked, there was no non-deprecated way to map the
>> information that I had.
>>
>> That is sign of bad tagging scheme.
>>
>> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
>> Wiki.
>>
>> Is it enough?
>>
>> I asked here on the mailing list, and the only answers that I got were
>> along the lines of "then don't map it."  So for several years I haven't
>> attempted to map rapids. The ones I know of and want to render, I maintain
>> separately from OSM, because the previous discussion had caused me to label
>> this feature mentally as, "OSM doesn't want this mapped."
>>
>> :( Hopefully this can be fixed so this will not happen.
>> ___
>> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
The statistics reflect all areas, regardless of which editors were used to
create them.  I stand by them, as numbers do not lie.  There was a 3:1
preference for water=reservoir during 2017 and 2018, two years prior to the
change in iD preset.  The data is open, and taginfo provides a very helpful
REST API.  Feel free to conduct your own statistical analysis.

If you are not willing to have this question put up for a proposal (where,
as with any proposal, you are free to present your argument for all to
consider), your arguments are in bad faith, and again, must be dismissed
without consideration.  Your desire to bypass our democratic process and
upend community consensus for tagging you don't like is frankly insulting
to the rest of us that work hard to achieve consensus in tagging.  Why
should we waste time debating you, if you aren't willing to accept the
outcome of the community decision-making process?

On Wed, Dec 16, 2020 at 9:43 AM Tomas Straupis 
wrote:

> Brian, you're using statistics which DO NOT represent mappers preferences.
> If you would use only JOSM created objects - then it would be close to
> mappers preferences (as JOSM allows mappers to choose).
> But you use iD created/adjusted objects and as it does not allow
> showing your preference (drilling down into tags is only a theoretical
> possibility) and even pushes you to overwrite other peoples
> preferences you have to exclude iD tainted objects if you're trying to
> get "community preference" from statistics.
>
> Therefore I would suggest starting with the core - arguments
> advantages/disadvantages of both schemas.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
Tomas,

Since you are not willing to accept (1) an existing approved proposal, (2)
new proposal to correct flaws in the first one, or (3) the overwhelming
preference of the mapping community over the past four years[1], then I'm
sorry but we must curtly dismiss your arguments as a one-man crusade[2,3,4]
against tagging which you do not like.  It is clear that you wish to impose
your views on the community regardless of what the consensus is.  If there
is truly a community of mappers out there that share your view, it should
be easy to convince them to come and vote.  Since you are not willing to
accept the democratic process that we have established, and you do not
respect the viewpoints of others, all you are doing is wasting our time.
Thus I ask you, respectfully, to stop.

If there are others here that desire a proposal for the purpose of
documenting that landuse=reservoir is deprecated, I will gladly do so.
With no proposal, the status quo will remain: landuse=reservoir will
continue to be steadily replaced with water=reservoir, and our wiki will
remain confusing in its documentation of these tags.

[1] https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/Analysis/Reservoir
[2] https://github.com/openstreetmap/iD/issues/7382
[3] https://github.com/openstreetmap/iD/issues/6589
[4] https://josm.openstreetmap.de/ticket/17874


On Wed, Dec 16, 2020 at 8:32 AM Tomas Straupis 
wrote:

> > If you believe that your argument in favor of tagging reservoirs as
> landuse is
> > strong, then you should have no objection to placing this question up
> for a
> > community vote, and allowing the community the freedom to decide.
>
>   Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
> should anybody propose the vote for it?
>
>   I do not like voting on wiki because it is clearly a flawed process
> (as discusses a number of times), what do 20 wiki participants/people
> mean against the actual mappers? We could end up in the same situation
> as with original water=reservoir proposal where somebody with barely
> few months of participation in OSM and no knowledge of GIS/Carto
> makes/influences the decision/proposal...
>
>   And what is a problem of listing benefits of water=reservoir schema?
> If there are none, then the only logical decision is to deprecate
> water=reservoir, because it would make it worse of the two. Shouldn't
> we get ARGUMENTS before we go to any kind of voting/decision?
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
Tomas,

If you believe that your argument in favor of tagging reservoirs as landuse
is strong, then you should have no objection to placing this question up
for a community vote, and allowing the community the freedom to decide.


On Wed, Dec 16, 2020 at 8:01 AM Tomas Straupis 
wrote:

> 2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> > The iD editor preset appears to use water=reservoir while the JOSM
> > preset appears to use landuse=reservoir.
>
>   Not entirely correct.
>   * JOSM gives freedom to mappers and supports BOTH.
>   * iD forces to use water=reservoir and evenmore pushes users to
> change tagging by disguise of "upgrade" - therefore even mappers who
> do not understand/know the difference are inclined to change the
> tagging. <- this is the reason for current stats
>
>   My understanding is that given landuse=reservoir is the original
> water schema, the new one should show some benefits to replace the
> original one? Or we do not care about consistency and simply go on
> with replacing very prominent schemas for no good reason?
>
>   My take is that:
>   * landuse=reservoir is better compared to natural=water+water=x
> because it pushes mappers to make distinction for these
> GIS/Cartographically very different classes of water. Therefore if
> landuse=reservoir is deprecated tagging will be worse.
>
>   What are the benefits of water=reservoir?
>   Given that full scope of proposal to put all water classes under
> natural=water (the purpose which is disadvantageous from
> GIS/Cartography perspective) have failed and we're now only talking
> about two classes of water (natural and man made), and classes which
> are very different and therefore should not be merged.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Brian M. Sperlongano
Thanks everyone for the discussion.

I believe there are two germane points being raised by Tomas that warrant
our consideration:

1. It is not clear from the original 2011 vote which created
water=reservoir (and other values) as to whether the community intended to
deprecate landuse=reservoir or whether the community intended to create two
parallel tagging schemes for the same object.

2. There is some subset of the user base that uses and/or prefers
landuse=reservoir over, or in addition to, water=reservoir.  The iD editor
preset appears to use water=reservoir while the JOSM preset appears to use
landuse=reservoir.  It is unclear whether there is actually a strong user
base preference for either tag or whether the numbers simply reflect the
presets in the editors that users happen to use.  There is also no way to
determine from these discussions alone the size of community support for
either scheme, particularly if such support is factional within non
English-speaking communities.

Given these issues, I would suggest a narrowly-written proposal that puts
forth the clear and specific question as to whether landuse=reservoir
should be deprecated.  If that proposal demonstrates clear community
consensus for deprecation (per the guidelines in our proposal process), we
can update our wiki documentation to explicitly recommend that
landuse=reservoir be gradually replaced by natural=water+water=reservoir.
If, instead, that proposal demonstrates that there is still a sizable
subset of mappers that prefer the landuse=reservoir tag, we would simply
leave both tags documented without caveats, noting the results of both this
and the 2011 proposals, and allow the community to sort out which tagging
scheme is preferred based on actual usage over time.

As I am the one that raised this issue in the first place, I would be happy
to draft such a proposal for consideration.  I want to be clear that in
such a proposal, any instances of disrespectful or insulting commentary
directed towards any group or individual will not be tolerated and will be
immediately brought to the attention of the wiki admins for followup.

Would this be satisfactory to the group in resolving the question of
reservoir tagging?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Brian M. Sperlongano
Wouldn't it be more consistent to keep it in the same key, and call it
place=lake_group?  Or even place=lakes?

Would this be used for something like the Great Lakes in USA/Canada or is
that too large of a feature?

On Tue, Dec 15, 2020, 12:05 PM stevea  wrote:

> +1.  Joseph's suggestion is a fine example of "OSM can and does coin new
> tags on occasion."  Adding a nice boost, there is a suggestion that
> "similar" tagging be used as an example of how to define / use / document
> the new tag.  Great!
>
> On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg 
> wrote:
> > Re: “ a couple of islets with a collective name”
> >
> > We have a tag for that: place=archipelago for a group of islands.
> >
> > There isn’t a common tag for a group of lakes with one name, probably
> because this is only common in some countries, especially near the Arctic
> region. We’ve talked about this issue before but did not find an existing
> tag.
> >
> > I would suggest a tag like natural=lake_group to be added to a
> multipolygon which includes each of the lakes, similar to how archipelagos
> are mapped.
>
> ___
> 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] Changes to clarify the Hazards proposal during the vote

2020-12-14 Thread Brian M. Sperlongano
Hello,

I recently received late feedback on the hazards proposal.  Based on the
feedback, I felt it was necessary to make small changes to this proposal.
I believe these changes are sufficiently minor that they do not invalidate
the voting which has occurred so far.  Since this proposal has begun voting
as of two days ago, I want to ensure that this change is made with full
transparency.  If anyone feels that these changes require a reset of
voting, or an extension of the voting period, I will do so upon request.

The changes are as follows:

1. Clarify that "bump" and "dip" hazards may apply to both artificial and
naturally-occuring dips.  This ensures that the definition of these two
tags are consistent with how those signs are actually used in the real
world, and also ensures that the definitions are consistent with the signs
shown in the sample images.  In addition, a sentence was added to
specifically clarify that this tag should not be applied to traffic control
devices, which have their own tagging.

2. Clarify that it is acceptable to tag both a hazard sign as well as a
hazard itself.  While both of these usages were listed as individually
acceptable, the proposal was silent on whether both approaches might be
used in tandem.

The exact changes to the proposal can be found here:

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Fhazard=revision=2072737=2072735
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-14 Thread Brian M. Sperlongano
On Mon, Dec 14, 2020 at 5:11 PM François Lacombe 
wrote:

> Hi Brian,
>
> Thank you for your comments
>
> Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano 
> a écrit :
>
>> 1. The proposal states "It is proposed to discourage the use of
>> undocumented pump:type=* to state pump mechanisms in favour of new
>> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
>> context.  Given the other threads today regarding reservoirs, it is
>> important to communicate clearly what we mean when we propose to stop using
>> a tag.  I would ask that instead of "discourage", that the proposal should
>> explicitly say "deprecate" so that there is no confusion that you intend
>> for us to stop using pump:type and document it as deprecated in the
>> deprecated features list.  Otherwise, I would ask that you clearly and
>> explicitly state what you mean by "discourage" and where those words of
>> discouragement would go.
>>
>
> To me, discourage means provide a better way to describe features and
> encourage people to do so. Reviewing a proposal and vote approval is a step
> and additional work has to be done in that way.
> I remember a discussion in my early OSM years about sense of "deprecated",
> "discouraged", "approved", "reviewed"... and I'm now merely in favour of
> encouraging and discouraging than enforcing or forbidding
> pump:type isn't documented currently, then how could it be added to any
> deprecated features list?
> The proposal aims to make pump_mechanism approved and then pump:type could
> be added to its wiki page as a possible duplicate.
>

Thanks for the clarification, however it does not quite resolve the
question.  That there is no such status "discouraged".  There is a page
that documents the possible status values[2] used by wiki templates.  To
directly answer your question, since there is no wiki page for the tag (as
in this case), it would be deprecated simply by adding it to the deprecated
features table with no additional action needed.

The wiki[1] says: "OpenStreetMap does not have 'banned features', as
anybody is allowed and encouraged to use any tag they think is useful."
Therefore, deprecating a feature does not "enforce or forbid" the use of a
tag - all it does is set the tag's status to deprecated on the tag's wiki
page, and adds an entry to the deprecated features[1] page.

If you are not proposing to deprecate the pump:type tag, then I think you
need to explain what you mean by "discourage".  Does that mean you will add
a disclaimer to some other wiki page, with a link to the proposal?  I'm not
sure what benefit that brings over simply deprecating the tag.

[1] https://wiki.openstreetmap.org/wiki/Deprecated_features
[2]
https://wiki.openstreetmap.org/wiki/Template:Description/doc#Additional_information
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
I agree with Mateusz that the wiki IS the project's standard document for
the meaning of tagging (from the perspective of data consumers) and how to
tag (from the perspective of mappers).  Note that both perspectives are
important.  But to address the specific point, there is no standard
document for renderer implementers, because there is no such thing as a
standard renderer implementation.  A renderer (something that turns data
into a map) is just one of very many ways to use and visualize geospatial
data.

I know you did not intend to criticize the volunteers that make this
project happen, but consider that when you dismiss the wiki as "no
documentation", it can be interpreted as dismissing the hard work of
countless people that volunteered their time to develop (and translate!) a
large and complex documentation base.  Most software developers find
documentation to be a chore and the last thing they deal with.  That is why
as someone who has the skills, time, and interest to contribute, I've
expended considerable effort improving the wiki's tagging documentation,
and when I've found gaps or problems, I've worked to draft and advance
proposals to address the deficiencies.  I saw a need and began filling it,
and my contributions to that documentation are something I am proud of.

For a project that provides its only product for free, it should be obvious
why the OSM Foundation has a small budget and can't afford to hire more
than a cursory staff for the most critical needs.  Consider changing your
perspective to "what am I able to contribute to make this project
stronger?" rather than "here are the things that are wrong".

As the author of a product that consumes OSM data, I am grateful to all of
the programmers, mappers, and technologists that have built the various
pieces of this ecosystem without which my product wouldn't exist.  It would
be awfully presumptuous of me to complain that this thing provided to me
entirely for free is in some way lacking, and I'm glad I am able to "give
back" in this small way.

This is just a gentle reminder that when you speak of "OSM", you are not
speaking to some big corporate entity with a glass lobby, a receptionist,
and someone to answer the phone -- you are speaking to a loose tribe of
individual volunteers that are collaborating on a free map of the world.

On Mon, Dec 14, 2020 at 4:15 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 14, 2020, 22:03 by and...@torger.se:
>
> Ok, understood. However as far as I know OSM lacks a standard document
> for render implementors to actually know how data should be interpreted.
>
> In part it is https://wiki.openstreetmap.org/ in part it is decision of
> authors of map style how they want map data to be intererpreted.
>
> The only reason I get here is when the OSM wiki doesn't have answers
>
> Yes, you are raising some very interesting cases (for example case of
> mountain
> and peaks named separately).
>
> Even here there are various answers and ideas circulating
>
> This is whole point of tagging mailing list for features with no known
> good way of tagging them. (or where it is not documented)
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
It sounds like what we are asking for is the ability to tag a rough polygon
in the approximate area where a label should be placed for a known but not
strictly bounded toponymic feature (mountain range, water body, etc).  That
would give a hint to renderers as to the location and most importantly,
size, of a label for such features.  This would also solve the current
problem of tagging large coastline-bounded marine features, such as seas,
bays, straits, etc., without creating overly complex polygons resulting
from re-use of the coastline ways.  It would also fix the inability to tag
such basic features as oceans.  When you type "Atlantic Ocean" into any map
other than OSM, it shows you the ocean.  When you type it into
openstreetmap.org, it shows you a super-close zoom-in to a single node -
not very helpful.

It is reductio ad absurdum to say that features like "Pacific Ocean",
"Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a
project that aims to create a map of the world simply because these
features don't have a fence or sign around them to indicate their exact
boundary.  Features exist in approximation in the real world, and it is a
perfectly valid opinion to want those things to appear, also in
approximation, on the map.  These things are verifiable because people know
what these toponyms mean and represent.  If it is possible to write a
wikipedia article on "Indian Ocean", it is possible to draw a rough polygon
in openstreetmap which means "this is roughly where the Indian Ocean is,
and renderers should consider drawing a label".

Note that this is not "tagging for the renderer" (which is often code for
"tagging that I don't like"), these are real, major features that actually
exist in the real world and their absence makes OSM weaker.

On Mon, Dec 14, 2020 at 8:04 AM Anders Torger  wrote:

> To make a specific answer to "what additional verifiable local
> knowledge" this relation is intended to cover, is that the wetland is a
> single named entity, not multiple entities named the same.
>
> And here's some elaboration. This is 4 km wide wetland, in the real
> world named as a single entity, but it does consist of both bog and
> marsh, in the screenshot named each separate part as you suggested:
>
>
> https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
>
> "Verifiable" is tricky in terms of names of natural features as we all
> know, as many of those haven't defined borders. Wetlands maybe so, but
> even in this case, are the small satellite wetlands part of Rijmmoàhpe
> or not? Noone knows, it was never defined. That's the way these names
> work. Does that mean that these type of names should not be in OSM at
> all? You tell me. I just try to contribute geodata to make maps for
> outdoor use. If OSM is not the platform, let me know.
>
> I'm not particularly experienced in how OSM use relations and why the
> are so "obnoxious" as Mateusz put it, but I have worked with arranging
> data in many projects and to me this is an obvious case of data that
> should be arranged as a container with all its parts. I also think that
> it would make it much easier to fix the renderer, it can easily get all
> parts for the single name, and as a added bonus get to know the "master
> type" (instead of having to go through all parts calculate the area to
> figure out which nature that is dominant to get the tag styling right).
> Etc.
>
> I didn't add it thinking about any renderer though, it was actually for
> myself to more easily keep track of all parts when editing on JOSM. With
> a parent relation I just need to click on one, and then on the parent
> relation to get all selected. Otherwise I need to create a filter on the
> name or something, so to me it's also more efficient for the mapper.
>
> And in the end I think that the individual parts should not have name
> tags at all, it should only be on the parent relation. The reason we put
> it on the individual parts now is to me obviously just because there is
> no renderer support available anywhere for naming these type of natural
> entities, and probably will stay that way for the foreseeable future.
>
> Having a relation on these new features makes them easy to find in the
> database and one can upgrade the tags later. I suppose it's much more
> complicated to make a filter to find parts named the same with shared
> borders, I don't really know how to do it in JOSM (but maybe one can?).
>
> So that's my reasons, but if you think they're bad I'll remove the
> relation. I would like to hear how you want to solve the problem instead
> though. As you see on the screenshot, the current situation is far from
> optimal with lots of tiny name tags where there should be only one.
>
> /Anders
>
> On 2020-12-14 13:28, Christoph Hormann wrote:
> >> Anders Torger  hat am 14.12.2020 07:59 geschrieben:
> >>
> >>
> >> I'll gladly answer questions, but I think you need to rephrase. I
> >> suppose it is some hidden critique in 

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-13 Thread Brian M. Sperlongano
François, thank you for your hard work on this proposal!  I will most
likely support this version.  I have a few questions:

1. The proposal states "It is proposed to discourage the use of
undocumented pump:type=* to state pump mechanisms in favour of new
pump_mechanism=*."  It is not clear what is meant by "discourage" in this
context.  Given the other threads today regarding reservoirs, it is
important to communicate clearly what we mean when we propose to stop using
a tag.  I would ask that instead of "discourage", that the proposal should
explicitly say "deprecate" so that there is no confusion that you intend
for us to stop using pump:type and document it as deprecated in the
deprecated features list.  Otherwise, I would ask that you clearly and
explicitly state what you mean by "discourage" and where those words of
discouragement would go.

2.  You propose to deprecate man_made=pumping_rig and propose to replace it
with the (far more popular) man_made=petroleum_well.  Both of these are
combined with the substance=* key.  I would ask whether there are usages of
pumping_rig that are being used with substance=* tags for non-petroleum
products (i.e. not oil/natural gas) which would be lost by abandoning this
pumping_rig?  If the answer is "yes", then I would support simply changing
the description of pumping_rig to explicitly exclude petroleum products,
and if the answer is "no" then I agree with deprecating it.


On Sun, Dec 13, 2020 at 1:48 PM François Lacombe 
wrote:

> Dear all,
>
> Following some rework to take care of comments received during the first
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section
> clearer.
> Classification of pumps is now done with pump_mechanism and is still
> equivalent to which available on Wikipedia. Numerous references are made
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote
> could begin by next Saturday.
>
> Best regards
>
> François
> ___
> 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] Is landuse=conservation actually deprecated?

2020-12-13 Thread Brian M. Sperlongano
I will note that the Massachusetts, USA mapping community does believe that
there is a distinction between the two tags, as noted here:

https://wiki.openstreetmap.org/wiki/Massachusetts/Conservation

However, this usage and definition seems to be specific to that particular
community and is not a widely shared viewpoint.  I was under the impression
that landuse=conservation was deprecated, but if that was resulting from an
arbitrary wiki edit and not a formal proposal, perhaps it should not be
marked deprecated in the wiki.

As to the question of whether landuse=conservation and
boundary=protected_area mean exactly the same thing, I don't think we can
answer that easily, because boundary=protected_area lacks a formal
definition.  My prior, current, and hopefully future proposal(s) are in
part working towards developing that definition of boundary=protected_area,
and aligning its meaning to the way wikipedia defines[1] protected area.

My personal *opinion* is that boundary=protected_area should deprecate
landuse=conservation, but there are certainly multiple viewpoints out there.

[1] https://en.wikipedia.org/wiki/Protected_area



On Sun, Dec 13, 2020 at 12:26 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Recently another wiki user marked landuse=conservation as "deprecated" on
> the Map Features page:
> https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:landuse=11273=2071912=2068278
>
> This same user had marked the page itself as deprecated back in 2017:
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dconservation=revision=1498145=387459
>
> Previously the Tag:landuse=conservation page had been redirected to a
> proposal since 2009:
> https://wiki.openstreetmap.org/wiki/Proposed_features/conservation
>
> *"Conservation land is land protected from development.*
>
> *It is left in more or less a natural state.*
>
> *It is often maintained to a very limited extent, such as annual mowing to
> prevent forest growth, removal of invasive species, replanting, or dealing
> with or preventing erosion.*
>
> *The public typically, but not always, has access, as it is a valuable
> recreational resource. (Sometimes the public has no physical way of getting
> to it, or is not allowed for water protection reasons, safety, etc)."*
> Now boundary=protected_area is probably the more common way to tag this
> concept.
>
> Comparison:
>
> https://taginfo.openstreetmap.org/compare/boundary=protected_area/landuse=conservation
>
> landuse=conservation is declining since 2015:
> https://taginfo.openstreetmap.org/tags/landuse=conservation#chronology
>
> While boundary=protected area mostly increases, though there are some
> jumps up and down from imports I imagine:
> https://taginfo.openstreetmap.org/tags/boundary=protected_area#chronology
>
> Is it correct to say that landuse=conservation has been deprecated,
> practically, by boundary=protected_area
> , even
> though that tag has not been approved?
>
> -- 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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Brian M. Sperlongano
Tomas,

Respectfully, I ask you to cease the pattern of name-calling, personal
attacks, and insulting language used in this forum, and on project bug
trackers[1][2].

Let's please assume good faith and be respectful while we discuss
differences of opinion with an open mind - we are all here for the same
reason - working together to create the best possible map for the world.


[1] https://josm.openstreetmap.de/ticket/17874
[2] https://github.com/openstreetmap/iD/issues/6589

On Sun, Dec 13, 2020 at 10:39 AM Tomas Straupis 
wrote:

> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> > 2019 was a turning point, and over the last two years, landuse=reservoir
> has
> > been on a steady decline, while water=reservoir continued its rapid
> growth.
>
>   New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better, and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
>   And the only reason for change of stat starting 2019 is because
> coders of iD decided to lie to the users that landuse=reservoir is
> deprecated which it never was and started replacing landuse=reservoir
> under their highly controversial disguise of "upgrade tags".
>
>   So the change of statistics is not the preference of mappers but
> preference of some nerds.
>
> > Is it time to more directly recommend that mappers favor natural=water +
> water=reservoir
> > *instead of* rather than *in addition to* landuse=reservoir?
>
>   I would propose to deprecate water=reservoir and even more - add
> guards so that such pointless/nerdy duplicate standards would not be
> introduced in the future.
>
>   Note that one of the main nerdy points of this schema was to have a
> possibility to write sql easier (somebody has problems with "and/or")
> and this would also require riverbanks to fall into this new water
> schema. And riverbank clearly does not fall into that even with iD
> lying about it too. Therefore the only point has failed and this
> stupidity is spreading havoc in tagging of such prominent water
> features for more than 10 years now.
>
> P.S. There is quite an easy solution to have a separate iD instance
> for beginners with correct tagging presets loaded.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Brian M. Sperlongano
This story is offered because I find it interesting, and as a possible
catalyst for updates to our tagging documentation.  I offer apologies to
those that are well aware of this controversy.

There are two competing ways to tag reservoirs: landuse=reservoir, or
natural=water + water=reservoir.  The reservoirs near me all used the
"landuse" version, and so I only recently became aware of the difference
when another mapper pointed it out.

landuse=reservoir was the original scheme (first documented on the wiki in
2008), while water=reservoir came about three years later, in an approved
2011 proposal[1] which added the key "water".  To read the voting
commentary, the proposal was mildly controversial: one user described the
vote as rushed, and another cited an issue we still discuss in 2020:
whether there is a difference between water=lake and water=pond!

The proposal noted among other things that "landuse=reservoir [is replaced]
by natural=water + water=reservoir".  It further went on to state:

"Until all renderers (which render those areas differently from
natural=water) support those new values, both schemes can be used together:
just add natural=water and water=* to already present tags."

And so, mappers began mappers began adding the new tags to the map.  In
mid-2011, landuse=reservoir sat at 180K usages while the newly-invented
water=reservoir had near-zero usages.  The proposal described that mappers
should use both tagging schemes until renderer support was achieved, after
which (presumably) landuse=reservoir could be safely removed from these
features (and we could finally stop tagging something that is in reality a
type of water as a type of land!)

Renderer support for natural=water is ubiquitous today.  However, there was
no trigger built in to declare that "renderer support has been achieved",
and the double-tagging went on for *eight years*.  By the end of 2018,
tagging of landuse=reservoir had peaked[2], having racked up 450K usages.
The upstart water=reservoir, while still far behind, had been experiencing
a near-exponential growth curve[3], with 180K usages.

2019 was a turning point, and over the last two years, landuse=reservoir
has been on a steady decline, while water=reservoir continued its rapid
growth.  As of today, landuse=reservoir is down to 384K usages, and
water=reservoir has reached 332K usages.  However -- if we exclude nodes
(as there are a large number of presumably imported landuse=reservoir nodes
still hanging out in the map), water=reservoir is slightly ahead - 331K vs
330K.

Now let's turn to what our wiki has to say about this:

"There was considerable confusion whether landuse=reservoir is deprecated,
but it turned out to be not deprecated and landuse=reservoir is used more
widely than "new" way natural=water + water=reservoir."

This is...an interesting lede for a tagging article to say the least!  The
real story behind this awkwardly-worded statement is in the
landuse=reservoir wiki article history, which documents a 9-year-long
low-grade edit war between pro-landuse and pro-water factions.  The comment
about "considerable confusion" was first added in 2014, and has stuck,
despite several attempts over the years to remove it.

This ends our tale.

Is it time to more directly recommend that mappers favor natural=water +
water=reservoir *instead of* rather than *in addition to* landuse=reservoir?


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
[2]
https://taginfo.openstreetmap.org/tags/?key=landuse=reservoir#chronology
[3]
https://taginfo.openstreetmap.org/tags/?key=water=reservoir#chronology
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Brian M. Sperlongano
> Break - I've just found that there actually are a handful of
> club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
> although all are undocumented, so they will be fine. Are we all in
> agreement though, that there should be no reference to "military" against
> Cadet groups (except, of course, for those countries where they *are*
> actually part of the military!)?
>

I would tend to agree - cadet groups are not a military service like an
army or navy.


> One other thing I've realised from this exercise is that the "Military"
> page needs further cleaning-up, but let's get this one out of the way
> first! :-)
>

Excellent - I look forward to your effort and enthusiasm trying to sort
this all out!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - Hazards

2020-12-12 Thread Brian M. Sperlongano
Hello,

Voting is now open for a two-week period on the proposal "Hazards".  I wish
to express my sincere appreciation to the many of you that provided
valuable input during the development of this proposal.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Brian M. Sperlongano
Hello Anders,

I would recommend creating a multipolygon relation (type=multipolygon) with
each of the wetland pieces, and set the name= and appropriate natural= and
wetland= tags on the relation.

On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
>
> Ground/land, air/aviation & maritime/naval all seem pretty well
> interchangeable, space is ready for the future & we should also include
> amphibious & probably Staff / Command / Headquarters for somewhere like
> this place: https://www.openstreetmap.org/relation/89605! Currently
> office=military & also office+government (together with building=public?),
> so would become landuse=military + military=base +
> military_service=joint_forces + function/branch="command" - sound good?
>

Yes, this makes sense in broad strokes, though some thought is needed as to
the exact set of keys and values would be needed to describe these things.


> I don't think we'd need to drill down further into what "type" of unit it
> is (Armour, Artillery, Engineers, MP etc) as that will just introduce a
> whole realm of further confusion, especially if it's being done by
> non-Military mappers, plus which I also still have some security concerns
> about identifying things too accurately‽
>

I think it would be fine to have a way to tag such unit identifiers, though
there can be multiple tenant units within a base, so this is possibly
beyond the scope of base tagging.

I did mention earlier in reply to one of the comments that (previously
> base=) military_service=yes / unknown would be OK if you can't work out
> what's in there, so that should hopefully cover that problem?
>

I do not think that military_service=yes or =unknown should be included in
the proposal.  For the "=unknown" situation, this is accomplished by simply
omitting the tag, and for the "=yes" situation, this is redundant with the
military=* tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-10 Thread Brian M. Sperlongano
In general I have avoided proposing values for these "warning of something
ahead" signs that are at a non-trivial distance from the hazard, as I think
that is a controversial usage, deserving of a separate discussion and/or
proposal.  Since there is already a tag for cattle grids and there is no
usage under hazard=* in taginfo, I would not add a new value for these, and
I note that the traffic_sign key has a general facility for tagging of
standard traffic signs by traffic sign ID.

On Thu, Dec 10, 2020 at 5:00 PM Philip Barnes  wrote:

> On Thu, 2020-12-10 at 07:27 +1000, Graeme Fitzpatrick wrote:
> >
> > Grid: to warn that you are approaching a cattle grid - we already
> > have a tag for grids, do we also need a sign to warn that they're
> > coming up?
>
> Welsh example (I have never seen these in England).
> https://www.mapillary.com/map/im/NiGw-6hqC72o_jkcnxe4UQ
>
>
> > 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
>
>
> Services often cross functions; for example, the US Army operates air
>> fields[2].  Tagging this military_service=army would be accurate, but would
>> not convey that this is an air force base, but not an Air Force base.
>>
>> To get around all of this, we should tag military bases with their
>> function/component rather than solely grouping them by service owner.  For
>> the example[2], the base could conceivably be tagged something like:
>>
>> name=Wheeler Army Airfield
>> landuse=military
>> military=base
>> military_service=army
>> military_function=air
>> operator=United States Army
>>
>> I went with military_function over military_component in this example.
>>  "Component" is the more typical term in military doctrine but "function"
>> is probably better understood by mappers.
>>
>> military_function could include: ground/land, air, maritime, space,
>> law_enforcement, logistics ... etc as needed to cover military organization
>> in different countries.
>>
>> Having both aspects gives mappers in different countries the flexibility
>> to combine service and functional aspects of military bases to create a
>> more accurate tagging.  In addition, from a data consumer, there is a
>> difference between "show me all the air force bases" and "show me all of
>> the military air bases".
>>
>
> May also make things a bit awkward? eg Holsworthy Barracks that I think I
> mentioned earlier
> https://www.openstreetmap.org/way/474902706#map=14/-33.9772/150.9641, is
> an Army base, that has infantry here, artillery ther, armour across that
> side, engineers over the back, commandos down in the bush, together with an
> Army Aviation airfield. What do you call it in one simple word?
>

As a general rule, I think just "army base" is sufficient for a
hypothetical multi-function base occupied by an army service. However, I
note from Wikipedia's discussion of that base:

"Holsworthy Barracks (ICAO: YSHW) is an Australian Army military barracks
[...] is part of the Holsworthy military reserve, which is 22,000-hectare
(54,000-acre) training area and artillery range for the Australian Army,
[...] Holsworthy Military Airport is also located in the reserve."

It calls out "Holsworthy Barracks", "Holsworthy military reserve", and
"Holsworthy Military Airport" as separate places.  Wikipedia seems to think
these are different things, and it seems like we should have tagging that
can describe the differences.  "Holsworthy Military Airport" sounds like a
perfect example of an army base that is performing air component
functions.

>From a data consumer perspective, if I wanted to calculate the number of
hectares that Australia's military dedicates to aviation, it would be
desirable to have a way to do that by querying for both air force bases as
well as bases operated by other services that perform an air warfare or
aviation function.  Or perhaps I wish to generate detailed breakdowns of
how military land is allocated based on both service and function.

Don't take this as criticism, as I fully support the proposed
military_service tag.  But -- I can already envision the mis-tagging that
may occur the first time a mapper encounters a military base that "quacks
like a cow" and goes to the wiki and there isn't an obvious way to tag
these differences beyond the "name" tag.  We have an opportunity here to
make the tagging more fully descriptive to indicate both the service that
operates a base as well as the overall military purpose for bases that are
specialized.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army
>> use "military service"
>>
> sometimes too, and mention the overall "British Armed Services", "Her
>> Majesty's Naval Service", etc.
>>
>
> The same goes for the dialect spoken by that page's author.
>
> However, whilst only the military services in the UK are armed forces,
> police in
> the US are generally armed.  So there would be confusion if we used UK
> terminology here.
>

There is no confusion in the US, the term "armed forces" specifically means
the military, and would never ever be confused with the local police, or
your armed neighbor Billy Bob.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
"Service" is the right term for what is being described (e.g. army, navy,
air force, etc), and is consistent with UK terminology[1].

However, it also assumes that every country's military forces are neatly
grouped into these categories.  The Chinese military is particularly
complex - the Chinese navy and air force are part of the army.  Some
countries have domestic police forces that are part of the military.  Saudi
Arabia, for example, has a separate air force and air defense force
organzied as separate services, the latter being carved out of the army in
the 1980s; tagging both as military_service=air_force would not be quite
right.

Services often cross functions; for example, the US Army operates air
fields[2].  Tagging this military_service=army would be accurate, but would
not convey that this is an air force base, but not an Air Force base.

To get around all of this, we should tag military bases with their
function/component rather than solely grouping them by service owner.  For
the example[2], the base could conceivably be tagged something like:

name=Wheeler Army Airfield
landuse=military
military=base
military_service=army
military_function=air
operator=United States Army

I went with military_function over military_component in this example.
 "Component" is the more typical term in military doctrine but "function"
is probably better understood by mappers.

military_function could include: ground/land, air, maritime, space,
law_enforcement, logistics ... etc as needed to cover military organization
in different countries.

Having both aspects gives mappers in different countries the flexibility to
combine service and functional aspects of military bases to create a more
accurate tagging.  In addition, from a data consumer, there is a difference
between "show me all the air force bases" and "show me all of the military
air bases".


[1]
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/389755/20141208-JDP_0_01_Ed_5_UK_Defence_Doctrine.pdf

[2] https://en.wikipedia.org/wiki/Wheeler_Army_Airfield

On Thu, Dec 10, 2020 at 12:08 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Wikipedia says: "The British Armed Forces, also known as Her Majesty's
> Armed Forces, are the military services responsible for the defence of the
> United Kingdom"... so perhaps the best British term is "military service"?
>
> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army
> use "military service" sometimes too, and mention the overall "British
> Armed Services", "Her Majesty's Naval Service", etc.
>
> Disclaimer: I don't speak the British dialect of English (aka "Her
> Majesty's English?" :-) )
>
> -- Joseph Eisenberg
>
>
> On Thu, Dec 10, 2020 at 3:55 AM Paul Allen  wrote:
> >
> > On Thu, 10 Dec 2020 at 07:28, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >>
> >>
> >> So I suggest military_branch=* or military_service=* for the key.
> >>
> >> Though this is based on my US English understanding of the military
> terminology. Do they call them "military service branches" in British
> English too?
> >
> >
> > "British Armed Forces."  More formally, "Her Majesty's Armed Forces."
>  See
> > https://en.wikipedia.org/wiki/British_Armed_Forces  Not a suitable term
> for use
> > outside of the UK.  "Armed Forces" would be applicable outside the UK but
> > I'm not sure how well it would be understood by, say, the US.  The
> Wikipedia
> > article says that British Armed Forces are the military services in the
> UK,
> > so military_service might be the best option.  OTOH, the sidebar of
> > that article refers to the Navy, Army and Air Force as service branches,
> > so military_branch or military_service_branch would probably work.
> >
> > --
> > Paul
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
>
> We have examples in the UK, even on major roads like the A346 between
> Marlborough and Swindon. I don't think they are tagged.



> with sophisticated routers issuing an alarm on approach might be
> something in the future. These dips are clearly signed.
>

You've just convinced me that this IS something that should be tagged!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
> Here are the ones that I think are worth considering:
>
>- Opening or swing bridge ahead
>
> This is already covered by the approved tag bridge:movable and its various
sub-keys that describe different types of movable bridges.  There were no
existing usages I could find under the hazard key, and the case of a
movable bridge _ahead_ sounds like a router problem.

>
>- Steep hill
>
> Covered by the approved key "incline"

>
>- Trams crossing ahead
>- Level crossing without barrier or gate
>- Frail (or blind or disabled) pedestrians crossing
>
> These are all versions of highway=crossing.  I have deliberately not
defined any crossing hazards as I feel they belong as part of that key,
which has its own hierarchy for different types of hazards.  If
highway=crossing and hazard= should be comingled, I think that is a
separate discussion that should be had.  But, to keep this "clean", I'm
specifically excluding highway=crossing hazards from consideration in this
go.  The only almost-exception is hazard=animal_crossing which is
specifically NOT a highway=crossing.

>
>- Pedestrians in road ahead [no sidewalk]
>
>  Already covered in the proposal with hazard=pedestrians

>
>- Overhead electric cable
>
> Overhead powerline cables are already mapped, it seems that would be
sufficient to know that there is an overhead cable.  There is zero existing
usage that I can find under any tag value for indicating this type of
hazard beyond the geometry of a power line drawn over the road.  As such, I
would exclude this case from this pass as potentially
controversial/duplicative with existing tagging.

>
>- Sharp deviation of route
>
> Already covered in the proposal as a hazard=turn.  I have not added
additional tagging to describe the sharpness of the turn because that fact
is already evident in the way geometry.

>
>- Ice
>
> This is a good suggestion, and I will add hazard=ice which has a handful
of usages.  It is distinctly different from hazard=frost_heave and will
cover the various versions of "bridge freezes before roadway" and so
forth.

>
>- Hidden dip
>
> Maybe.  There is a barely used tag hazard=dip.  Is this a permanent
feature?  I usually see these in relation to road construction.  Note that
speed dips are already covered under the key traffic_calming, so this would
have to describe a permanent, signed dangerous feature that wasn't put
there for traffic control reason.


> One not covered there is the warning that a route is unsuitable for long
> vehicles.  There are a few minor roads near me like that.  Drive a long
> vehicle along them and (at best) you have a long reverse or (at worst)
> you get stuck.
>

Since we have tags to describe the width of roads, and the ways making them
up have a geometry associated with them, it seems that this is something
that routers could simply calculate based on existing tagging.  In order to
avoid tags which might be controversial or redundant with other tagging, I
would not include this -- similar to a "narrow road" hazard which I have
chosen to exclude for the same reason.  I feel that these cases are
potentially more complex and deserve a separate consideration and/or
proposal.



> Also, in the UK, the sign for unexploded ordnance is the same as you
> have for minefields.  That symbol first appeared in UK Defence Standard
> 05-34, Marking of Service Matériel, and was called (bizarrely) "Unexploded
> explosive ordnance" (if it has exploded it would no longer be explosive,
> and if it's explosive then it must be unexploded).  In old money it
> would have been called "unexploded bomb."
>

Thanks!  This is not a sign I normally see on my daily commute :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
> I'd suggest fallen_rock and low_flying_aircraft as tag values based upon
>
the common case but have the proposal mention their secondary application.
>

I actually have low_flying_aircraft in the proposal as a value, though I
just discovered that there is a more common value in use, "air_traffic" (88
usages).  However, I agree with the suggestions that low_flying_aircraft is
the better tag value and will add "air_traffic" to the deprecation list.

I will wait to see if I hear more from others about fallen vs falling
rocks, but I note your comments and Kevin's also.


> I think there may be other hazard warning signs in that document for you to
> consider.
>

Many of the signs on that list are already described by other tags.  For
example, the "yield" sign is covered by highway=give_way.  In general, I
think we have that list pretty well covered, though there may be one or two
more obscure cases.  Are there specific signs you feel are missing from the
hazard key?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
I have found examples of both falling rock[1] and fallen rocks[2] on
signage and it's not clear to me which is the more common.

There are >50 usages of hazard=falling_rocks and only 3 usages of "Fallen
rock" (with incorrect space and capitalization), so I went with what was
most commonly tagged.  I am not opposed to abandoning this minor usage of
falling_rock and replacing it with a new fallen_rock if that's the
consensus.

Are others in favor of dropping falling_rocks for fallen_rocks?

[1]
https://commons.wikimedia.org/wiki/File:Falling_Rock_-_Colorado_Mountains_(44651781425).jpg
[2] https://commons.wikimedia.org/wiki/File:NYS_NYW4-14.svg

On Wed, Dec 9, 2020 at 8:37 AM Paul Allen  wrote:

> On Wed, 9 Dec 2020 at 13:13, Brian M. Sperlongano 
> wrote:
>
> Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall
>>
>
> Kevin Kenny argued (I think convincingly) that the hazard is fallen, not
> falling, rocks.  There is a very slight risk that a rock will fall on your
> vehicle but the greater risk, by far, is that you will drive into a fallen
> rock.
>
> Editors could make both fallen and falling searchable, and identify
> the preset as "falling/fallen rocks," so we might as well make the
> value reflect the really big risk rather than the very small one.
>
> --
> 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] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
Thanks to all who have spilled much ink and provided extensive comment on
this proposal[1] -- the feedback is deeply appreciated as it increases
confidence that the proposal reflects community consensus.  The hazard tag
has attracted an additional 2,000 usages just over the course of this RFC,
and given the attention that this has gotten, I want to make sure we get
this right.

As currently written, this proposal:

- Creates 5 new keys
- Creates 28 new values on these new keys
- Adds 2 new values to existing keys
- Deprecates 19 tag values

Given the scope and extent of the discussion and feedback, I am holding
this RFC open past the 2-week minimum period in order to allow additional
opportunity for community input.  Below the cut line is a summary of the
significant changes made to the proposal and decisions made through the
course of this RFC.

If there is additional input, please provide it!  If anyone feels that they
are a "no" vote for this proposal, I especially want to hear from you, as a
vote should be confirmation of community consensus achieved through
discussion.


 Summary of Changes since the start of RFC 

* Added:

hazard=bump (signed natural bumps, not traffic_calming=*)
hazard=frost_heave
hazard=loose_gravel
hazard=low_flying_aircraft
hazard=horse_riders (equestrians in the roadway, not highway=crossing)
hazard=pedestrians (pedestrians in the roadway, not highway=crossing)
hazard=queues_likely
hazard=slippery
hazard=unexploded_ordnance

* Changed:

Add hazard=cyclists; deprecate hazard=bicycle, bicycles
Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall

* Removed from proposal (but not deprecated):

hazard=yes
hazard=school_crossing

* Clarified that mappers should not tag subjective hazard features which
cannot be confirmed or denied even when visiting the location in person.

* Declined to add a "narrow road" hazard, as this is controversial based on
a past proposal[2] to eliminate the width=narrow tag, and is deserving of
its own proposal if a narrow road hazard is desired.


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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-07 Thread Brian M. Sperlongano
I fixed that for you, it should just be status=proposed, and the template
does the rest of the magic!

On Mon, Dec 7, 2020 at 7:26 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Tue, 8 Dec 2020 at 10:19, Graeme Fitzpatrick 
> wrote:
>
>>
>> I have just posted a new proposal re Military Bases:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Military_bases
>>
>
> But when I look at it, it's saying it's in Inactive status so not sure
> what I've done there?
>
> Suggestions please!
>
> 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] RFC - Hazards - Pedestrian hazard

2020-12-06 Thread Brian M. Sperlongano
Ah yes, I temporarily forgot that we have other street view sites!  Thank
you for that subtle nudge.

I pulled up this [1] example at random, which is tagged in the map with
hazard=cyclists (on a stretch of way).  I assume this means (in this
specific case) "cyclists enter the roadway 100m ahead".  Next randomly
selected example [2] in Poland is a spot where a signed bike lane ends and
cyclists begin sharing the road with cars.

Now admittedly, 239 usages is a tiny amount of existing usage, but the way
I've described it in the proposal seems consistent with how mappers have
actually used this tag so far (bike in road hazards).  I also recently
changed over the example image in the proposal to a MUTCD-style "share the
road with bicycles" sign, which is a less ambiguous descriptor than the
red-triangle-with-a-bicycle variants.

I tend to favor formalizing existing usage rather than inventing new tags,
as well as more concise tags instead of verbose ones.  If there is a
consensus that hazard=cyclists will be misused if approved and documented,
we can change it to something invented like hazard=cyclists_in_road.  If
there isn't a consensus on what to do with this value, I would just drop
this particular value from the proposal as a future problem in order to
approve the set of tags that we all agree on!

[1]
https://www.mapillary.com/app/?lat=49.316661=8.4070676=18=photo=BoYvMnLxXMr0KaUmIDPxhg
[2]
https://www.mapillary.com/app/?lat=53.50421582735714=14.477556379223921=17=photo=aaBuvm_A9utc1PYDRyGyXw=0.5085941428184124=0.5962547075134255=0

On Sun, Dec 6, 2020 at 6:45 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 7. Dec 2020, at 00:17, Brian M. Sperlongano 
> wrote:
> >
> > The largest existing use of hazard=cyclists is in Germany.  There is no
> Google StreetView in Germany
>
>
> of course there is
>
>
> > , but from the small number examples [1] I looked at, it seems like this
> tag is being used for "cyclists in the road" hazards and not "cyclist
> crossings"
>
>
> I have looked it up, and until 2013 the sign was called “crossing
> cyclists” while it is now called “cyclists”. It is typically set up before
> bicycle crossings or before a separate  cycleway merges with the road.
>
> 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 - Hazards - Pedestrian hazard

2020-12-06 Thread Brian M. Sperlongano
The largest existing use of hazard=cyclists is in Germany.  There is no
Google StreetView in Germany, but from the small number examples [1] I
looked at, it seems like this tag is being used for "cyclists in the road"
hazards and not "cyclist crossings".  There were only 10 usages of the tag
(out of a few hundred) that were combined with highway=crossing.  So it
does seem that the way this is being used in actual practice is
hazard=cyclists for "cyclist in the road" hazards and highway=crossing +
bicycle=yes for cyclist crossings.  As long as the use of this tag is
properly documented (which I will strive earnestly to ensure), and with
links to the cyclist crossing wiki page, this distinction seems sufficient.

Over 160,000 cyclist crossings have been tagged (highway=crossing +
bicycle=*), and it is well-established tagging, but this is clearly a
different case!  In addition to being useful to motorists ("watch out for
bicycles!"), conversely it is also useful to cyclists ("this is a more
dangerous than usual place to ride!").

[1] hazard=cyclists: https://overpass-turbo.eu/s/10Vc

On Sun, Dec 6, 2020 at 5:41 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Mon, 7 Dec 2020 at 04:14, Martin Koppenhoefer 
> wrote:
>
>> I cannot remember having seen such signage for places where cyclists are
>> using the road.
>>
>
> Doing it to you again! :-)
>
>
> https://www.google.com.au/maps/@-28.128994,153.4847037,3a,75y,327.54h,51.22t/data=!3m6!1e1!3m4!1sSXoyhtDrthUQ45j0cSdQ4g!2e0!7i13312!8i6656?hl=en
>
> Since these images were taken, signage has also been put up warning of
> cyclists on road, in addition to the roadway markings.
>
> 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


[Tagging] RFC - Hazards - Pedestrian hazard

2020-12-06 Thread 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

2020-12-06 Thread 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

2020-12-06 Thread 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

2020-12-05 Thread 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?)

2020-12-04 Thread 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

2020-12-04 Thread 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

2020-12-04 Thread 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

2020-12-03 Thread 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

2020-12-03 Thread 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?)

2020-12-03 Thread 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

2020-12-03 Thread 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

2020-12-02 Thread 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

2020-12-01 Thread 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

2020-11-30 Thread 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)

2020-11-27 Thread 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

2020-11-27 Thread 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

2020-11-27 Thread 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

2020-11-26 Thread 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)

2020-11-26 Thread 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

2020-11-26 Thread 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)

2020-11-26 Thread 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

2020-11-26 Thread 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)

2020-11-26 Thread 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)

2020-11-26 Thread 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

2020-11-26 Thread 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

2020-11-26 Thread 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

2020-11-25 Thread 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

2020-11-25 Thread 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

2020-11-24 Thread 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

2020-11-23 Thread 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

2020-11-22 Thread 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

2020-11-22 Thread 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

2020-11-22 Thread 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

2020-11-20 Thread 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

2020-11-20 Thread 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

2020-11-18 Thread 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

2020-11-17 Thread 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

2020-11-16 Thread 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?

2020-11-12 Thread 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?

2020-11-11 Thread 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?

2020-11-11 Thread 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?

2020-11-11 Thread 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?

2020-11-11 Thread 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?

2020-11-11 Thread 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?

2020-11-09 Thread 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

2020-11-09 Thread 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


  1   2   >