[Tagging] Fuzzy areas again: should we have them or not?
janjko at gmail.com
Mon Dec 21 10:03:39 UTC 2020
The fifth alternative is move the big areas to an outside repository:
This might be a great alternative until we find a better solution. And
there might not be a better solution.
pon, 21. pro 2020. u 10:22 Anders Torger <anders at torger.se> 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
> 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...
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging