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

2020-12-24 Thread stevea
Long, prickly post ahead.

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

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

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

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

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

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

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

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

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

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

2020-12-23 Thread Andy Townsend

Hi all,

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


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



On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm > wrote:


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


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



(snipped discussion)


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


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



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


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





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


I think we need to know whether these comments represent the opinion 
of the DWG, and whether the DWG is signaling to the community that 
they will be taking a heavy-handed approach against mappers that 
invent schemes for or create fuzzy areas through the principle of free 
tagging.



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


Best Regards,

Andy (from the DWG)

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




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


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

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

Bullseye.

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

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

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

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


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

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

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


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


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

2020-12-22 Thread Anders Torger

Thanks Kevin, point taken ;-)

To summarize. This is the way I interpret this situation:

OSM is a geodatabase, with a design that makes some geodata suitable for 
it, others less so. The overall design is not likely to change to accept 
more types of geodata, instead we would rely on extra data sources to 
generate maps which require data that is not suitable for OSM, such as 
elevation data for contour lines and possibly fuzzy areas for names.


If fuzzy areas fit into the current OSM database or not is something we 
in the community don't agree on. Some of us think it does, others don't. 
Some think they are useful to making maps, but still not suitable for 
OSM. Some think they are not really useful or at least not important for 
maps either, they haven't seen a need for them.


It's not only about generating maps, it's also about being able to ask 
the database if location X is located in the Red Sea / Sahara desert / 
other named but fuzzy area, or not and similar questions. If we want OSM 
to be able to cater such queries is really interesting and something 
that haven't been discussed much so far.


It's hard to make constructive discussions on solutions when there is no 
agreement on that there is a problem that needs solving. Here we are 
exactly in that situation, we have not really come to the point to agree 
on a problem to be able to discuss solutions.


My personal OSM-related interest for the time being is in map generation 
especially in rural and "uninhabited" areas, and making mainstream 
OSM-based maps better in those areas. OSM database is however both a 
superset and a subset of the data needed for generating these type of 
maps. While I personally desire that OSM database and its default 
renderer should be developed in a direction to "fill in the gaps" this 
is not a goal of OSM at large. I was naive in the beginning and thought 
that was the case or at least a desire shared by many in the community 
and that the type of map features I need would be seen as mainstream, 
but clearly it is not.


Instead the enduring view is that the type of mapping I look into is 
better suited for OSM combined with extra data sources on the side and a 
custom renderer. Although I rather would see OSM moving towards grasping 
over a larger feature set which includes more of what I believe to be 
quite central to classic cartography and "what should be in any map", I 
stand more alone on that desire than I thought I would. This does not 
mean that there is any specific hostility against cartography, but there 
seems to be quite different views on what features that are important 
and not in maps. In other words many aspects that I thought was 
obviously important is not considered that by many/most OSM 
contributors.


This fuzzy area thing touches exactly on such a subject and is therefore 
quite difficult to discuss.


I think though it's already quite safe to say that there is not enough 
interest to make this a mainstream feature of OSM. It's also safe to say 
that those small scale fuzzy areas already exist in OSM and is 
manifested in various ways, so there are clearly not just I that need 
them in mapping. But I have no idea how we could move from that state.


/Anders

On 2020-12-22 00:16, Kevin Kenny wrote:


Anders has been a bit confrontational___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

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

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

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

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

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

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


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

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

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

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


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

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

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


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


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

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

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

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


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

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread 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] Fuzzy areas again: should we have them or not?

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


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

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