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

[Anders Torger]

Thanks for the feedback Frederik, appreciate it.

I don't think it's entirely fair though. I certainly don't write every 
day. Indeed I can write a lot as I'm quick on the keyboard, and I should 
probably try to be more on the point, that's fair. I have a tendency to 
get into sidetracks when talking about things that interest me, like 
maps.


But if you look at it, it's a starter email, then it's just replies to 
replies. I started two threads yesterday. Anyone is free to reply at the 
speed they want. If replies come slower, my responses to them come 
slower. If I have less time to reply a certain day, my replies come 
slower, (I usually don't start threads busy days though). I don't 
require people to reply fast, never had. It's a thread, people don't 
need to dive into threads dealing in issues they are not interested in 
if they don't want to. And I certainly don't think I win if people don't 
reply, why would I do that? It's not really even about "winning" an 
argument, I don't see it that way, it's about presenting a viewpoint and 
the needs and argue for that and hopefully convince people that there is 
a need somewhere. If someone doesn't reply I just read what their last 
statement on the subject was. I don't invent new emails in my head that 
say "I agree" :-).


But I'm not blind, I see it's not working out well, so regardless of 
what I think is fair or not I need to change the style or just back off. 
It's not that easy though when being passionate about a subject. Sorry 
for that.


/Anders

On 2020-12-21 22:08, Frederik Ramm wrote:

Anders,

On 12/21/20 21:36, Anders Torger wrote:
Actually it seems to me that thinking about several tags at a time 
seems

to be a fairly new concept ;-)


I think this is approximately your 15th message today on the tagging
list. Together, without quotes, you have written about 5,000 words of
original content.

Now, we are a community and your opinion is not worth more than that of
others on the list of course. The total number of regular contributors
on this list is perhaps around 20. If every one of these 20 wrote as
much as you do - as would be their right - we'd end up with about
100,000 words on tagging, every day.

The average reading speed of most adults is around 200 to 250 words per
minute (and that does not include spending time to actually think about
complex problems, just reading and understanding).

If every one of the 20 active contributors were writing as much as you
do, we'd each of us have to spend more than 6 hours reading this list
every day.

Even just what you wrote today takes 20 minutes out of the day of the
average reader (and again, this is only for reading, not for thinking
about the problem).

Please consider that many of us juggle many different responsibilities,
including work, family, or mapping.

The next time you make a point, or raise a topic for discussion:

1. Ask yourself if there's another big discussion currently ongoing. If
yes, maybe postpone the thing you want to discuss.

2. Ask yourself if you have already written more than 1000 words today.
If yes, maybe postpone your message.

3. If you have just started a topic and people are, slowly and as their
time permits, responsing to what you have written, resist the urge to
fire off an immediate reply to everyone who writes something. This is
not "Anders Torger versus the world". You can raise a topic, then you
should give everyone some time to think about it and say their opinion.

If you write so much that others stop replying, it doesn't mean you 
won;

it means you have ruined the medium.

Bye
Frederik


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

Re: [Tagging] Feature proposal - Voting - guard stone

[Volker Schmidt]

On Tue, 22 Dec 2020, 01:02 Paul Allen,  wrote:

> On Mon, 21 Dec 2020 at 23:34, Volker Schmidt  wrote:
>
> (perhaps the duck principle could be applied: it looks like a guardstone,
>> it keeps the wheels on the road like a guard stone, hence it can tagged as
>> a guard stone)
>>
>
> Guardstones don't keep the wheels on the road, they keep the wheels off the
> building.  Your duck is a drake
>
I am not saying they are the same, I was pointing out, that, by stretching
the duck principle a bit you could use the same tag. But I would prefer us
finding a better tag.

>
> The pair of "guard" stones one on each side of the minor road could be a
>> kind of ancient width limiter for passing vehicles. I have seen many of
>> these on the artificial earthen embankments (Italian: argine) that are
>> common along waterways in the flat lands of Northern Italy. So we could tag
>> them as barrier=bollard; maxwidth=x
>>
>
> Seems plausible.
>
> The rows of "guard stones" along roads are certainly a predecessor of
>> guard rails, i.e. they prevented vehicle from veering off the road.
>>
>
> Maybe, but they're on the wrong side of the road.  They prevent the vehicle
> veering into trees, which would be just as effective as stopping it going
> further and do as much (or as little) damage.  A guardrail would be
> on the other side of the road, to prevent a vehicle going over the cliff.
>
You must be looking at different picture. The one I linked, shows
definitely false guard stones on the valley side. I drove that road in
1963, when it was in better shape, I guarantee you the protection was on
the correct side, and the terrain  is steep.

>
>> I just googled this interesting German document
>> 
>> So the German term is "Leitstein", at lest it was in the former DDR The
>> modern
>>
> equivalent are the "Leitpfosten
>> ", French "délinéateur", but
>> there is no English
>>
> equivalent
>>
>
> The English equivalent of the modern Lietpfosten appears to be
> called "verge marker" or "marker post" (the bulkier ones are
> called bollards)
> https://uk.glasdon.com/road-safety/reflective-verge-markers
>
> I don't know the English term for Leitstein or even if we ever had such
> things.
>
I learned the term. "Leitstein" today from the report that I googled.

Volker

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

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

[Kevin Kenny]

On Mon, Dec 21, 2020 at 3:38 PM Anders Torger  wrote:

> I think it's more about that most OSMers are interested in urban areas,
> street routing and stuff like that, and outdoor maps haven't really been
> much of a thing other than for simple illustrative purposes.
>
Most OSM'ers are sophisticated computer users. Most humans are interested
most in mapping the features that they interact with. Most sophisticated
computer users live in cities.

Those of us who map in the wild areas of New York State (which are
surprisingly large; the Adirondack Park is slightly smaller than Belgium;
larger than New Jersey, Massachusetts or Slovenia), deal with the problem
of "too much ground to cover, too few people to map it."  The Adirondack
Park, for all that its land area is comparable to the states and countries
that I mentioned, has a population of only about 130,000.  Only about a
quarter of the residents have broadband service; many do not even have
land-line telephone. Cell service is spotty in the villages and nonexstent
in the back country, even on I-87 (the one freeway that crosses the park).
There are no computer geeks, because there are no computer geek jobs.  On
one mapping trip through the park, I had to plan a 100-km segment without
resupply. (The segment included one stop at a developed campground, but
nowhere to buy groceries or charge batteries!) The Catskill Park is not
quite as remote, but nearly so; it certainly has wilderness areas big
enough to get lost in.

Given the overwhelming size of the area, and the scarcity of mappers, I
don't expect the area to be mapped well in OSM. Nevertheless, for certain
features such as hiking trails, campsites, and similar amenities, OSM is
the best data source that I have.

In producing my own maps, such as what you might see in
https://kbk.is-a-geek.net/catskills/test4.html?la=44.1408=-74.1034=15,
I've had to depend on external data sources to a great extent.  Even the
external data sources are not "boots on the ground" surveys; for instance,
I know that the landcover has largely been derived from computer-based
analysis of multi-band, multi-season satellite imagery. (The multi-season
aspect allows for estimating the leaf cycle.)

This is far from an ideal rendering for outdoor maps, but it's at least an
attempt at a proof of concept.

Because I'm combining so many data sources, the map takes on rather a
'cubistic' aspect, with, for instance, many shorelines drawn for the water
bodies.  I actually find this to be an advantage in practice. If I see
shorelines that vary widely, I know that I can expect that the water level
will be correspondingly variable, according to season and level of beaver
activity.  If I see that different databases have multiple routings of a
trail giving a 'braided' appearance, I have reason to expect that the trail
in that area will be indistinct and difficult to follow.

Indeed, my chief concern in rendering (beyond things like the open problems
of better lettering of area features, suppression of river names inside
lakes, representation of features such as mountain ranges, valleys, ridges,
passes, ...) is how better to manage conflation of features when I have
up-to-date information in OSM and out-of-date information in the external
databases.  Duck Hole, for isntance, is rendering peculiarly because OSM
has it as a wetland with a rather different boundary. The Cold River dam
failed in 2011 and there are no plans to rebuild. but NLCD (National
Landcover Database) and the APA (Adirondack Park Agency)  hydrography
database have never been updated to provide that information. Nevertheless,
hydrographic features are pretty stable and those datasets are considerably
more complete (albeit less reliable) than OSM.

It's a common mistake for the urban micromappers to think that if the
country folk cared about their mapping, they'd micromap to the same level.
It's just not feasible to do so. The lack of mapping does not indicate a
lack of interest.

In any case, I hope that this side project indicates that you're not alone
in your interest in mapping outdoor recreation. Note that this particular
project is very much US-specific, owing to the fact that I'm building it
from US-specific data sources, and its iconography is also distinctly
USAian, but I think the principles could apply anywhere.

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

[Paul Allen]

On Mon, 21 Dec 2020 at 21:50, Kevin Kenny  wrote:

I don't think I've had the situation come up, but if it did, I'd probably
> map the riverbank only once, and split the river at the fall and at the
> outlet of the pool. Do the ordinary waterway=riverbank or water=river
> mapping for the river as a whole, and create a multipolygon (probably
> tagged natural=water water=pond) to represent the pool.
>
> I've seen only one plunge pool.  And that was dammed to turn it into a
mill pond.
But I've seen many stream pools that I've yet to map properly.  They're
usually named, because they are of significance to anglers or boat
builders.  It's easier to do it your way, unless you want to name the pool.

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

Re: [Tagging] Feature proposal - Voting - guard stone

[Joseph Eisenberg]

 C) Freestanding guardstone-like objects are often found independently of
buildings.

Those look like barrier=bollard perhaps?

On Mon, Dec 21, 2020 at 9:33 AM Volker Schmidt  wrote:

> I forgot to follow up on two other aspects of this, sorry.
>
> A) how are they tagged when two of them are on both sides of a gate
> 
> ?
>
> B) There are occasionally also rows of them in historic towns
> 
> .
>
> C) Freestanding guardstone-like objects are often found independently of
> buildings.
> I am not sure what they are called, here are some examples.
> They come in three types of  arrangements:: pairs, or rows, or pairs of
> rows.
> The pairs are often on minor roads on embankments
>  (don't know
> what the purpose was)
> The rows are often on major roads on embankments
> , or older
> mountain pass roads.
> 
> (predecessors of guardrails I suppose)
>
> Volker
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6450454857789031944_m_980705564951531214_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, 21 Dec 2020 at 11:50, Anne-Karoline Distel 
> wrote:
>
>> Hi,
>>
>> there haven't been any comments on it in a while, so I think it is safe
>> to start the voting process on
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>>
>> Voting ends on January 4th.
>>
>> Thanks to everyone who contributed to the discussion and proposal page!
>>
>> Happy holidays,
>>
>> Anne (b-unicycling)
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6450454857789031944_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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 - addr:interpolation on closed ways and nodes

[ipswichmapper--- via Tagging]

How would this break routing and navigation? As far as I know, geocoders 
currently read hypenated addresses as ranges anyway (correct me if I'm wrong) 
so this proposal won't change what happens to hypenated addresses without 
addr:range tag. (Ime. Navigation is already broken in NYC)

IpswichMapper
---


21 Dec 2020, 19:44 by kevin.b.ke...@gmail.com:

>
>
> On Mon, Dec 21, 2020 at 2:15 PM ipswichmapper--- via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> What do you mean by this? You would have to tag with addr:range=no, as that 
>> is not a default value.
>>
>> However, don't see this as a downside. Currently, software such as OSMand 
>> interprets hypenated addresses as a range anyway, so requirement to  tag 
>> addr:range=no would be a benefit.
>>
>
> Ouch.  So every building in Queens, NY (one of the five boroughs of New York 
> City, with about 2.3 million inhabitants) would need to have an 
> 'addr:range=no' tag added in order not to break routing and navigation there?
>
>
> -- 
> 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?

[Anders Torger]

Sorry, forgot to add that an alternative to fuzzy areas would be to do 
like hamlet/village/town/city etc and have a bunch of these point names 
for various natural features that we could place out instead of fuzzy 
areas. Do you think that is better?


That combined with an external database for huge areas ("the Alps") 
would fulfill most needs. Shaping text for the small fuzzy areas is not 
really much of a thing so point naming would be satisfactory, but would 
be quite many tags that needs introducing, while the fuzzy area is more 
a continuation of areas that already exist and are to some extent 
already in use. I also think a fuzzy area does provide some valuable 
information and requires the mapper to make a healthy think over what 
the name actually refers to and covers, and avoids the issue of "which 
tag size to use".


That said, I would pick hierarchical point naming over nothing any day.

/Anders

On 2020-12-21 19:30, Mateusz Konieczny via Tagging wrote:


Dec 21, 2020, 16:42 by zelonew...@gmail.com:

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.


Bigger problem is that with things like mountain ranges there are 
multiple differing opinions

about borders.

For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy 
multiple authors

give precise, unfuzzy borders (specific rivers or roads).

But different authors prefer different borders.

See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans
and 
https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
for other kind of differences. Modelling this is not fitting well how 
OSM works.



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.


I would not say cannot, but it is extremely poor fit to OSM data model 
and how

OSM operates.

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.


It is not so easy. Someone mapped several fuzzy areas in my regions and 
all of

them are extremely irritating while mapping.

Building outlines are not stretching for hundreds of kilometers and do
not appear in places where there is nothing at all and building outlines
are verifiable unlike mess like 
https://www.openstreetmap.org/relation/1757627

and other from https://overpass-turbo.eu/s/11pc

Some day I will need to check whatever it is also one big copyright 
violation
(for now I just left questions at ancient changesets that added this 
mess).


___
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 - addr:interpolation on closed ways and nodes

[Kevin Kenny]

On Mon, Dec 21, 2020 at 2:15 PM ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

> What do you mean by this? You would have to tag with addr:range=no, as
> that is not a default value.
>
> However, don't see this as a downside. Currently, software such as OSMand
> interprets hypenated addresses as a range anyway, so requirement to  tag
> addr:range=no would be a benefit.
>

Ouch.  So every building in Queens, NY (one of the five boroughs of New
York City, with about 2.3 million inhabitants) would need to have an
'addr:range=no' tag added in order not to break routing and navigation
there?


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

[Kevin Kenny]

On Mon, Dec 21, 2020 at 1:56 PM Anders Torger  wrote:

> Do you think there is a valid use for fuzzy areas in outdoor/rural areas,
> or would you rather see them not being used there either?
>

I've mentioned before that I, at least, have fuzzy administrative
boundaries to deal with.

https://caltopo.com/map.html#ll=43.9281,-74.49657=14=t shows an example
of a political boundary where even the USGS topo has the callout,
'INDEFINITE BOUNDARY' - and an error of closure indicated at the north
corner of Arietta township!

(It's not just an error in aligning the map sheets.  Note that the contour
lines and water bodies align perfectly.  The old surveys simply don't line
up. Nobody cares enough to put up the substantial expense that it would
take to resolve the question.)

In the hamlet of Oxbow, the residents do care what township they inhabit
(and pay taxes to), so the town line is surveyed and monumented in the
little strip at https://caltopo.com/map.html#ll=43.43904,-74.48374=15=t
.  Most of the rest is pretty, uhm, approximate.

Historical fact: Gore Mountain
https://caltopo.com/map.html#ll=43.67821,-74.03996=14=t was so named
because it fell in the 'gore' created by the fact that the old land grant
lines failed to close, and hence didn't belong to any township.  In that
case, nobody cared for decades, until Barton discovered garnets on its
north slope.  A protracted legal battle ensued over which town had the
right to tax the mines, which was eventually resolved by resurveying the
old lines and creating the new town of Johnsburg in the gap. That's just
how we address these questions here in the US; ignore them until someone's
willing to pay to find out the answer.

The answer to 'what county contains the cluster of houses on Kings Flow (
https://caltopo.com/map.html#ll=43.68781,-74.22956=15=t)?' is obvious:
Hamilton County.  The answer to "which county contains the summit of
Chimney Mountain?" is "who wants to know?"

Topology matters. You can't answer an 'inside/outside' query without a
closed region. Whatever solution we arrive at, it ought to allow an
implementor to resolve a question like, "in what county is the village of
Indian Lake?" (Hamilton, despite its indefiite boundary!) or  "Is Port
Sudan a port on the Red Sea?" If it cannot represent the fuzzy world to the
point where that sort of question can be answered, it is an incomplete
solution. Nobody familiar with the places would have the slightest trouble
answering those questions.

I'm really reluctant to say that the solution must be to foist the problem
off on an external database.  All geodata are approximate. To say that
anything with imprecision doesn't belong in OSM is to open the door to
endless haggling over how good the survey must be before data meet OSM's
standards. Is that the path we want to take?
-- 
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]

On Dec 21, 2020, at 10:53 AM, Anders Torger  wrote:
> Cluttering could be a problem, but is an easy thing to solve with filters. As 
> I edit i national parks now I have this huge national park polygon covering 
> all work, which renders as a flat although half-transparent color in JOSM. 
> It's easy to remove with a filter though, but actually I'm not disturbed by 
> it enough to care to do it. If we actually define this as a feature we could 
> have a filter setup for these in our tools.

Anders, think about what you are saying:  defining fuzzy areas (work to do, 
work to achieve consensus...) virtually requires a tool filter for reducing or 
eliminating them from how many — even most — mappers view them?  That smacks 
(hard) of "OSM:  do something quite different from what you do (for me and my 
purposes) and then filter out the results (as noise) from your views of the 
data."  Do you see how this entire approach can be seen as offensive by OSM?  I 
don't want to stifle real questions about whether we want fuzzy areas, as it's 
a valid discussion.  But positing it like this is 100% a non-starter.

> The question becomes more complex as there are several types of these areas. 
> Regions in cities like this I haven't thought about before, I didn't know 
> that it existed. It has quite different impact than a plateau in the 
> mountains.

Yes, it does become more complex.  You haven't thought about these?  Thinking 
about these (and others like them, yet also unlike them) is required.  There 
are no shortcuts to that.

> I think it would be unfortunate if a few bad examples of fuzzy area use or 
> (simple) limitations in our tools block all use or further development of 
> them, as they are important for certain type of maps in certain areas.

Repeating myself:  "there is good design, there is bad design."  Which do you 
think OSM prefers?

> I guess cities can do well without region mapping or just use points which 
> there is a quite rich definition for already (neighboorhood etc),

Yes, the specifics of how to map "smaller conurbations" (within larger 
conurbations) is documented in our place=* wiki.  There is no need to guess at 
how to use nodes (or closed ways) to do this.  (Not "points").

> but making an outdoor/rural map without naming nature and without proper 
> support for zooming out (ie having some approximate size of the named 
> features), greatly cripples the capabilities of maps rendered for those areas.

There you go again:  you seem to persist with this basic understanding that 
OSM's rendered map data are "what OSM is."  No.  OSM is data.  Accurate, 
ground-verifiable (there are some specific exceptions, like boundaries), 
peer-reviewable, properly tagged (because consensus establishes the tagging 
scheme) data.  Stop tagging for the renderer!  (And / or build your own).

> Do you think there is a valid use for fuzzy areas in outdoor/rural areas, or 
> would you rather see them not being used there either?

I see potential value in the concept (a good place to start, as I have said).  
I don't see anything nearly enough for me to conclude (let alone even begin to 
consider, yet) that "fuzzy areas" should be "in" OSM.  In some separate, 
OSM-friendly (possibly to be mingled with OSM data) repository which can be 
cleverly blended?  Maybe.  I would need much more proposal-oriented specific 
propositions with which to evaluate that before I could proceed.  Should you 
wish to continue in this direction, please develop one (or several) such 
proposals (starting with familiarity with our culture, process and tools, then 
progressing through questions and dialog) and this community will consider it / 
them.  Jump up and down that "we are crippled because we don't do what you 
think we should do" (and don't currently, because it isn't what we do, it is 
what you THINK we SHOULD do), no.  This community should not consider repeated 
complaints that we do not do what one Contributor thinks we should do as valid 
methodology to quite radically alter our data model.  Such an approach is 
doomed to failure, and should be.  Constructive propositions to different ways 
of doing things?  Proposed as the community has evolved to discuss, develop and 
accept them?  Sure, we do that here.  Absorbing repeated complaints that we 
shouldn't continue with a working process and listen to one, persistent 
complainer?  Nope.  That's not how this project works.

Anders, honestly, I'm trying to help you.

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

What do you mean by this? You would have to tag with addr:range=no, as that is 
not a default value.

However, don't see this as a downside. Currently, software such as OSMand 
interprets hypenated addresses as a range anyway, so requirement to  tag 
addr:range=no would be a benefit.

IpswichMapper
-- 
 


21 Dec 2020, 18:27 by zelonew...@gmail.com:

> 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

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

[Paul Allen]

On Mon, 21 Dec 2020 at 18:51, Brian M. Sperlongano 
wrote:

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

I knew what you meant by "conflate."  Others may not.

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

It feels more natural to map a side pool of a wide river which has a river
polygon
by expanding the polygon.  But such a pool cannot be named.  It feels
unnatural to tack a pond onto the side of a river polygon.  But I suppose
it will work.

-- 
Paul
___
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 Mon, Dec 21, 2020 at 1:41 PM Paul Allen  wrote:

> On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano 
> wrote:
>
>>
>> "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."
>>
>
> 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.
>
> Also, there are tidal pools (which may be outside the scope of the
> proposal).
>
> Is this distinction satisfactory?  How are folks tagging these features?
>>
>
> I've been tagging them as ponds, for lack of anything better.  Well,
> until a few days ago I didn't realize the distinction between ponds
> and pools so I was tagging them as ponds because I didn't know
> they weren't ponds but pools.  If I'd had to map bigger ones
> I'd have tagged them as lakes.
>
>
I've been tagging them as `natural=water`.  :)
Or maybe `waterway=riverbank.`.


