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

[stevea]

We have a spot on the ocean shore, right at (below, at sea level) the entrance 
to a state park, in an urban area:  it's known locally as "the toilet bowl" and 
it's node/3370641047.

It's tagged hazard=yes (best I could do at the time, I suppose; I tagged it in 
2015) and "dangerous area, no swimming."

We can do better (now or soon).

> On Dec 23, 2020, at 9:40 PM, Graeme Fitzpatrick  wrote:
> On Thu, 24 Dec 2020 at 15:14, Brian M. Sperlongano  
> wrote:
> "I'd like to swim in a small pool with a waterfall".
> 
> Good spot for one of your hazard tags!
> 
> We have Natural Bridge nearby 
> https://www.queensland.com/au/en/things-to-do/attractions/p-56b25f942880253d74c479de-natural-bridge-springbrook-national-park.html,
>  which is a hole cut in the roof of a cave by millions of year of rushing 
> water, making a waterfall.
> 
> Unfortunately, over the years, despite warnings not to swim in there, quite a 
> few people have drowned, as the force of the falling water pulls them under & 
> back, they can't see & so run out of air :-(


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

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

[Graeme Fitzpatrick]

On Thu, 24 Dec 2020 at 15:14, Brian M. Sperlongano 
wrote:

> "I'd like to swim in a small pool with a waterfall".
>

Good spot for one of your hazard tags!

We have Natural Bridge nearby
https://www.queensland.com/au/en/things-to-do/attractions/p-56b25f942880253d74c479de-natural-bridge-springbrook-national-park.html,
which is a hole cut in the roof of a cave by millions of year of rushing
water, making a waterfall.

Unfortunately, over the years, despite warnings not to swim in there, quite
a few people have drowned, as the force of the falling water pulls them
under & back, they can't see & so run out of air :-(

Thanks

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

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

[Andrew Harvey]

I'm giving away all my favourite spots here but both of these the stream is
mapped a a way, and has the pool under the waterfall mapped as an area, so
you can determine pools under a waterfall based on the natural=water area
with one of the nodes being a waterway=waterfall node.

https://www.openstreetmap.org/way/531128566
https://www.openstreetmap.org/way/32173325

If we want a separate tag for this that's fine, but currently people use
the water=stream_pool in OSM to tag these.

On Thu, 24 Dec 2020 at 16:31, Brian M. Sperlongano 
wrote:

> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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

[Andrew Harvey]

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

Re: [Tagging] Cartpath RFC

[stevea via Tagging]

Thank you immensely for doing your (our) homework, Minh!
SteveA

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

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

[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

[stevea]

On North America's west coast and in "the West" (ern states of the USA), I've 
heard "hole" used for both fishing spots and swimming spots in creeks, streams 
and rivers (and "pools," what I often see called a "thickening" of the river, 
such as a calmer not-quite-eddy off to one side that might go a bit deeper than 
usual, sometimes with river-cliff diving!).

I've also seen "official" naming conventions on waterways like "Branciforte 
Creek Reach 2" where an urban river/creek becomes a concrete canal (named 
"Reach 1"), becoming channelized to flow into a more major waterway.  Los 
Angeles has a lot of these (concrete, channelized rivers) in its vast 
conurbation, very useful for flood control.

Yes, if I want to angle in a creek or river, I'll do it on public land, where 
there are plenty of opportunities (sometimes requiring a permit from state Fish 
& Game department, sometimes not).  Somebody wants to charge me money for a 
permit to fish on private land, I'll pass, thanks.  I realize that in some 
parts of the world, though, "that's how angling happens."

Two whole cents,
SteveA
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Wed, Dec 23, 2020 at 1:08 PM Paul Allen  wrote:

> On Wed, 23 Dec 2020 at 17:28, Kevin Kenny  wrote:
>
>> On Wed, Dec 23, 2020 at 7:17 AM Paul Allen  wrote:
>>
>> British anglers must be different from American ones. Most fishermen that
>> I know don't want their favorite fishing holes to be mapped! They'll tell
>> you where they are if you're really nice and ply them with a pint or three,
>> but will then swear you to secrecy!
>>
>
> The good places for certain types of fish require permits.  Angling
> associations make their money by selling permits to waters they control.
>
> Teifi Trout Association maps: https://teifitrout.co.uk/tta-waters/
> and permits https://teifitrout.co.uk/tta-shop/fishing-permits/
>

Ah.  Around here, the best freshwater fishing is mostly on public land.
Since the anglers can't sell permits, they keep the choice places to
themselves. (A handful also work as wilderness guides. :) )

Around here the fishermen have names for some of the pools too, such as
Bear Hole https://www.flickr.com/photos/ke9tv/14799397098, Devil's Kitchen
https://www.flickr.com/photos/ke9tv/7082920415, Rat Hole
https://youtu.be/2rCKgEum2FQ?t=39 and Fawn's Leap
https://youtu.be/2rCKgEum2FQ?t=77  (Oh, yeah, did I mention that the cliff
divers have names for them, too?)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Graeme Fitzpatrick]

