We should probably not have all these possible generalized areas in our
db. Just as we probably shouldn't have a bedrock map in the db either,
at least not until it can manage layers.
But we could simply pick one criteria, document the definition of the
"fuzzy area" and have that. Some criteria that is useful as a basis for
making general-purpose maps. I don't think it's a problem to have fuzzy
areas in the database as long as they can be identified as such and
there is a clear definition of what they mean and what the concept of
fuzziness is. Renderers shouldn't generally not render the border of
these areas, and if they do for some particular illustration (to show
where Black Forest is for example) they should make them really blurry
and fuzzy. Sure one can always come up with arguments regarding
verifiability, but in general I think they are quite weak. If we want
this feature we can have it. If we don't want it, we can make up
arguments against it.
Often I see in discussions on this list that people not really say if
they actually want a feature or not. They just put forward criticism on
a certain implementation, without ever clarifying their standpoint on
the feature as such. It does not apply to you Martin of course (you have
clearly shown you want this feature, we're just discussing method, which
is great), I just want to mention that I think we should all strive to
do that, clarify our standpoint for or against a feature rather than
just covering under technical arguments, sometimes increasingly strained
and formulaic.
Anyway, one can also argue that it is a problem from an editing
standpoint to have these fuzzy areas overlay other areas increasing the
clutter. While I think the argument has some merit, I think that is
easily solved with a filter, already today supported in JOSM, and easily
added to iD. As the areas are fuzzy it does not really matter if other
natural polygons are edited and adjusted without adjusting the fuzzy
area, they don't need (and probably shouldn't) share nodes with the
underlying nature, so it's not a problem if they aren't visible at the
same time per default.
Although I argue for having these in the main database, I'm not really
against to having it in a different database, that would technically
work as well. I just see it as unlikely to catch on. If we have it in a
separate database we could do it even if the majority of the OSM
community isn't on board with the concept at all. OSM-Carto wouldn't
render it, and as a result I think a major part of the mappers wouldn't
even know that it exists. Just like it's unreasonable to think that
mappers would know about naming concepts that render incorrectly in
OSM-Carto (the Rijmmoáhpe wetland example).
I also think that having concepts to name nature is important enough to
serve the making of maps that it really should be in OSM main database.
OSM can already name much of nature and mappers contribute to that, it
just falls a bit short on these more complex cases. The concept of fuzzy
areas has already been softly introduced with bays and straits. I see no
reason why we shouldn't develop that capability further.
Another challenge with having it in a different database is that of
management and availability. It's strange to suddenly need two databases
to render just common general-purpose maps, and who's going to make sure
that it's available? I think that using the current OSM infrastructure
is a safer bet.
/Anders
On 2020-12-15 09:50, Martin Koppenhoefer wrote:
sent from a phone
On 15. Dec 2020, at 06:11, Graeme Fitzpatrick <graemefi...@gmail.com>
wrote:
If I look at a map eg
https://en.wikipedia.org/wiki/Black_Forest#/media/File:Relief_Map_of_Germany,_Black_Forest.png,
it tells me that the Balck Forest is a more or less oval-shaped area
in Southern Germany. Why can't we draw a similar rough oval in OSM &
call it Black Forest?
have a look at this overview:
https://de.wikipedia.org/wiki/Naturräumliche_Gliederung_des_Schwarzwaldes#Grobe_Gliederung
these areas are not directly observable on the ground, yes, they are
made (I suppose) by scientists according to certain criteria, but you
will probably get different answers if you asked a biologist, a
geologist or a linguist. And according to the scale that they are
working in.
Shall we really aim at having all these possible generalized areas and
classifications as nested polygons in our db? Seems obvious that we
can't.
Cheers Martin
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