In the karst terrain around here, you sometimes have to do more geologic
investigation than I have time for to determine what's actually retaining
the water in a waterbody, and there are plenty for which the distinctions
are unclear anyway. https://www.openstreetmap.org/way/226924460 appears in
origin to be a glacial tarn.  It has an outflow stream, but the majority of
the water exits through percolation (there's no identified sinkhole) into
the caves beneath, and tracers injected into the water have appeared in
several of the stream outlets below the cliffs
https://www.openstreetmap.org/way/595609787.   In a dry summer, the outflow
stream may stop flowing entirely, but the lake never dries up.  So is that
a tarn, or a doline, or (considering that humans have actually dammed the
outflow stream in an effort to preserve the boating value of the lake) a
reservoir?  Frankly, I don't care very much. I have no ambition to produce
a detailed map of the local surface geology, which is horrendously
complicated. It's a permanent body of fresh water, navigable by pleasure
boats. If someone else wants to try to fill in the geologic details, be my
guest!

I might tag as `waterway=riverbank` (the commonest usage around here) if
there's no good reason not to keep the plunge pool separate from the river,
as at the base of https://www.openstreetmap.org/node/5844315874.



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

[Anders Torger]

Cluttering could be a problem, but is an easy thing to solve with 
filters. As I edit i national parks now I have this huge national park 
polygon covering all work, which renders as a flat although 
half-transparent color in JOSM. It's easy to remove with a filter 
though, but actually I'm not disturbed by it enough to care to do it. If 
we actually define this as a feature we could have a filter setup for 
these in our tools.


The question becomes more complex as there are several types of these 
areas. Regions in cities like this I haven't thought about before, I 
didn't know that it existed. It has quite different impact than a 
plateau in the mountains.


I think it would be unfortunate if a few bad examples of fuzzy area use 
or (simple) limitations in our tools block all use or further 
development of them, as they are important for certain type of maps in 
certain areas. I guess cities can do well without region mapping or just 
use points which there is a quite rich definition for already 
(neighboorhood etc), but making an outdoor/rural map without naming 
nature and without proper support for zooming out (ie having some 
approximate size of the named features), greatly cripples the 
capabilities of maps rendered for those areas.


Do you think there is a valid use for fuzzy areas in outdoor/rural 
areas, or would you rather see them not being used there either?


/Anders

On 2020-12-21 19:30, Mateusz Konieczny via Tagging wrote:


Dec 21, 2020, 16:42 by zelonew...@gmail.com:

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.


Bigger problem is that with things like mountain ranges there are 
multiple differing opinions

about borders.

For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy 
multiple authors

give precise, unfuzzy borders (specific rivers or roads).

But different authors prefer different borders.

See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans
and 
https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
for other kind of differences. Modelling this is not fitting well how 
OSM works.



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.


I would not say cannot, but it is extremely poor fit to OSM data model 
and how

OSM operates.

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.


It is not so easy. Someone mapped several fuzzy areas in my regions and 
all of

them are extremely irritating while mapping.

Building outlines are not stretching for hundreds of kilometers and do
not appear in places where there is nothing at all and building outlines
are verifiable unlike mess like 
https://www.openstreetmap.org/relation/1757627

and other from https://overpass-turbo.eu/s/11pc

Some day I will need to check whatever it is also one big copyright 
violation
(for now I just left questions at ancient changesets that added this 
mess).


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

> 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

[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

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

[Paul Allen]

On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano 
wrote:

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

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.

Also, there are tidal pools (which may be outside the scope of the
proposal).

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

I've been tagging them as ponds, for lack of anything better.  Well,
until a few days ago I didn't realize the distinction between ponds
and pools so I was tagging them as ponds because I didn't know
they weren't ponds but pools.  If I'd had to map bigger ones
I'd have tagged them as lakes.

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

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

[Mateusz Konieczny via Tagging]

Dec 21, 2020, 16:42 by zelonew...@gmail.com:

>
>
> On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm <> frede...@remote.org> > 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.
>
Bigger problem is that with things like mountain ranges there are multiple 
differing opinions
about borders.

For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy multiple 
authors
give precise, unfuzzy borders (specific rivers or roads).

But different authors prefer different borders.

See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans
and https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
for other kind of differences. Modelling this is not fitting well how OSM works.


>
>
>> 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.
>
I would not say cannot, but it is extremely poor fit to OSM data model and how
OSM operates.

> 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.
>
It is not so easy. Someone mapped several fuzzy areas in my regions and all of
them are extremely irritating while mapping.

Building outlines are not stretching for hundreds of kilometers and do
not appear in places where there is nothing at all and building outlines
are verifiable unlike mess like https://www.openstreetmap.org/relation/1757627
and other from https://overpass-turbo.eu/s/11pc

Some day I will need to check whatever it is also one big copyright violation
(for now I just left questions at ancient changesets that added this mess).

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks Steve, good to know about the wiki, I had a hunch that was how 
it's meant but wasn't really sure. Certainly descriptive for this tag. I 
guess I could "take over" the fell tag but starting massively use it for 
bare mountain landcover, but I shall look more closely into 
alternatives.


Just starting using Overpass Turbo, seems like a really cool and useful 
tool, and impressively fast for the amount of data there is. With a bit 
of learning curve as you say though :-D.


I think I've read about heath+alpine=yes somewhere, I'll see if I can 
make an OT search for it :-).


/Anders

On 2020-12-21 19:11, stevea wrote:

Nice, Anders.  You can use taginfo to get "the raw numbers" (quantity)
of a particular kind of tagging.  What might work specifically for you
in this case is to use some well-crafted Overpass Turbo queries (over
a specific area at first, you can use the "bbox" method of "what you
see on-screen" or you can use the "geocodeArea" directive to restrict
the query to a named place).  OT querying takes some practice to
become skilled in its vast power to query OSM data, but it is worth
investing in the learning curve to do this, as it is likely (imo) the
most powerful tool we have to ask our data "what about this, like
this?"

Usually, our wiki describe "tagging as is," what is known as
"descriptive."  On occasion, some wiki will be "prescriptive," meaning
"here is how one SHOULD tag, though I make a point to say that any
wiki which does that should say so explicitly.

Good luck in your endeavors!

SteveA


On Dec 21, 2020, at 9:56 AM, Anders Torger  wrote:
I just discovered a strange(?) thing with the "natural=fell" tag which 
I missed at first: on the wiki page there's two purposes defined of 
this single tag, the first is landcover of bare mountain as discussed, 
and the other purpose is, quote from the wiki:


"In the north of England, and probably in other areas of Norse 
influence such as Iceland, Norway and Sweden, there is a practice of 
naming the sides of hills, fells, rather than peaks. A single hill can 
have different names on different sides. This tag can be used to 
record such names."


It's true that we do have such a practice although more so at lower 
altitudes. I recently added such a name on an alpine mountain as a 
fell cutout with a fixme tag (there is no other tag for slopes I 
think, didn't realize that "fell" is it). However as said we have 
"fell" in that sense in forested areas as well, even more common 
there.


I guess if "fell without name tag" is defined as landcover, and "fell 
with name tag" is defined as fuzzy area naming a side of a hill it 
could work, but it's the first time I see this type of dual 
definition. Is it normal, or is the wiki page just documenting how 
this tag have ended up being used?


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

[Mateusz Konieczny via Tagging]

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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

Nice, Anders.  You can use taginfo to get "the raw numbers" (quantity) of a 
particular kind of tagging.  What might work specifically for you in this case 
is to use some well-crafted Overpass Turbo queries (over a specific area at 
first, you can use the "bbox" method of "what you see on-screen" or you can use 
the "geocodeArea" directive to restrict the query to a named place).  OT 
querying takes some practice to become skilled in its vast power to query OSM 
data, but it is worth investing in the learning curve to do this, as it is 
likely (imo) the most powerful tool we have to ask our data "what about this, 
like this?"

Usually, our wiki describe "tagging as is," what is known as "descriptive."  On 
occasion, some wiki will be "prescriptive," meaning "here is how one SHOULD 
tag, though I make a point to say that any wiki which does that should say so 
explicitly.

Good luck in your endeavors!

SteveA


On Dec 21, 2020, at 9:56 AM, Anders Torger  wrote:
> I just discovered a strange(?) thing with the "natural=fell" tag which I 
> missed at first: on the wiki page there's two purposes defined of this single 
> tag, the first is landcover of bare mountain as discussed, and the other 
> purpose is, quote from the wiki:
> 
> "In the north of England, and probably in other areas of Norse influence such 
> as Iceland, Norway and Sweden, there is a practice of naming the sides of 
> hills, fells, rather than peaks. A single hill can have different names on 
> different sides. This tag can be used to record such names."
> 
> It's true that we do have such a practice although more so at lower 
> altitudes. I recently added such a name on an alpine mountain as a fell 
> cutout with a fixme tag (there is no other tag for slopes I think, didn't 
> realize that "fell" is it). However as said we have "fell" in that sense in 
> forested areas as well, even more common there.
> 
> I guess if "fell without name tag" is defined as landcover, and "fell with 
> name tag" is defined as fuzzy area naming a side of a hill it could work, but 
> it's the first time I see this type of dual definition. Is it normal, or is 
> the wiki page just documenting how this tag have ended up being used?
> 
> /Anders


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

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

[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] Feature Proposal - RFC - crossing=priority

[Matthew Woehlke]

On 20/12/2020 08.54, ipswichmapper--- via Tagging wrote:
- What should be considered a crossing? If it is unmarked, is it a 
crossing at all? (Should all intersections be tagged as "unmarked 
crossings"? Are places with traffic islands (no kerbs) where people 
frequently cross considered as crossings even though they have no 
marking & no kerbs?)


FWIW, I would say a crossing is somewhere there is a clear expectation 
that people will cross the road. For example, where a sidewalk connects 
to the curb on either side of the road but there are no markings on the 
pavement would be an unmarked crossing. I've seen these in both aerial 
imagery and in person.


To respond to Paul's point, I would tend to think of "marking" as 
referring to markings *on the road pavement*, not just on the sidewalk.


--
Matthew

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

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

I just discovered a strange(?) thing with the "natural=fell" tag which I 
missed at first: on the wiki page there's two purposes defined of this 
single tag, the first is landcover of bare mountain as discussed, and 
the other purpose is, quote from the wiki:


"In the north of England, and probably in other areas of Norse influence 
such as Iceland, Norway and Sweden, there is a practice of naming the 
sides of hills, fells, rather than peaks. A single hill can have 
different names on different sides. This tag can be used to record such 
names."


It's true that we do have such a practice although more so at lower 
altitudes. I recently added such a name on an alpine mountain as a fell 
cutout with a fixme tag (there is no other tag for slopes I think, 
didn't realize that "fell" is it). However as said we have "fell" in 
that sense in forested areas as well, even more common there.


I guess if "fell without name tag" is defined as landcover, and "fell 
with name tag" is defined as fuzzy area naming a side of a hill it could 
work, but it's the first time I see this type of dual definition. Is it 
normal, or is the wiki page just documenting how this tag have ended up 
being used?


/Anders

On 2020-12-21 18:27, stevea wrote:
On Dec 21, 2020, at 7:10 AM, Tomas Straupis  
wrote:

2020-12-21, pr, 16:52 Anders Torger rašė:

But what to do if the things you want doesn't
really fit into what OSM currently is and strives to be...


 We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
 YOU define what OSM is and where it is going to by DOING.
 The more I look at it, the more it seems that fragmentation is
inevitable. Question is how much will remain "common".


Thank you for saying it like this, Tomas.  Fragmentation happens,
though it is not the end of OSM when it does.  Private projects, when
they happen, don't necessarily harm OSM, they prove its strength as a
solid foundation of data upon which are built bespoke / custom
solutions.  These even can (and do?) "link up" to form a stronger
fabric which "rides along with" the solid foundation.  There are
examples of this in OSM right now.  Truly, a lot of what was said in
the last few posts are bullseyes on a target:

• YOU define what OSM is by DOING (a crucially important truth!)

• While "local renderers" are by definition limited in their scope,
they need not be limited in their use:  they can be practical/visual
proofs of "better ways" (to do things), testing grounds for finding
solutions to more international problems

• There are already local communities creating local cartographic data
schemas, this is already being talked about as becoming more-widely
and better integrated among data consumers (like yourself, Anders —
that's how this works)

• Making OSM into what we might use in the future as a "baseline" map
for a drop-in replacement for government maps (in Sweden, for example)
will doubtless earn us growing contributions that surpass the
government maps.  Yes, that's a fair bit of sweat, work and time, but
it is worth it!  (That's a fantastic dream, well-stated and shared by
many, Anders!)

• Agreeing on the goals FIRST (among peers who can, do and will work
towards them) takes energy, but it is worth it!

• It is easy to get hooked on this kind of mapping / data /
collaboration!  It works, it is a lot of fun.  Repeat ad infinitum.


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

Re: [Tagging] Feature proposal - Voting - guard stone

[Volker Schmidt]

I forgot to follow up on two other aspects of this, sorry.

A) how are they tagged when two of them are on both sides of a gate

?

B) There are occasionally also rows of them in historic towns

.

C) Freestanding guardstone-like objects are often found independently of
buildings.
I am not sure what they are called, here are some examples.
They come in three types of  arrangements:: pairs, or rows, or pairs of
rows.
The pairs are often on minor roads on embankments
 (don't know what
the purpose was)
The rows are often on major roads on embankments
, or older
mountain pass roads.

(predecessors of guardrails I suppose)

Volker


Virus-free.
www.avast.com

<#m_980705564951531214_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 21 Dec 2020 at 11:50, Anne-Karoline Distel 
wrote:

> Hi,
>
> there haven't been any comments on it in a while, so I think it is safe
> to start the voting process on
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>
> Voting ends on January 4th.
>
> Thanks to everyone who contributed to the discussion and proposal page!
>
> Happy holidays,
>
> Anne (b-unicycling)
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 21, 2020, at 7:10 AM, Tomas Straupis  wrote:
> 2020-12-21, pr, 16:52 Anders Torger rašė:
>> But what to do if the things you want doesn't
>> really fit into what OSM currently is and strives to be...
> 
>  We are ALL OSM community. If somebody tells you that "I am OSM and
> only A is right" - do not believe them.
>  YOU define what OSM is and where it is going to by DOING.
>  The more I look at it, the more it seems that fragmentation is
> inevitable. Question is how much will remain "common".

Thank you for saying it like this, Tomas.  Fragmentation happens, though it is 
not the end of OSM when it does.  Private projects, when they happen, don't 
necessarily harm OSM, they prove its strength as a solid foundation of data 
upon which are built bespoke / custom solutions.  These even can (and do?) 
"link up" to form a stronger fabric which "rides along with" the solid 
foundation.  There are examples of this in OSM right now.  Truly, a lot of what 
was said in the last few posts are bullseyes on a target:

• YOU define what OSM is by DOING (a crucially important truth!)

• While "local renderers" are by definition limited in their scope, they need 
not be limited in their use:  they can be practical/visual proofs of "better 
ways" (to do things), testing grounds for finding solutions to more 
international problems

• There are already local communities creating local cartographic data schemas, 
this is already being talked about as becoming more-widely and better 
integrated among data consumers (like yourself, Anders — that's how this works)

• Making OSM into what we might use in the future as a "baseline" map for a 
drop-in replacement for government maps (in Sweden, for example) will doubtless 
earn us growing contributions that surpass the government maps.  Yes, that's a 
fair bit of sweat, work and time, but it is worth it!  (That's a fantastic 
dream, well-stated and shared by many, Anders!)

• Agreeing on the goals FIRST (among peers who can, do and will work towards 
them) takes energy, but it is worth it!

• It is easy to get hooked on this kind of mapping / data / collaboration!  It 
works, it is a lot of fun.  Repeat ad infinitum.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Anders Torger]

Maybe we need to split "small" and "large" fuzzy areas into different 
concepts. Or at least different discussions, as they are quite different 
in terms of how they affect the map and what needs they fulfill.


I do see a risk of edit wars of large fuzzy areas that make great impact 
on overview maps. I already thought we had that on country borders in 
conflict areas and such, so maybe we already have routines to deal with 
that? If we can't introduce features due to edit war risk, maybe the 
problem is not the feature as such, but how we can handle edit wars? 
Edit wars is completely new to me though, so I don't know much about 
this problem area or how much we normally let it affect our features.


I don't think these large fuzzy areas need to have very large amount of 
nodes by the way (they just lay on top, as they are defined as fuzzy 
it's unnecessary to specify lots of nodes), but they need to cover a 
large geographical area. You couldn't really edit them in JOSM or iD 
normally I think, but I don't think "normal" mappers would need to 
either. Having them in an external database and not integrate with the 
normal tools would be ok, and I guess that would also solve the edit war 
issue too. I'd very much like it to be rendered in OSM-Carto at some 
point though so we don't completely forget about it, but I would suspect 
that there are technical difficulties to do that with the current 
platform so we could skip that for now.


However, fuzzy areas needed for rural and outdoor maps cover a wetland, 
a piece of forest, a small plateau, a slope of a mountain, a valley, a 
peninsula in a lake etc, those are unlikely to be a problem in terms of 
edit wars. They are also small enough to be accessible for edit in JOSM 
and iD today, and as I often mention already exists and renders in the 
form of bays and straits, which I actually need to use quite often as we 
have these in our lakes of different sizes and coverage, meaning that 
point naming without size differentiation doesn't work.


Having a "fuzzy tag" I think is a good idea, although we could also do 
it as a flat structure with a list of tags that are defined as being 
fuzzy. Anything that works :-).


If there is large opposition from the people that make the renderers 
most of us use against these type of features I don't think we have much 
chance of success though. I think it's hard to get crowd-sourcing going 
if there is no renderer at all supporting it.


/Anders

On 2020-12-21 17:16, Paul Allen wrote:

On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano 
 wrote:


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.


I assume that there is a technical limitation on the number of nodes in 
such a
polygon.  A limitation that may apply to any or all of editors, 
database tables
and renderers.  There may be some technical workarounds, there may not 
be.



"Whether we want fuzzy areas"


To an extent, everything we map is fuzzy, in that there is always 
imprecision.
Aerial imagery may be offset.  Roads may pass through woods giving 
little or
no visual indication.  GPS traces have errors and require many traces 
to
achieve good precision.  Everything we map is fuzzy in the sense that 
it

is imprecise but we live with that and understand that the map is an
approximation that we may be able to improve upon at a subsequent date.

The dislike of fuzziness here appears to centre around verifiability.
We don't want edit wars over the extent of a boundary for which
no definitive answer can ever be given.  We want rigidly defined
areas of doubt and uncertainty.  I'm not sure that a fuzzy tag
will resolve that problem.  The precise boundary of a wetland
doesn't matter too much and a few tens of metres either way
isn't a problem; when it comes to "The Alps" that is a different
matter.  Simply tagging an area as fuzzy doesn't mean another
mapper won't disagree with your polygon and edit it.

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.


The problem is the edit wars that may arise.  Not a technical issue but 
a

behavioural one.

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.


And there is the deeper problem.  People will do it 

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

[Paul Allen]

On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano 
wrote:

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

I assume that there is a technical limitation on the number of nodes in
such a
polygon.  A limitation that may apply to any or all of editors, database
tables
and renderers.  There may be some technical workarounds, there may not be.


> "Whether we want fuzzy areas"
>

To an extent, everything we map is fuzzy, in that there is always
imprecision.
Aerial imagery may be offset.  Roads may pass through woods giving little or
no visual indication.  GPS traces have errors and require many traces to
achieve good precision.  Everything we map is fuzzy in the sense that it
is imprecise but we live with that and understand that the map is an
approximation that we may be able to improve upon at a subsequent date.

The dislike of fuzziness here appears to centre around verifiability.
We don't want edit wars over the extent of a boundary for which
no definitive answer can ever be given.  We want rigidly defined
areas of doubt and uncertainty.  I'm not sure that a fuzzy tag
will resolve that problem.  The precise boundary of a wetland
doesn't matter too much and a few tens of metres either way
isn't a problem; when it comes to "The Alps" that is a different
matter.  Simply tagging an area as fuzzy doesn't mean another
mapper won't disagree with your polygon and edit it.


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

The problem is the edit wars that may arise.  Not a technical issue but a
behavioural one.


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

And there is the deeper problem.  People will do it anyway.  And possibly
have
their additions reverted by the DWG.  Repeatedly.  In the short term, that
may
work.  In the longer term, "any tag you want" may win.  You can't turn back
the tide but, with barriers you can divert it.

If we don't have fuzzy areas, people will abuse place=locality and other
tags to get labels rendered.  If we do have fuzzy areas then renderers
can calculate label placement, label size, and which zoom levels the
label appears at.  Fuzzy areas also mean we have meaningful tagging
rather than abused tagging, which makes searching for such areas
simpler.

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

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

[Tomas Straupis]

2020-12-21, pr, 17:47 Brian M. Sperlongano rašė:
> 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.

  The question is not about their attributes (tags), but rather their geometry.
  All objects currently held in OSM are of large scale.
  Fuzzy areas are by definition objects of a much smaller scale.
  Having objects of different scale in the same layer (in the same
database in OSM case) is not good (causes a lot of problems) from GIS
perspective.

  So it is not good even if we do not add metaphysical properties like
"verifiability".

P.S. Third attempt: separate database? Or internal/technical separator
field and filter on API level? With possibility to switch between the
two in JOSM (and no possibility to edit both at the same time or reuse
parts)? wink wink :-D

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

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

[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] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen]

