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

[Kevin Kenny]

On Thu, Dec 24, 2020 at 10:10 AM Paul Allen  wrote:

> Yes, we already have fee and access which can cope with these things.
> What we didn't have was an understanding in the US that such tags
> were even applicable or that anyone might wish to map fishing
> features on rivers, especially pools that don't "bulge" enough to
> be obvious from aerial imagery but which are obvious from
> detailed measurement (using, say, a rod, line and float) on
> the ground.  The legislation affects the degree to which
> such details become public knowledge.
>

Yeah... but...

Don't think we don't understand that we can apply the tags; we just don't
often need them.

 The New York State-owned lands have pretty uniform rules for hunting and
fishing; for these, I follow 'don't tag the local legislation'.

The New York City ones vary all over the place, and the import of those
tags them specifically. For instance, in the case of
https://www.openstreetmap.org/way/481482895 there is,

`foot=hunting;fishing' - public foot access allowed only for the stated
purposes.
'hunting=permit fishing=permit trapping=no' - a permit is required for
hunting or fishing; the setting of traps is prohibited.
`NYSDEC:wildlife_management_unit=3H` - the specific state Wildlife
Management Unit that hunters must consult.
`website=*` - link to lots more information, including, of course, how a
permit may be obtained.

https://www.openstreetmap.org/relation/6304851 has similar tagging, but
declares that you don't need a permit to fish there. (Or to enter on foot
for other reasons, but I find it hard to imagine why you'd want to go
plooshing about in that marsh if it weren't to fish.)

We do have facilities devoted to fishing access, such as
https://www.openstreetmap.org/relation/6396542 -- which doesn't render
because there's no good "tag for the renderer" approach. (That one's not
got access constraints shown because it's free to all comers; of course,
anglers over 16 need a state fishing license.)

Essentially all of our Wildlife Management Areas are devoted to the
preservation of habitat for game fish and for wild game for hunters. (
https://www.openstreetmap.org/relation/6367671 is an example. There are a
great many of these.)  Once again, these are free to all comers. These are
supported financially by the revenue from the sale of hunting and fishing
licenses and by a tax on arms and ammunition.

There are some of our State Forests, for example
https://www.openstreetmap.org/relation/7229593, that I can't imagine why
you'd trouble to visit if it weren't to fish. (Note the adjacent presence
of https://www.openstreetmap.org/way/429194108.)

I can easily see how 'access=private', 'access=fee' and so on would apply
to fishing spots. I just haven't had occasion to map any.

You're right that I haven't mapped a lot of specific fishing spots, but
that's partly because they're so numerous.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[stevea]

Long, prickly post ahead.

On Dec 24, 2020, at 7:35 AM, Anders Torger  wrote:
> By not rendering valleys and peninsula and possibly other tags often used on 
> "non-verifiable geometry" it's a signal to mappers that those are not 
> considered important or desirable. We could say that we shouldn't care about 
> what OSM-Carto does, and for advanced users that have their own renderers 
> that makes some sense, although it risks further increase fragmentation in 
> mapping methods.

False.  This is pure speculation.  OSM asks that Contributors enter 
on-the-ground-verifiable data into the map.  Period.  This is what I mean by 
"map well."  If you get a rendering that pleases you, great!  If you don't, "at 
least" the data (accurate, verifiable — to the extent they can be verified — I 
agree "verifiable" can be slippery at times) are "in OSM."  I put "at least" in 
quotes not to diminish its importance, but rather to emphasize that THIS IS THE 
INTENT!  There is no "signaling" by renderer authors "tag like this so you see 
in renderings what is considered important or desirable to map."  Big "no," 
right there.  Do renderer authors render data which ARE entered into OSM?  
Sure.  Period.  Full stop.

Anders, please:  DON'T TAG TO ACHIEVE PARTICULAR RENDERINGS!  I applaud good 
dialog here about "fuzzy" and natural-naming, as those are interesting, even 
necessary discussions.  But these value-judgements you make like above are 
specious and even pose danger to OSM should they gain traction.  My passion 
against this shines brightly here, as I don't want to see that:  it drives the 
desire for particular renderings to guide what we map.  No!  That's not what 
OSM is!  Entry of good DATA is the goal, RENDERINGS are a nice-to-have, 
particular expression of them.  OK?

> But how many of us mappers have our own renderers? A few on this list have it 
> of course, but broadly speaking it's probably less than 1% of all mappers. 
> And if you don't have your own pipeline or is simply interested in the free 
> end products that anyone can access for free all over the world, one have to 
> take into account what OSM-Carto does.

Continuing to complain that OSM doesn't render as you like (or that few have or 
can or do make renderers, or that making a renderer is challenging...) further 
illustrates the distance of your understanding what of OSM is.  OSM absorbs 
good geographic contributions of volunteers (like you, me and readers of this 
list).  This list absorbs questions about tagging and improving strategy for 
better tagging and possibly results in improving or making tools or better 
process for achieving that.  It strives to offer answers, better strategies and 
guidance.  Getting hung up on how our tagged data render seems it needs a 
different list like OpenStreetMap-Carto, where "renderer discussion" takes 
place and where people might have far more patience with you than I do (I've 
extended a great deal here with you).  You don't seem to discuss tagging (the 
point of this list), you seem to repeatedly, exhaustingly, 
frustratingly-to-many-here complain about rendering.  I ask you explicitly:  
please stop.

> Even if the mappers community end up with a consensus to map in one way (or 
> at least a consensus that it is an okay alternative), and those in charge of 
> OSM-Carto choose not to render it, then it's really not working out... 
> because OSM-Carto is the only renderer that can represent "the community".

You do realize that OSM is about the data that we put into a database, right?  
I distinctly tire of repeatedly making this point to you.  Repeated complaining 
about particular renderings is truly unwelcome traffic here.  If you wish to 
discuss better TAGGING strategy IN THE CONTEXT OF a renderer, one where you do 
not seem to act like a child who wants to be given a cookie of your particular 
rendering desire, that's one thing.  But that's not what you continue to do 
here.  I believe I have been kind and patient with you, but patience is finite: 
 I repeat myself that you seem to entirely miss the point of what this list 
(and even OSM as a project) really is.  Better the data, better the tagging, 
better the strategies / tools / documentation, yes.  But repeatedly complain?  
You get me who says "stop that" and others who support me.  As you explicitly 
state "it's really not working out" (for YOU, not OSM):  OK, see you later and 
thanks for coming.  I don't like being harsh, but we're going around and 
around, yet you persist.  Stop.  You are being more than Kevin kindly put it, 
"a bit confrontational," you go far beyond that.

> I know many think that we should not care about rendering at all, and the way 
> to see our own work is to download it in JOSM and enjoy the geodata objects 
> we've made, as OSM is supposed to be a geodatabase, not a geoservice 
> provider. I don't think that is how the typical mapper see it though.

OSM cares about renderings:  we offer four on our map page as a

Re: [Tagging] Quarry lakes

[Joseph Eisenberg]

I would like to keep water=lake as being a natural or semi-natural lake.

Since most abandoned quarries are obviously artificial, it would be better
to use a different tag.

"Water-filled quarries can be very deep, often 50 ft (15 m) or more, and
surprisingly cold, so swimming in quarry lakes is generally not
recommended. Unexpectedly cold water can cause a swimmer's muscles to
suddenly weaken; it can also cause shock and even hypothermia.[2] Though
quarry water is often very clear, submerged quarry stones and abandoned
equipment make diving into these quarries extremely dangerous. Several
people drown in quarries each year."

See examples:
https://en.wikipedia.org/wiki/Quarry#/media/File:Stone_Quarry_Kerala.JPG
https://en.wikipedia.org/wiki/Quarry#/media/File:Stone_quarry_adelaide.JPG
https://en.wikipedia.org/wiki/Quarry#/media/File:Rummu_karjäär1.jpg

The first two are obviously old quarries and I would want to use a
different tag, not water=lake.

-- Joseph Eisenberg


On Thu, Dec 24, 2020 at 9:24 AM Brian M. Sperlongano 
wrote:
>
> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Quarry lakes

[Paul Allen]

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

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

If they should, then you have to consider that some of them may be ponds.

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

It can be hard to know if a pond/lake is the result of quarrying or not.  it
depends upon knowing the history of an area.  For the distant past such
information may not be available.  So subtagging with lake=quarry
and pond=quarry may be the way to go - it can be added if known
or if such information arises later.  The Norfolk Broads were long
regarded as natural, until it was proven in the 1960s that they
were excavated in the Middle Ages and later flooded by rising
sea levels.

The question arises as to whether or not peat workings qualify as
quarries.  The Norfolk Broads were peat workings that later
flooded.  https://en.wikipedia.org/wiki/The_Broads

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

[Tagging] Quarry lakes

[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

[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] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[Peter Elderson]

Option 1
addr:range=* specifies the increment

addr:range=even
addr:housenumber=2..250

if .. is used, a hyphen combined with a range can be handled.

addr:range=odd
addr:housenumber=200-01..200-91

In these examples, a default of 2 would simplify things: .. infers a range,
increment is default 2 and - is never a range indicator.

Error to be expected: people just copying the housenumber plate may use
2-250.
When using the explicit addr:range tag, the format error may be detected
because .. is missing.

Peter Elderson


Op do 24 dec. 2020 om 15:12 schreef Paul Allen :

> On Thu, 24 Dec 2020 at 10:14, Martin Koppenhoefer 
> wrote:
>
>> maybe we should add an expression marker, like {10..20} to make it more
>> explicit and avoid confusion with typos?
>>
>
> In programming, you also have the ability to define the increment,
> which defaults to 1 if left unspecified.  That way you can distinguish
> between 10, 11, 12, 13, 14, 15, 16 and 10, 12, 14, 16 (or even
> 10, 13, 16).  You could argue that for addresses the increment
> ought to default to 2, since that is most commonly encountered.
>
> --
> 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] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Thu, 24 Dec 2020 at 05:40, Andrew Harvey 
wrote:

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

Until water=stream_pool came along, these would have been mapped
as water=pond, or even left as natural=water without defining the
type of water.  I expect many still are mapped that way, even
today.

Do we need to differentiate between stream pools and plunge pools
given that so many of both are already mapped as ponds?  I can
see arguments both ways and don't (yet) have strong feelings
either way.

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

[Martin Koppenhoefer]

Am Do., 24. Dez. 2020 um 00:22 Uhr schrieb Peter Elderson <
pelder...@gmail.com>:

> 10..20, meaning 10 up to and including 20
>



I don't know if it is just you, but there are already some few examples for
this in the db:
17
*wa**s:**ra**il**wa**y:**20**12**..**20**14*

5
*wa**s:**ra**il**wa**y:**20**01**..**20**12*

1
*bu**il**di**ng**:~**19**63**..**19**64*

1
*hi**st**or**ic**:C**13**..**.1**88*1

1
*na**me**:1**70**0.**.1**76**0-**17**80*

1
*na**me**:1**97**0-**19**90**..**20**05*

0
*bu**il**di**ng**:l**ev**el**:1**,2**,3**..*.




Btw. this one seems to be triggering a bug in taginfo:
https://taginfo.openstreetmap.org/keys/?key=building%3Alevel%3A1%2C2%2C3...

I like the .. syntax, intuitive if you know sequence expressions from bash.

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