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