On Thu, 24 Dec 2020 at 09:00, Kevin Kenny  wrote:

> On Wed, Dec 23, 2020 at 1:25 PM Paul Allen  wrote:
>
> I've had one German solemnly assure me that anything labeled a 'creek' in
> English is a minor watercourse, and challenge why I was mapping a riverbank
> for Schoharie Creek.
>

Thanks, Kevin, entertaining as always! :-)

I've also seen a couple of comments that "Creeks are small", & always have
a wonder about them?

Here are two of our local "Creeks"

https://goo.gl/maps/47KR97bhpjpSBpDv5

&

https://goo.gl/maps/fru9t4Vg7NynNPtv8

Definitely wouldn't try jumping across either of them, although a lot of
people have fun jumping into them, frequently off the bridges!

Thanks

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

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

[ipswichmapper--- via Tagging]

It says in the proposal the the vertical bar is an alternative. You can still 
use hypens, however vertical bar is more explicit. With a addr:range however 
hypens should be enough.
-- 


23 Dec 2020, 22:59 by tagging@openstreetmap.org:

> As I understand, it would mean that 40-48 range would need to be
> recorded as addr:housenumber=40|48 rather than more natural
> addr:housenumber=40-48
>
> Dec 23, 2020, 21:06 by t...@fitchfamily.org:
>
>> Vertical bar character is already in use for turn lanes[1]. Not a big deal 
>> to type it, at least on a US keyboard. Certainly easier to type it than to 
>> enter two key/value pairs for the same information. Seems like a poor reason 
>> to avoid it since it is one of the few characters that seems unlikely to 
>> exist on an address in the wild.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications_per_lane
>>
>>> On Dec 23, 2020, at 11:46 AM, Mateusz Konieczny via Tagging 
>>>  wrote:
>>>
>>> I am not so happy about it.
>>>
>>> Typing that would be extremely unnatural.
>>>
>>> Maybe better have additional add:range:from= addr:range:to=
>>> for ranges?
>>>
>>> Dec 23, 2020, 20:10 by tagging@openstreetmap.org:
>>> Im gping to update the proposal tonight, when I have time.
>>>
>>> I currently think suggesting a new character, | , used to explicitally 
>>> specify ranges. The advantage of this is that ypu can interpolation 
>>> hypenated addresses, e.g. :
>>>
>>> addr:housenumber="19-100|19-200"
>>>
>>> Would imply : 19-100, 19-102, 19-104, 19-106 etc.
>>>
>>> Renderers can use "19-100 to 19-200"
>>>
>>> Hypens would be accepted, but this is clearer.
>>>
>>> The problem is that now you will have to get every single renderer and 
>>> geocoder to understand this (which will take months ,even years).
>>>
>>>
>>>
>>> --
>>> 23 Dec 2020, 16:29 by lon...@denofr.de:
>>> On Mon, Dec 21, 2020 at 07:05:10PM +0100, ipswichmapper--- via Tagging 
>>> wrote:
>>> 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.
>>>
>>> It's better. It would resolve half the issue. addr:housenumber would still
>>> have a double interpretation but it's the smaller of the two issues.
>>>
>>> addr:housenumber:range would capture a bit better what the tag means
>>> but it starts to get uncomfortably long.
>>> "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.
>>>
>>> That would only make sense, when you define addr:range as being
>>> applicable to housenumbers with hyphens only. However your definition
>>> above was imo more sensible:
>>> "applies to nodes and closed ways that have addr:housenumber"
>>>
>>> If you look at all nodes and ways with addr:housenumbers 99.999% have
>>> a addr:range=no. So that makes more sense as a default then.
>>> 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.
>>>
>>> My guess would be that the main reason that people started using the
>>> hyphen notation with addr:housenumber is that they wanted something
>>> human readable on the map. And addr:housenumber was already rendered.
>>>
>>> With that in mind, I think there is a reasonable way forward even for
>>> a addr:range tag as you suggest and also for a separate
>>> addr:housenumber_range=1-15 like I would prefer. For both it is relatively
>>> easy to support a new agreed on proposal while still using the old
>>> behaviour where the new one is not yet implemented. So the transition would
>>> be:
>>>
>>> 1. Agree on proposal.
>>> 2. Get openstreetmap-carto, Nominatim and others to support new proposal.
>>> 3. Tell mappers about proposal.
>>> 4. Wait a few years.
>>> 5. Drop support for addr:housenumbers with interpolations.
>>>
>>> Sarah
>>>
>>> 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:
>>> >
>>> >> 

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

[Andy Townsend]

Hi all,