On Mon, 21 Dec 2020 at 15:25, Volker Schmidt  wrote:

> Thanks for the pointer, but It does not help. I'm an iD occasional basic
> user only.
>

Ah.  I thought one of your main gripes was the iD was warning you about
stuff
you weren't editing.

I am talking about the behaviour of JOSM.
>

I'm in the reverse position to you: I use JOSM occasionally, mainly for
splitting areas (there are large woods around here with named portions
that have been mapped as one big wood) which iD doesn't appear to
have any way of doing.

Maybe I am also JOSM ignorant regarding its functionalities.
>

If it isn't built-in functionality then there's probably a module to
do what you want.  And if there isn't a module, I expect one could
be written.

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Volker Schmidt]

Thanks for the pointer, but It does not help. I'm an iD occasional basic
user only.
I am talking about the behaviour of JOSM.
Maybe I am also JOSM ignorant regarding its functionalities.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 21 Dec 2020 at 14:56, Paul Allen via Tagging <
tagging@openstreetmap.org> wrote:

> On Mon, 21 Dec 2020 at 09:02, Volker Schmidt  wrote:
>
>>
>> That we will have to live with two tags, or more,  for the same thing is
>> nothing new, what I don't like is to be pestered continuously to do things
>> to objects that happen to be in my downloaded area, and which I had no
>> intention even to look at.
>>
>
> If you open iD's issue inspector you have the choice of "My edits" or
> "Everything."  You also have the choice of "In view" or "Everywhere."  Does
> that help?
>
> --
> 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 - addr:interpolation on closed ways and nodes

[Sarah Hoffmann]

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 16:52 Anders Torger rašė:
> But what to do if the things you want doesn't
> really fit into what OSM currently is and strives to be...

  We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
  YOU define what OSM is and where it is going to by DOING.
  The more I look at it, the more it seems that fragmentation is
inevitable. Question is how much will remain "common".

"Don't let the bastards grind you down" - U2 :-)

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Good points.

I think Norway and Sweden is quite well-known for good maps for hikers 
in the mountains (at least we think so ourselves :-) ), but indeed those 
do not require as quick updates as there's not much changing out there 
and so far no craftbeer on the top of Kebnekaise mountain. But maybe its 
coming... :-). I have no doubt though that if we could make a good 
baseline outdoor map which works as a drop-in replacement for the 
government maps, we could get more contributions that surpass what 
official sources can provide, such as various climbing routes. That's my 
dream, and one reason I started to map national parks. However if the 
base map lacks important base features, eg names in the nature or proper 
generalization, the map is considered less relevant for these areas and 
people won't contribute in the same way.


I also agree with your other points, but it does boil down to that I 
need to do a lot of work :-O. On the other hand it's much easier to get 
things done when you have a small community that can agree on the goals, 
than most energy being spent on trying to convince each-other if a goal 
is even worthwhile to pursue or not, and making people upset in the 
process, which I myself have been guilty of. It's energy-draining for 
all of us.


I've seen the large fragmentation in OSM, all those small private 
projects here and there, as a problem. Not the projects as such, those 
are great, many great and interesting ideas, but most seem disconnected 
from the main community and as such few make it back into mainline, but 
instead goes unmaintained and eventually peters out when the authors 
move on to other projects. But what to do if the things you want doesn't 
really fit into what OSM currently is and strives to be... I'll think 
about it over Christmas. I've invested way more time in OSM during the 
fall than I initially planned to. Mapping is dangerous, it's easy to get 
hooked ;-).


/Anders

On 2020-12-21 15:09, Tomas Straupis wrote:

2020-12-21, pr, 15:54 Anders Torger rašė:

A local renderer would be limited in use <...>


  Not necessarily ;-)
  1. It could be a practical/visual proof of a "better way".
  2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problems.
  3. If enough local communities create cartographic data schemas,
they could technically align them (tagging-cartographic maillist?) and
then data consumers would have to adopt to that as well.
  4. I'm not aware of the outdoors map specifics in Sweden, but at
least here OSM maps update much faster and also include
specific/thematic information for tourism, cayaking, craftbeer,
history and all other good things which official sources do not have.
And having all of that in one database (rather than an overlay) has
some important benefits.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 15:54 Anders Torger rašė:
> A local renderer would be limited in use <...>

  Not necessarily ;-)
  1. It could be a practical/visual proof of a "better way".
  2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problems.
  3. If enough local communities create cartographic data schemas,
they could technically align them (tagging-cartographic maillist?) and
then data consumers would have to adopt to that as well.
  4. I'm not aware of the outdoors map specifics in Sweden, but at
least here OSM maps update much faster and also include
specific/thematic information for tourism, cayaking, craftbeer,
history and all other good things which official sources do not have.
And having all of that in one database (rather than an overlay) has
some important benefits.

-- 
Tomas

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks Tomas, much appreciated.

I guess you are right, but if local country cartography is the only way, 
that lowers motivation to contribute a lot here locally. We have great 
local maps already. To me the attraction of providing to OSM is that the 
data gets broadly available in any end product that uses OSM data. So 
any mobile app using OSM maps suddenly gets much better maps here 
locally, even if the app was made for the US market in the first place.


A local renderer would be limited in use, and then I could use just our 
local government maps directly. Which I indeed have done for some 
projects local to Swedish users.


(Thanks for the fuzzy area PS too. Maybe external database is the way to 
go, I see many say that. But that is of little use if it's not getting 
used by standard renderers, and it seems like we maybe aren't into 
making rural/outdoor maps at all)


/Anders

On 2020-12-21 14:38, Tomas Straupis wrote:

2020-12-21, pr, 14:42 Anders Torger rašė:

I personally want to see that the community work for a more defined
mapping baseline with OSM-Carto as a strong reference, used as a
motivational tool for crowd-sourcing, and as it is with the current
provider landscape -- also work as an end product. It does in parts
already, and I want to see more of that. I also got a sense of 
urgency,

map density in OSM has improved a lot, data sources that a mapper has
access too has also improved a lot since OSM started, so mappers can
today map much more than they could before and are more motivated to 
do

so, at least in some places in the world. I want the OSM technical
platform to be ready for that.


  In OSM for natural reasons cartographers are a small minority
comparing to majority of coders. Therefore cartographic goals do not
get through a "coder filter" (it is more important for majority to
have clean code than to have clean map).
  You might try, but in my experience the only way is to:
  * have a more cartographic agreement with local community (it is
easier in small scale, as you can meet in person, show good examples
and thus prove the value of cartography)
  * have your own country renderer (you can start with VPS for ~100EUR
a year and go up as your usage grows).
  * have your own country editor with your regional tagging schema (I
will publish instructions on how to do that in a month or two)
  * do most of the work yourself (or with a small group of cartography
oriented people) at least initially as resistance will be there anyway
until you prove/show results
  You will have cartographic maps and will not have to waste time
agreeing on cartographic nuances with people who do not understand
cartography. You will simply agree about them LOCALLY and use them
(OSM has a rule of "free tagging").

P.S. Frederik is right about fuzzy features, even in cartographic
perspective they do not belong in the same bucket as current OSM
features. I think you should have a separate database for those. It is
not hard to implement that as amount of data/changes is much lower.
They later end up in the same database in similar GIS tables as main
OSM data therefore are seamless to use in final products.


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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen via Tagging]

On Mon, 21 Dec 2020 at 09:02, Volker Schmidt  wrote:

>
> That we will have to live with two tags, or more,  for the same thing is
> nothing new, what I don't like is to be pestered continuously to do things
> to objects that happen to be in my downloaded area, and which I had no
> intention even to look at.
>

If you open iD's issue inspector you have the choice of "My edits" or
"Everything."  You also have the choice of "In view" or "Everywhere."  Does
that help?

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

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

[Anders Torger]

I forgot to comment this. Just want to make sure that there is no 
misunderstanding: this is not primarily about labeling the Alps or the 
Atlantic or the Sahara desert.


It's mainly about making rural and outdoor maps useful for a local 
context. Maps that hikers, mountaineers and hunters use when moving 
about in nature away from roads and residential areas.


OSM can indeed continue to make huge progress in urban areas and car 
navigation etc without ever caring about making outdoor maps. And if 
that is what we want, that's fine. But if we actually do want the OSM 
data to *also* be used as a basis for outdoor maps away from the streets 
(and not just for an illustrative purpose, but for real use), we are 
crippling it by not having methods to map these names in a proper way. 
For outdoor and rural areas being able to work in an overview manner is 
also more important, as areas are huge, wide space between features, 
which makes simple point mapping place=locality style not work well.


But it all boils down to, do we want to support these type of maps or 
not.


/Anders

On 2020-12-21 13:57, Frederik Ramm wrote:
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.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 14:42 Anders Torger rašė:
> I personally want to see that the community work for a more defined
> mapping baseline with OSM-Carto as a strong reference, used as a
> motivational tool for crowd-sourcing, and as it is with the current
> provider landscape -- also work as an end product. It does in parts
> already, and I want to see more of that. I also got a sense of urgency,
> map density in OSM has improved a lot, data sources that a mapper has
> access too has also improved a lot since OSM started, so mappers can
> today map much more than they could before and are more motivated to do
> so, at least in some places in the world. I want the OSM technical
> platform to be ready for that.

  In OSM for natural reasons cartographers are a small minority
comparing to majority of coders. Therefore cartographic goals do not
get through a "coder filter" (it is more important for majority to
have clean code than to have clean map).
  You might try, but in my experience the only way is to:
  * have a more cartographic agreement with local community (it is
easier in small scale, as you can meet in person, show good examples
and thus prove the value of cartography)
  * have your own country renderer (you can start with VPS for ~100EUR
a year and go up as your usage grows).
  * have your own country editor with your regional tagging schema (I
will publish instructions on how to do that in a month or two)
  * do most of the work yourself (or with a small group of cartography
oriented people) at least initially as resistance will be there anyway
until you prove/show results
  You will have cartographic maps and will not have to waste time
agreeing on cartographic nuances with people who do not understand
cartography. You will simply agree about them LOCALLY and use them
(OSM has a rule of "free tagging").

P.S. Frederik is right about fuzzy features, even in cartographic
perspective they do not belong in the same bucket as current OSM
features. I think you should have a separate database for those. It is
not hard to implement that as amount of data/changes is much lower.
They later end up in the same database in similar GIS tables as main
OSM data therefore are seamless to use in final products.

-- 
Tomas

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

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

[ipswichmapper--- via Tagging]

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.

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

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

[Anders Torger]

Thanks Frederik,

if I interpret your answer correctly it is that we should not map these 
names at all (at least not within the scope of OSM database and 
OSM-Carto rendering), is that correct?


As a mapper I would like to know what the strategy is so I don't waste 
my effort on dead ends.


A technical comment: I don't see a need for wavy polygons or something 
fancy like that. Just regular polygons. They are by definition fuzzy, 
the polygon borders aren't supposed to be rendered, it's just a guide 
for renderers to know where to place text label. I see no need for a new 
datatype, I think the database is ready for fuzzy areas today, and is 
already being used (bays and straits).


However, it becomes more and more clear that the leading profiles in the 
OSM community actually doesn't care *that* much about rural/outdoor 
map-making, or at least that the current view of what the data model 
should be is more important. I certainly don't mean this is a derogatory 
manner, it's perfectly fine to have that view. However, I on the other 
hand care very much about rural and outdoor map-making and desire that 
be an important end use for the OSM data I contribute, and I get a bit 
confused. I get thrown between hope and despair regarding the general 
community's view on this. A clearly stated strategy would be nice. 
Without that I get I like "maybe if I come up with a better idea to 
store these names they'll like it", but if we don't want them in the 
first place, I'd appreciate if we just say so.


I know lettering across the alps and other huge areas is a favorite 
example, but in my context it's much more about the small ones. In rural 
areas we have about 5-10 of these types of names per 10x10 km square. 
Not mapping those make rural maps and outdoor maps a lot less useful 
than they could be. These names are used all the time by outdoor people. 
Not having them in large disqualifies OSM to be used for outdoor map end 
products, but if that is what the community wants I'm certainly ready to 
accept that. There's no use to map areas which we never intend to make 
useful maps for, so then I'll just skip those. There are still other 
areas to map.


/Anders

On 2020-12-21 13:57, Frederik Ramm wrote:

Hi,

On 21.12.20 10:20, Anders Torger wrote:

In the mountains we have an number of named plateaus. There is a tag
proposal for natural=plateau, but just like with natural=peninsula and
similar tags there is an underlying question that we really need an
answer to first: should we have fuzzy areas or should we not?


I think I have laid out my point in
https://lists.openstreetmap.org/pipermail/tagging/2020-December/056823.html

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.

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.


We know there are disadvantages and no solution is 100%
perfect, but sometimes there's a higher goal to fulfill.


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.

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.

Bye
Frederik


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

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Mateusz Konieczny via Tagging]

Dec 20, 2020, 23:29 by graemefi...@gmail.com:

> On Sun, 20 Dec 2020 at 17:55, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>> How objects tagged now with amenity=lifeboat_station should be tagged after 
>> this proposal passes?
>>
>
> They were a late addition after somebody pointed out that they exist. They 
> would be replaced by emergency=marine_rescue, which has already been defined 
> as groups " dedicated to the rescue of vessels &/or sailors at sea"
>
The problem is that some water rescue stations are not marine but inland.

>>
>> Also "The area of the Rescue base should render with the same pink colour as 
>> currently used for
>> Police & Fire Stations, together with an "SOS" icon." is problematic as 
>> proposal process has no
>> power to select any rendering in any map style.
>>
>
> Yes, but all proposals suggest a rendering scheme.
>
Suggesting rendering is OK. But "should render with the same pink colour as 
currently used for"
reads like instruction that render is supposed to follow - while it is not 
working this way.

Also, not all of them 
(see for example 
https://wiki.openstreetmap.org/wiki/Proposed_features/carpet_hanger
where I skipped this section) 

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

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

[Frederik Ramm]

Hi,

On 21.12.20 10:20, Anders Torger wrote:
> In the mountains we have an number of named plateaus. There is a tag
> proposal for natural=plateau, but just like with natural=peninsula and
> similar tags there is an underlying question that we really need an
> answer to first: should we have fuzzy areas or should we not?

I think I have laid out my point in
https://lists.openstreetmap.org/pipermail/tagging/2020-December/056823.html

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.

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.

> We know there are disadvantages and no solution is 100%
> perfect, but sometimes there's a higher goal to fulfill.

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.

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.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

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

[Mateusz Konieczny via Tagging]

Dec 21, 2020, 13:01 by dieterdre...@gmail.com:

> Am Mo., 21. Dez. 2020 um 08:40 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>>
>> Mapping military bases in Israel, Russia, mapping anything in China/North 
>> Korea
>> etc should be welcomed in OSM if someone is doing this and wants that.
>>
>
>
>
> Mateusz, this is a quite detailed list, can you explain which other countries 
> are included in "etc"? I do not know about Israel, Russia or North Korea, but 
> I am pretty sure that mapping in China is illegal.
>
Yes, mapping China without explicit permission breaks Chinese law.
But it is not against OSM rules to be within Chinese jurisdiction and map China.

The same for mapping military bases in Russia or Israel.

'can you explain which other countries are included in "etc"' - I heard about 
other countries
that have similar laws but I have not verified this claims.

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

(Sorry if I missed a private message. I have a generic filter that 
throws all emails that match tagging in some way to one mailbox and 
sometimes I miss things.)


Anyway, I'm talking about globally distributed open source projects, 
where you communicate in text over email and forums. Not a workplace. 
It's very different ways of communicating, and it always looks harsher 
than it is. You probably have a whole different view of me than you 
would have if we met in person. But point is taken, and I have noted 
that discussions go south here a lot quicker than I'm used to, and 
indeed that's ineffective. I'll try to provide a softer tone, because 
what I want really want is solutions to the issues.


I guess one issue with my appearances here is that in my humble opinion 
many things in OSM are problematic, mostly a result of that it has 
piecewise evolved rather than it has had a solid design leadership, and 
it's got some growing pains. I've hidden that view poorly mainly because 
many issues I run into I think would have been non-issues if it has been 
more of a top-down design for a baseline feature set focusing on actual 
end uses. I now understand that this view is very provocative though, so 
I'll try to tone it down.


I personally want to see that the community work for a more defined 
mapping baseline with OSM-Carto as a strong reference, used as a 
motivational tool for crowd-sourcing, and as it is with the current 
provider landscape -- also work as an end product. It does in parts 
already, and I want to see more of that. I also got a sense of urgency, 
map density in OSM has improved a lot, data sources that a mapper has 
access too has also improved a lot since OSM started, so mappers can 
today map much more than they could before and are more motivated to do 
so, at least in some places in the world. I want the OSM technical 
platform to be ready for that.


/Anders

On 2020-12-21 11:55, stevea wrote:

On Dec 21, 2020, at 2:10 AM, Anders Torger  wrote:
I'm sorry if you experience it as that. Maybe I'm a bit too 
confrontational, and maybe I should express myself with a softer tone, 
I guess my style has become a bit shaped by to how we communicate 
engineer to engineer in programming projects.


Anders, I’ve been an employee at Apple, Adobe and many startups (in
Silicon Valley and my university city nearby on the coast), as an
engineer, to other engineers.  I have been a team leader, a manager
and a director — on dozens of programming projects.  I DON’T “guess”
at your style and if you worked with me I’d give you as stern a
talking to behind a closed door, just the two of us.  That’s not as I
do here on-list, precisely because YOU chose the more public venue,
but also because you don’t answer my polite, private email.


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

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

[Martin Koppenhoefer]

Am Mo., 21. Dez. 2020 um 08:40 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Mapping military bases in Israel, Russia, mapping anything in China/North
> Korea
> etc should be welcomed in OSM if someone is doing this and wants that.
>



Mateusz, this is a quite detailed list, can you explain which other
countries are included in "etc"? I do not know about Israel, Russia or
North Korea, but I am pretty sure that mapping in China is illegal.

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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 21, 2020, at 2:10 AM, Anders Torger  wrote:
> I'm sorry if you experience it as that. Maybe I'm a bit too confrontational, 
> and maybe I should express myself with a softer tone, I guess my style has 
> become a bit shaped by to how we communicate engineer to engineer in 
> programming projects.

Anders, I’ve been an employee at Apple, Adobe and many startups (in Silicon 
Valley and my university city nearby on the coast), as an engineer, to other 
engineers.  I have been a team leader, a manager and a director — on dozens of 
programming projects.  I DON’T “guess” at your style and if you worked with me 
I’d give you as stern a talking to behind a closed door, just the two of us.  
That’s not as I do here on-list, precisely because YOU chose the more public 
venue, but also because you don’t answer my polite, private email.

> That is the jargon can be quite "hard" with many strong opinions clashing, 
> but it's nothing personal.

Your jargon isn’t what I experience in professional software engineering 
settings, it is what I hear from smart-aleck, spoiled children or teenagers.  I 
don’t take it personally, that’s a mistake on your part.  I find it wholly 
ineffective.  Because it is.

> I've seen others in this list use the same "tough" way to voice their 
> opinions so I thought it was okay. As long as one focus on the merits of the 
> arguments, have an open mind to change opinion, is open to solutions one 
> didn't think about, and don't go personal it usually works well.

While on occasion here, I have seen a certain swagger and displays of, let’s 
say, “attitude,” I haven’t seen the constant, aggressive, highly negative 
“toughness” that you bring.  It is relentless.  What others do is ask 
questions.  By contrast, what you do is complain and say what is wrong with how 
we already do things.  We’ve gotten a lot done and have much to do yet, but we 
partly do that with dialog, not by giving cookies to children.

> I can try go softer in jargon, but it won't change the fact that the reason I 
> get on this list is when things either don't work or I don't find an answer 
> to some question. So it will be "complaints" in some way or another. I think 
> I do provide some solutions too though, although some may not be easy to 
> realize or is not likable by everyone.

The problem isn’t jargon.  I understand jargon, the list understands jargon.  
(And if or when we don’t we ask for clarification, usually getting it.  That’s 
part of how good dialog works).  The problem is that your complaints to this 
list are nearly completely lacking in “good questions” that any of us can field 
(or, given your poor attitude, really want to).  They are as I have described 
them.  Only very rarely are they well-posed questions.  Please endeavor to 
remedy that and I virtually guarantee that you will find people who reply with 
thoughtful answers, or at the very least helpful direction.  But plain and 
simple, nobody likes a complainer.

> That there are many "complaints" coming from me now is because I currently 
> map *a lot* and mainly nature (which wasn't an original goal for OSM but 
> something that has come later, so it's understandable that there are issues)

Please be careful about assumptions that you make and how they affect you:  
this is part of what is ineffective with your interactions with this list.  OSM 
doesn’t need you to make excuses (like that you or anybody “understands that 
“there are issues”).

> and therefore come across many issues which have no clear answers.

To you, now, when you haven’t clearly and politely asked your question.  Try 
this:  before posting your “issues,” distill them down to one or two 
well-crafted questions that someone on this list MIGHT be able to answer 
succinctly.  Before you actually write it, consider some possible answers.  
Ask:  might it be X, is Y even possible, does Z seem like a feasible direction 
to explore if this has never been done in OSM before?  Like that.  It works!

> This is a list for tag discussion, strategy and related tools. Issues bubble 
> up to here. If I had a clear answer I wouldn't even need to post, and there 
> are many of those too (ie where I've found working solutions on the wiki or 
> through OSM help).

I understand how that works, you are correct.  This IS a (good) place to turn 
when the wiki or other sources do not satisfy your craving to know how to do 
something in OSM.  It is HOW one does that questioning here that (partly) 
determines how likely you are to get an answer.  Well-crafted, judgement-free, 
lacking-in-assumptions questions do well.  Non-questions that are judgmental 
and assume (a little, a lot) do poorly, as you have discovered.

> The reason I don't have a clear answer is that there is several issues with 
> the current approaches, which I described in my post.

You can describe these “issues” in the course of the dialog with someone who 
engages you here if and as they actually provide a blockade to 

[Tagging] Feature proposal - Voting - guard stone

[Anne-Karoline Distel]

Hi,

there haven't been any comments on it in a while, so I think it is safe
to start the voting process on

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

Voting ends on January 4th.

Thanks to everyone who contributed to the discussion and proposal page!

Happy holidays,

Anne (b-unicycling)


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

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

[Anders Torger]

Yeah I know of that github project and I'm thinking of that an approach 
of having small fuzzy areas in the main database, and huge ones in a 
separate might be the way to go.


One reason to have big names separate and not the small ones could be 
that the big names will be "completely" mapped almost right away and 
don't require crowd sourcing. However the small ones, as an example we 
have say 5-10 of these names per 10x10km square in Sweden, do require 
crowd sourcing from regular mappers.


But then I ask myself, if we can have the small ones, why not have all, 
also the big ones, in OSM? We have already big scale information in the 
database. The clutter thing I think is just a tool issue which is 
already solved in JOSM (filters) and can be easily solved in iD.


Or we could go the opposite way and move all fuzzy areas to an external 
database, also the small local ones. It's sort of a conceptual way to 
create it as a separate layer. I'm not against that from a technical 
perspective, but I'm worried if this data is not included in the main 
OSM database it's a big risk that it won't be available and won't be 
used by OSM-Carto and then mappers won't be motivated to contribute so 
we won't get the necessary crowd sourcing going.


(I've heard that some think fuzzy areas is "mapping for the renderer" 
and that's the reason we don't really move forward on this issue. 
Unfortunately I don't remember the exact reasoning behind why it would 
be mapping for the renderer so I can't recreate that argument here, but 
I guess someone can fill that in. From my perspective I think fuzzy 
areas is the exacty opposite to mapping for the renderer, as the mapper 
just give information of name and rough size of an actual fuzzy area, 
and makes no decision on label placement or size. Sure one can misuse it 
and say make a fuzzy area much larger than it should be to make the 
renderer draw a large text just for the sake of it, but that's just 
regular misuse and something we need to relate to for all OSM tags and 
features.)


/Anders

On 2020-12-21 11:03, Janko Mihelić wrote:


The fifth alternative is move the big areas to an outside repository:
https://github.com/dieterdreist/OpenGeographyRegions

This might be a great alternative until we find a better solution. And 
there might not be a better solution.


Janko

pon, 21. pro 2020. u 10:22 Anders Torger  napisao je:


Next question.

In the mountains we have an number of named plateaus. There is a tag
proposal for natural=plateau, but just like with natural=peninsula and
similar tags there is an underlying question that we really need an
answer to first: should we have fuzzy areas or should we not?

Plateau, peninsula etc are naturally mapped like an additional low
detail fuzzy area polygon on top of other land covers. My opinion has
been made clear in other threads: I think fuzzy areas on top is an
elegant solution for naming nature and something we should have. I 
think

the cluttering issue can be solved with filters, but as these will be
used in low numbers to start with I think cluttering will not be an
issue for some time to come so it's something we could look into 
later.

In any case that's a tool issue, not a database issue.

If we don't want fuzzy areas, an other alternative is to have these as
named points, (previously often made as "place=locality"). I think 
that

is okay too, but then we need size classification on them like we have
on residental isolated dwelling/hamlet/village etc so the renderer 
have
enough information to know how large to make texts and which zoom 
level

to show them. Having the same level for all names doesn't work.

Fuzzy areas has the advantage of solving the text size automatically
(not a mapper decision), and gives freedom to the renderer to place 
(and
even shape) the text. Fuzzy areas also scale well up to huge sizes 
(like
the Sahara desert) if we want that as well, which point text doesn't 
in
the same way. We could decide to have fuzzy areas over a certain size 
in

an external database too. I'm not super-stoked over the external
database method though, as I think then it risks becoming like
elevation/contours is today, ie not generally available and with 
varied

quality.

A disadvantage is that fuzzy areas have limits in verifiability and it
arguably requires more knowledge/judgment from the mapper than roughly
placing a point. On the other hand, optimal point placement also have
cartography and verifiability issues. The underlaying issue here is of
course that these type of names have never have defined borders and
never will, but I think we cannot continue to pretend that they aren't
relevant for a database mainly used to generate maps. We need to
represent them in some way.

A third alternative is not having names of this type at all. While I
just said that it's not the way to go, if someone still has that as a
clear opinion please make that clear rather than just point at
disadvantages of every suggested 

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks, good points and information.

Indeed, the fell tag seems to be a bit misused. I would guess it could 
be because there are things actually named "Fell" there, and then 
inexperienced mappers may use the Fell tag as that seems appropriate. 
Incorrect use can be cleaned up in time though (fell is not used *a lot* 
so it's not like fixing place=locality uses...), and I think it 
shouldn't stop a useful tag. But sure we could perhaps make a new one, 
or a new tag combination if that is better.


I have myself looked at the fell definition here:

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell

And interestingly enough the "examples" photographs are from areas I'm 
actually currently mapping(!) so I thought if it was meant to be used at 
all, this is the place :-). It also matches up how maps are 
traditionally made here, so very good for the local community. We don't 
call these areas "fell" in our local language, but rather what would be 
translated to "bare mountain" (ie mountain above tree line), but the 
actual name of the tag isn't what matters, it's the definition. And the 
current wiki page clearly points at the use I'm looking for.


Although the bare rock/scree altitude is quite clear and I'll probably 
map it as that in time, I'm afraid that if I map the mid altitude bare 
mountain with "heath" instead of fell, the heath definition will be a 
bit watered out due to the speckled and diffuse character of this 
nature. So I think it would be better with a specific tag that embraces 
this property of the land.


/Anders

On 2020-12-21 10:34, Andy Townsend wrote:

On 21/12/2020 07:39, Anders Torger wrote:

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. ...


This isn't really anything to do with tagging, but I can understand
why some renderers decide not to render it.

Usage, at least where am I, is hugely problematic:
http://overpass-turbo.eu/s/11nH .

Usage in the Pennines northwest of Leeds is almost exclusively just a
bunch of names that have been copied from old out-of-copyright NPE
maps.  The features may be peaks, or patches of moorland, or something
else again.  If a renderer was to do something with them, it'd
probably be as "place=locality".

Further west examples like https://www.openstreetmap.org/way/412325588
correspond better to the wiki definition.  In that example other
landuse (woodland, heath) is also mapped.

There are also some surprising uses in place of other tags - on
https://www.openstreetmap.org/way/368051383 it surely means
"trail_visibility"!

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] natural=fell not rendered, alternatives?

[Anders Torger]

Steve,

I'm sorry if you experience it as that. Maybe I'm a bit too 
confrontational, and maybe I should express myself with a softer tone, I 
guess my style has become a bit shaped by to how we communicate engineer 
to engineer in programming projects. That is the jargon can be quite 
"hard" with many strong opinions clashing, but it's nothing personal. 
I've seen others in this list use the same "tough" way to voice their 
opinions so I thought it was okay. As long as one focus on the merits of 
the arguments, have an open mind to change opinion, is open to solutions 
one didn't think about, and don't go personal it usually works well.


I can try go softer in jargon, but it won't change the fact that the 
reason I get on this list is when things either don't work or I don't 
find an answer to some question. So it will be "complaints" in some way 
or another. I think I do provide some solutions too though, although 
some may not be easy to realize or is not likable by everyone.


That there are many "complaints" coming from me now is because I 
currently map *a lot* and mainly nature (which wasn't an original goal 
for OSM but something that has come later, so it's understandable that 
there are issues) and therefore come across many issues which have no 
clear answers. This is a list for tag discussion, strategy and related 
tools. Issues bubble up to here. If I had a clear answer I wouldn't even 
need to post, and there are many of those too (ie where I've found 
working solutions on the wiki or through OSM help). The reason I don't 
have a clear answer is that there is several issues with the current 
approaches, which I described in my post.


If OSM intends to be for all globally, there is a need to consider local 
needs and respect local knowledge, not only consider a feature relevant 
if it is has global spread. Maybe these natural=fell issues are specific 
to Scandinavia (although I think Great Britian has similar), but they 
are real here.


I try to make a case that it would be wise to render natural=fell, and 
describe why. There's a closed issue report on OSM-Carto github about 
this (yes I actually do some research before I post), and my arguments 
were shaped by that thread, to proactively meet what came up there so we 
don't need to have exactly the same discussion all over again.


However, that I have a suggested solution doesn't mean that I'm open to 
other suggestions, maybe an alpine tag for indicating nature above tree 
line for example. I think it's however very difficult and not worthwhile 
to go very specific for our fell habitat, which I also described in the 
original post.


Heath below the tree line is quite easy to identify, as it's surrounded 
by forest. Heath above the tree line is pretty chaotic, speckled with 
bare rock and scree. Hence a generic tag "fell" would suit perfectly 
well, and is already in existence, but it needs rendering in OSM-Carto 
to show mappers that there is backing for this tag.


/Anders

On 2020-12-21 10:12, stevea wrote:

On Dec 20, 2020, at 11:39 PM, Anders Torger  wrote:
I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. I don't think that (somewhat 
randomly) requiring detailed landcover is a good design choice.


Can Anders write anything here without telling OSM that it is broken
and we don't know what we are doing?

Anders, where did you study cartography or get an advanced degree in
design?  Ignoring the question speaks volumes.

I think it would be better to have a defined hierarchy from more 
generic to more specific tags so the map can evolve.


Thank you for your opinion.

Taking the leap to high detail mapping directly makes covering the map 
very slow and sometimes inaccurate.


Maybe.  Again, only maybe.  If you don't like OSM, you are welcome to
not use it.

Fell in particular is in parts so heavily speckled with slightly 
different covers it's hard to even see on the satellite photo what it 
is.


Complain, complain, complain.

You can have say 30% bare rock, 20% scree and 40% heath and 10% 
wetland in an area. So I guess I make that heath then as it's 
dominant? That would however be more misleading than actually setting 
a more generic tag like natural=fell. Forcing detailed mapping where 
this is very difficult to do is not a good idea.


Bleating, bleeeating to this list with little to no
constructive bent to your complaints is not a good idea.

When we get to even higher altitude the growth disappear and we have 
just bare rock and scree so it becomes easier. It can at times be 
quite hard to differ between bare rock or scree though (the resolution 
of the satellite photos in the mountains is often not that great).


I'm beyond thinking that this barrage of "my preferences are the best"
is not that great:  I'm 

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

[Janko Mihelić]

The fifth alternative is move the big areas to an outside repository:
https://github.com/dieterdreist/OpenGeographyRegions

This might be a great alternative until we find a better solution. And
there might not be a better solution.

Janko

pon, 21. pro 2020. u 10:22 Anders Torger  napisao je:

> Next question.
>
> In the mountains we have an number of named plateaus. There is a tag
> proposal for natural=plateau, but just like with natural=peninsula and
> similar tags there is an underlying question that we really need an
> answer to first: should we have fuzzy areas or should we not?
>
> Plateau, peninsula etc are naturally mapped like an additional low
> detail fuzzy area polygon on top of other land covers. My opinion has
> been made clear in other threads: I think fuzzy areas on top is an
> elegant solution for naming nature and something we should have. I think
> the cluttering issue can be solved with filters, but as these will be
> used in low numbers to start with I think cluttering will not be an
> issue for some time to come so it's something we could look into later.
> In any case that's a tool issue, not a database issue.
>
> If we don't want fuzzy areas, an other alternative is to have these as
> named points, (previously often made as "place=locality"). I think that
> is okay too, but then we need size classification on them like we have
> on residental isolated dwelling/hamlet/village etc so the renderer have
> enough information to know how large to make texts and which zoom level
> to show them. Having the same level for all names doesn't work.
>
> Fuzzy areas has the advantage of solving the text size automatically
> (not a mapper decision), and gives freedom to the renderer to place (and
> even shape) the text. Fuzzy areas also scale well up to huge sizes (like
> the Sahara desert) if we want that as well, which point text doesn't in
> the same way. We could decide to have fuzzy areas over a certain size in
> an external database too. I'm not super-stoked over the external
> database method though, as I think then it risks becoming like
> elevation/contours is today, ie not generally available and with varied
> quality.
>
> A disadvantage is that fuzzy areas have limits in verifiability and it
> arguably requires more knowledge/judgment from the mapper than roughly
> placing a point. On the other hand, optimal point placement also have
> cartography and verifiability issues. The underlaying issue here is of
> course that these type of names have never have defined borders and
> never will, but I think we cannot continue to pretend that they aren't
> relevant for a database mainly used to generate maps. We need to
> represent them in some way.
>
> A third alternative is not having names of this type at all. While I
> just said that it's not the way to go, if someone still has that as a
> clear opinion please make that clear rather than just point at
> disadvantages of every suggested solution without coming up with an
> alternative. We know there are disadvantages and no solution is 100%
> perfect, but sometimes there's a higher goal to fulfill.
>
> The fourth and current alternative is leaving the question undecided,
> with some fuzzy areas active (bays and straits), some not rendered
> (peninsula), and passively see how it plays out in the coming years (or
> decades!). It's the simplest alternative, but as a mapper and OSM end
> user I hope we can make some real progress now.
>
> Worth mentioning is also the alternative to make a fuzzy cutout of the
> dominant landcover and name that. I've done quite some forest naming
> that way. However it's quite complicated and time-consuming to make
> these cutouts (complex multipolygon editing), and it only works well
> when the name is actually tied to the landcover as such, eg the name is
> on the forest, not a forest-covered peninsula or plateau. While I think
> it's okay to mix this cutout naming method when it works, and use fuzzy
> areas on top when that is required, I also think a viable option would
> be to name forests with fuzzy areas on top as well, but then we need a
> specific tag (or tag combination) so the renderer knows that it
> shouldn't make landcover rendering for that.
>
> I'd like to at least know where we are headed. I could use a tag which
> is not yet rendered, but it would be nice to know if the information
> will potentially ever be used, or if I'm maybe just wasting my time...
>
> /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] natural=fell not rendered, alternatives?

