[Tagging] Fuzzy areas again: should we have them or not?
Anders Torger
anders at torger.se
Mon Dec 21 10:41:36 UTC 2020
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 <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
>> 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201221/26ac0cd0/attachment-0001.htm>
More information about the Tagging
mailing list