I'll reply to this as me since the DWG's ticketing system was cc:ed on 
this mail and we can't reply from there because the messages will bounce.


On 21/12/2020 15:42, Brian M. Sperlongano wrote:



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.



(snipped discussion)


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 



Has the DWG ever taking swift and immediate action to enforce a 
particular tagging scheme?  We've certainly taken swift and immediate 
action to reverse the deletion of countries that someone didn't like, 
and to remove genitalia from the front lawn of the White House, but I 
can't think of an occasion when we've enforced a particular tagging 
scheme in that way.


The nearest recent example that I can remember was us having to "pick a 
side" in the Chesapeake Bay debacle 
(https://lists.openstreetmap.org/pipermail/tagging/2020-November/056426.html 
), but that was essentially just a revert to the "status quo ante" so 
that normal coastline processing could continue.





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.



People add new stuff to OSM all the time, and invent new tagging 
schemes.  As long as it's possible to retag later when something better 
comes along, that's fine.  People who try and use the data may well say 
"I can't possibly use data tagged like that, I'll just ignore it", and 
that's fine too.  As long as proponents of the new scheme don't try and 
misrepresent it (e.g. have the wiki say that it is really popular when 
it isn't), or mechanically edit existing data to match it, or misuse an 
existing key in some way, I can't see why anyone would want to purge a 
new key from the database.


Best Regards,

Andy (from the DWG)

PS (not with a DWG hat on): Just to pick up on one other thing- as some 
people may know, the last time "tagging list mail volume" was mentioned 
I wrote https://www.openstreetmap.org/user/SomeoneElse/diary/393175 .  
By my reckoning, Anders is only in 5th place this month on the tagging 
list in terms of number of posts, and is some considerable way off the 
all-time record (someone managed 132 personal posts one month earlier 
this year).  How we try and map fuzzy stuff is worth discussing, even if 
with a rendering hat on I'm still in the "I can't possibly use data 
tagged like that, I'll just ignore it" corner on that one.  Mind you, I 
didn't think that anyone would do anything useful with site relations, 
and openinframap does.




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

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

[ipswichmapper--- via Tagging]

Hello everyone,

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:range

Here is the updated page. There may be some mistakes / it may not be completely 
done yet, but it gives a rough overview of addr:range.

Thanks,
IpswichMapper-- 
 Sent with Tutanota, the secure & ad-free mailbox: 
 https://tutanota.com


23 Dec 2020, 21:04 by tagging@openstreetmap.org:

> Thats what the addr:range tag is for
>
> I have explained this in a previous message on this mailing list. I'll update 
> the wiki proposal page so that it much clearer how addr:range works compared 
> to trying to explain in on a mailing list.
>
> Thanks, 
> IpseichMapper 
> -- 
>
>
>
> 23 Dec 2020, 20:38 by dieterdre...@gmail.com:
>
>>
>>
>> sent from a phone
>>
>>> On 23. Dec 2020, at 20:12, ipswichmapper--- via Tagging 
>>>  wrote:
>>>
>>> addr:housenumber="19-100|19-200"
>>>
>>> Would imply : 19-100, 19-102, 19-104, 19-106 etc.
>>>
>>
>>
>> it could also imply 19-100, 19-101, 19-102...
>> and you also can’t know which numbers are included and which do not exist 
>>
>> Cheers Martin
>>
>
>

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

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

[stevea]

On Dec 23, 2020, at 9:23 AM, Martin Søndergaard  
wrote:
> While some might not agree with the tone of Anders, I do think his 
> "enthusiasm" has resulted in the most interesting discussion I have seen on 
> this list yet. And I want to give a few of my thoughts as well.

Bullseye.

> On Tue, 22 Dec 2020 at 09:43, stevea  wrote:
> “Names in nature” is an interesting, complex, challenging, yes, even 
> strategic topic.  I think we can get closer to “better,” here on this list, 
> with good, respectful, effective dialog.  I look forward to that.
>  
> In my opinion this problem is in no way limited to "names in nature". 
> Practically all place=* features (except the "Administratively declared 
> places" category), such as City, Town, Village, Hamlet, etc. are "fuzzy" 
> features, but no one seems to talk about them as such.

Excellent:  I am glad somebody took my relatively limited (we have to start 
dialog somewhere...) point and expanded upon what needs expansion.  I did not 
mean to "limit" what we discuss when I said what I said, as these are expansive 
topics and frequently not easy to discuss.

Thank you, Martin, for expounding upon many tangents of this thread and 
bringing them together in a way that lets us understand that "naming" and 
"fuzzy" and "nature" are not as precise as we might wish them to be.  We've got 
a real, live thread here, vibrant with great dialog!

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

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

[Snusmumriken]

On Wed, 2020-12-23 at 09:55 -0800, Joseph Eisenberg wrote:
> 3) Archipelagos are partially cultural concepts but most often
> represent island groups which are close together and share a
> geological origin, as well as a human-created name. In OpenStreetMap
> they are mapped as multipolygon relations which contain each island's
> coastline, so this is quite precise and verifiable by visiting the
> area in person and asking the local people the name of the island
> group or chain.

I believe that your statement is verifiably false. Take for example
Stockholm archipelago, it is estimated to contain somewhere around
24.000 islands and has no official boundaries. You could well travel
around the edges and ask the local people whether or not a specific
island belongs to the Stockholm archipelago or not and get a different
answer depending on who you ask. 


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

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

[Paul Allen]

On Wed, 23 Dec 2020 at 18:04, Brian M. Sperlongano 
wrote:

>
> It seems like the convention for rivers is that the river's continuity
> (and name) are carried with the waterway=river ways and not the area
> polygons that cover the width of the river (regardless of whether you use
> the water=river or waterway=riverbank scheme).
>

So it appears to me.

  I also note that the distinction (effectively) between stream/river (the
> only variants that are in serious use) is that a stream is small enough
> that it's modeled by a way, while a river is large enough to require
> drawing a polygon.
>

Erm, nope.  The distinction is whether or not you can jump across it.
However,
wider rivers may benefit from a polygon.  But if you're in a hurry, or can't
be bothered, don't use a polygon.  Whenever I have masochistic urges
I extend the polygon on Afon Teifi further upstream.  This is as far as I've
gone from the estuary, and you can see that the rendering without the
polygon doesn't do it justice:
https://www.openstreetmap.org/?mlat=52.05829=-4.58272#map=17/52.05829/-4.58272
Follow the river a little way east from that point and you'll see a stream
join
the unpolygonned river.  Follow the river a little way north from that point
and you'll see the stream Nant Eifed join the polygonned river.


> I will make an assumption that there exists a class of these pools that
> are large enough that we would want to be able to map them as an area (and
> we wouldn't call them a pond),
>

Not so much wouldn't call them a pond as shouldn't call them a pond (unless
we declare pools to be honorary ponds for OSM purposes).

and there are also some that are small enough that mapping them as a node
> or linear way is fine also.
>

A node, maybe.  I'm not sure a linear way makes sense.


> 5. Be the same tagging for both rivers and streams
>

That could be hard.  It doesn't make sense to put a polygon on a
stream, they're not wide enough.

>
> I think it's fine if a river does not have continuity of water=river or
> waterway=riverbank polygons, as long as the waterway=river is properly
> contiguous.  I.e. I think it would be fine to have a sequence of river
> polygons with a stream pool polygon in between.
>

It would be rare (but not impossible) for the whole width of a river to be a
pool.  Mostly it's one side of the river where the flow rate slows.  But
since the
polygons overlay the water=river it should all work.  Maybe a carto problem
with name overlaps/priority, but that's probably soluble.

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

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

[Sarah Hoffmann]

On Mon, Dec 21, 2020 at 07:05:10PM +0100, ipswichmapper--- via Tagging wrote:
> 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.

It's better. It would resolve half the issue. addr:housenumber would still
have a double interpretation but it's the smaller of the two issues.

addr:housenumber:range would capture a bit better what the tag means
but it starts to get uncomfortably long.

> "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.

That would only make sense, when you define addr:range as being
applicable to housenumbers with hyphens only. However your definition
above was imo more sensible:
"applies to nodes and closed ways that have addr:housenumber"

If you look at all nodes and ways with addr:housenumbers 99.999% have
a addr:range=no. So that makes more sense as a default then.

> 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.

My guess would be that the main reason that people started using the
hyphen notation with addr:housenumber is that they wanted something
human readable on the map. And addr:housenumber was already rendered.

With that in mind, I think there is a reasonable way forward even for
a addr:range tag as you suggest and also for a separate
addr:housenumber_range=1-15 like I would prefer. For both it is relatively
easy to support a new agreed on proposal while still using the old
behaviour where the new one is not yet implemented. So the transition would
be:

1. Agree on proposal.
2. Get openstreetmap-carto, Nominatim and others to support new proposal.
3. Tell mappers about proposal.
4. Wait a few years.
5. Drop support for addr:housenumbers with interpolations.

Sarah

> 
> 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

Re: [Tagging] Cartpath RFC

[Paul Allen]

On Wed, 23 Dec 2020 at 08:40, Peter Elderson  wrote:

> It's not about an example, it's about using a general term for a specific
> type.
>

When I saw "cartpath" in the subject, my first thought was NOT golf carts.
My first thought was of a two-wheeled vehicle pulled by one or two
horses.  Around here there are competitions for those types of cart,
run on dedicated gallops.  For all I know, somewhere there are paths
dedicated to them.

"cartpath" is too general.  And should be hyphenated or underscored,
anyway.

And maybe it would be better handled as an access value.

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