[Andy Townsend]

On 21/12/2020 07:39, Anders Torger wrote:

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. ...


This isn't really anything to do with tagging, but I can understand why 
some renderers decide not to render it.


Usage, at least where am I, is hugely problematic: 
http://overpass-turbo.eu/s/11nH .


Usage in the Pennines northwest of Leeds is almost exclusively just a 
bunch of names that have been copied from old out-of-copyright NPE 
maps.  The features may be peaks, or patches of moorland, or something 
else again.  If a renderer was to do something with them, it'd probably 
be as "place=locality".


Further west examples like https://www.openstreetmap.org/way/412325588 
correspond better to the wiki definition.  In that example other landuse 
(woodland, heath) is also mapped.


There are also some surprising uses in place of other tags - on 
https://www.openstreetmap.org/way/368051383 it surely means 
"trail_visibility"!


Best Regards,

Andy



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

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

[Anders Torger]

Next question.

In the mountains we have an number of named plateaus. There is a tag 
proposal for natural=plateau, but just like with natural=peninsula and 
similar tags there is an underlying question that we really need an 
answer to first: should we have fuzzy areas or should we not?


Plateau, peninsula etc are naturally mapped like an additional low 
detail fuzzy area polygon on top of other land covers. My opinion has 
been made clear in other threads: I think fuzzy areas on top is an 
elegant solution for naming nature and something we should have. I think 
the cluttering issue can be solved with filters, but as these will be 
used in low numbers to start with I think cluttering will not be an 
issue for some time to come so it's something we could look into later. 
In any case that's a tool issue, not a database issue.


If we don't want fuzzy areas, an other alternative is to have these as 
named points, (previously often made as "place=locality"). I think that 
is okay too, but then we need size classification on them like we have 
on residental isolated dwelling/hamlet/village etc so the renderer have 
enough information to know how large to make texts and which zoom level 
to show them. Having the same level for all names doesn't work.


Fuzzy areas has the advantage of solving the text size automatically 
(not a mapper decision), and gives freedom to the renderer to place (and 
even shape) the text. Fuzzy areas also scale well up to huge sizes (like 
the Sahara desert) if we want that as well, which point text doesn't in 
the same way. We could decide to have fuzzy areas over a certain size in 
an external database too. I'm not super-stoked over the external 
database method though, as I think then it risks becoming like 
elevation/contours is today, ie not generally available and with varied 
quality.


A disadvantage is that fuzzy areas have limits in verifiability and it 
arguably requires more knowledge/judgment from the mapper than roughly 
placing a point. On the other hand, optimal point placement also have 
cartography and verifiability issues. The underlaying issue here is of 
course that these type of names have never have defined borders and 
never will, but I think we cannot continue to pretend that they aren't 
relevant for a database mainly used to generate maps. We need to 
represent them in some way.


A third alternative is not having names of this type at all. While I 
just said that it's not the way to go, if someone still has that as a 
clear opinion please make that clear rather than just point at 
disadvantages of every suggested solution without coming up with an 
alternative. We know there are disadvantages and no solution is 100% 
perfect, but sometimes there's a higher goal to fulfill.


The fourth and current alternative is leaving the question undecided, 
with some fuzzy areas active (bays and straits), some not rendered 
(peninsula), and passively see how it plays out in the coming years (or 
decades!). It's the simplest alternative, but as a mapper and OSM end 
user I hope we can make some real progress now.


Worth mentioning is also the alternative to make a fuzzy cutout of the 
dominant landcover and name that. I've done quite some forest naming 
that way. However it's quite complicated and time-consuming to make 
these cutouts (complex multipolygon editing), and it only works well 
when the name is actually tied to the landcover as such, eg the name is 
on the forest, not a forest-covered peninsula or plateau. While I think 
it's okay to mix this cutout naming method when it works, and use fuzzy 
areas on top when that is required, I also think a viable option would 
be to name forests with fuzzy areas on top as well, but then we need a 
specific tag (or tag combination) so the renderer knows that it 
shouldn't make landcover rendering for that.


I'd like to at least know where we are headed. I could use a tag which 
is not yet rendered, but it would be nice to know if the information 
will potentially ever be used, or if I'm maybe just wasting my time...


/Anders

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Tomas Straupis]

2020-12-21, pr, 11:02 Volker Schmidt rašė:
> Mass deprecations are counter-productive in general and independently of 
> whether they the new tagging is better in some way..

  +1

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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 20, 2020, at 11:39 PM, Anders Torger  wrote:
> I'm doing further mapping of Swedish national parks, now in the mountains, 
> and I have noted that natural=fell (habitat over tree line) is not rendered.
> 
> Looking into why it seems that OSM-Carto implementors want more specific 
> landcover tags to be used. I don't think that (somewhat randomly) requiring 
> detailed landcover is a good design choice.

Can Anders write anything here without telling OSM that it is broken and we 
don't know what we are doing?

Anders, where did you study cartography or get an advanced degree in design?  
Ignoring the question speaks volumes.

> I think it would be better to have a defined hierarchy from more generic to 
> more specific tags so the map can evolve.

Thank you for your opinion.

> Taking the leap to high detail mapping directly makes covering the map very 
> slow and sometimes inaccurate.

Maybe.  Again, only maybe.  If you don't like OSM, you are welcome to not use 
it.

> Fell in particular is in parts so heavily speckled with slightly different 
> covers it's hard to even see on the satellite photo what it is.

Complain, complain, complain.

> You can have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an 
> area. So I guess I make that heath then as it's dominant? That would however 
> be more misleading than actually setting a more generic tag like 
> natural=fell. Forcing detailed mapping where this is very difficult to do is 
> not a good idea.

Bleating, bleeeating to this list with little to no constructive 
bent to your complaints is not a good idea.

> When we get to even higher altitude the growth disappear and we have just 
> bare rock and scree so it becomes easier. It can at times be quite hard to 
> differ between bare rock or scree though (the resolution of the satellite 
> photos in the mountains is often not that great).

I'm beyond thinking that this barrage of "my preferences are the best" is not 
that great:  I'm already there!

> We already have more-generic-to-more-specific landcovers in other areas, you 
> can provide wood without specifying tree type for example, or wetland without 
> specifying type of wetland. (Parenthesis: going from more generic to more 
> specific by adding additional specifying tags is an elegant design, I think 
> it's a bit unfortunate that that design is mixed with a flat tag structure as 
> well, but that's the way it is...).

More than a bit unfortunate are posts by constant complainers.

> It seems like a very odd design choice to require more detailed mapping in 
> alpine areas where this is rather difficult. If we look into how official 
> maps do it in Sweden and Norway they don't have specific landcovers above the 
> tree line, they have just "fell", and in addition significant wetlands, plus 
> waters and streams of course.

It seems like a very odd choice to write to a list with little more than "you 
folks are wrong, why don't you simply do things the way that _I_ want them 
done?"  Even after we (I, others...) politely and patiently engage you, do you 
expect us to keep doing so when it appears you cannot write to this list with 
little more than a litany of complaints?

> Fell indicates where we have bare mountain (above treeline), which is the key 
> information outdoor goers need

Says you.  Others might agree, others disagree, not everybody thinks like you.  
OSM aims to be for all, not just you.

> plus waters and significant wetlands. Anyone that has been to these mountains 
> know that once above the tree line the land cover is quite predictable, it's 
> decided by altitude and steepness.

The reason humans make maps is because nature, the world around us, is always 
changing in some way and is absolutely NOT predictable.  Maps are an 
approximation of reality, not reality.  There is no such thing of value as 
"quite predictable."  The first time something happens that wasn't predicted, 
you'll learn the value of that.

> At the fell altitude contour lines is key information, not if it's a patch of 
> heath or bare rock, which rather just makes a map harder to read without 
> providing valuable information.

I'm pretty sure of one thing:  you are not hard to read.  I see your name in 
the From header and know that I'm about to read someone hostile to OSM who 
can't seem to make even constructive criticism.  It's all rock-throwing, here's 
what's wrong with you and why don't you do things my way?  (Without so much as 
a "please").

> So far I have tagged these areas with natural=fell. I'm thinking about adding 
> bare_rock at high altitude (and scree only when clear and significant), but 
> in the medium altitude where there is growth more detailed mapping becomes 
> very difficult. Heath would be the most natural generic tag for that area, 
> but then we loose the distinction that it's above the tree line, as there 
> already is some heath areas below the tree line. Maybe adding an extra tag 
> like 

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Volker Schmidt]

Yep.
I know that.
But for the tag to be on the deprecated tag list, it has to be deprecated
in the wiki, I presume at least. That is my point. I don't think that JOSM
will flag it deprecated because ID deprecated it, while the wiki still has
it as a valid tag.
That we will have to live with two tags, or more,  for the same thing is
nothing new, what I don't like is to be pestered continuously to do things
to objects that happen to be in my downloaded area, and which I had no
intention even to look at.
Mass deprecations are counter-productive in general and independently of
whether they the new tagging is better in some way..


On Sun, 20 Dec 2020 at 16:59, Paul Allen  wrote:

> On Sun, 20 Dec 2020 at 15:29, Volker Schmidt  wrote:
>
>>
>>
>>
>> In addition, please consider that deprecated features are being flagged
>> by editor sw on
>>
> saving any changeet that contains an deprecated tag, even if it has
>> nothing to do
>>
> with your actual editing, this would be adding another contnued nuisance
>> for mappers
>>
> (there are already others opf that type).
>>
>
>> Please don't do it
>>
>
> Too late, at least for iD.  Its authors have already decided to deprecate
> landuse=reservoir.  All this proposal does is document the fact.
>
> --
> 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