Thanks.
I appriciate that you say that features are actually missing in this
context. The usual way things go when I've tried to discuss these issues
in various OSM forums is that it's incredibly hard to get to a consensus
that there actually even is a problem at all. I get suggestions to map
it in some way that either not work at all or has no renderer support by
any data user out there, and when I point out that the discussion just
goes silent, and I'm probably just considered annoying.
If one gets past the first hurdle and actually gets to a consensus that
these things cannot be done today, the next hurdle is "do we want to
support this?". Also here I tend to get stuck in meta-discussions about
how hard these features are to render quickly on a map or difficult it
is to store in the database or show it in the tools, without anyone
voicing any opinion for or against the desire to actually have this
feature, just seemingly trying to kill it with arguments that it's just
too hard to implement. OSM-folks often say that OSM should support not
only mapping of streets as the name implies, but also nature. But when I
point at specifics required to actually do this in a good way, I find
myself stuck.
This wetland question was sort of put to an end with a reply "just name
all parts the same". It does work for my particular use case, but as you
point out it's far from a generic concept, and unlikely that it will be
taken up by renderers as relation is missing. Wetlands do generally have
sharp borders (although in the national park I'm mapping some of the
wetlands are so large that they have different names in different
places). When it comes to peninsulas, valleys, mountains, broad ridges,
hills, slopes and more natural features we have names for, not so much.
Personally I'm okay with just drawing an area on top, everyone
understands that it's fuzzy. Just like we can do today with bays and
straits. But as discussed in another post, there's overwhelming
criticism from leading OSM profiles against having fuzzy areas in the
main database so it's unlikely to happen. And as long as no widespread
renderer actually uses the data and there's no wiki info on how to name
these things there's no chance for this to catch on by regular mappers
actually taking their time to put in the names.
Mountains are in OSM usually mapped as a point, a peak. However,
mountaineering was not an interest among those that actually named the
mouintains, so often what has a name is the mountain, not the peak
itself. But as OSM doesn't support naming mountains, there's lot of
misleading naming out there. Today I had a mountain to name, it has
three peaks, but only one name, and the name is on the mountain not the
peak. The list goes on. For anyone knowledgeable in cartography missing
features like this are easily identified.
Sure we can choose to have a map that doesn't support them (and say that
we only intend to support zoomed in urban contexts, I guess that's where
the money is anyway), but it's not odd features in any way, any
institutionally made map have them.
/Anders
On 2020-12-12 13:55, Martin Koppenhoefer wrote:
sent from a phone
On 12. Dec 2020, at 12:26, Anders Torger <and...@torger.se> wrote:
In the wetland case as described, there is no parent relation at all.
The only thing that ties them together is implicitly by sharing
borders and having the same name tag. It seems to me that an
"official" way to edit should tie them together with a parent
relation.
Yes, we do not have a way to map toponyms for larger areas when we
also want to map detailed landcover within. Christoph’s idea of using
the same names on the parts fails when the individual parts have
different names. We can’t map bigger geographic entities like deserts,
swamplands, forests, highlands (besides the names for the smallest
parts, or if they correspond to other entities with clear boundaries
like nature reserves, or maybe by overlapping the same kind of
objects, what is generally frowned upon)
The logical way would be a parent relation with type=wetland (and
actually have the name only there, but no renderer today understands
that, it needs to be on the separate parts as well). What should the
roles be? The most logical way would be to leave role field empty.
Maybe a similar approach as the one for relations of type=group (i.e.
a relation type which explicitly “inherits” its meaning from the
members without the requirement but with the possibility for
additional tags, a place to put a name for the ensemble) could be
taken for area relations as well, e.g. the site relation could include
the different wetlands, and a name (and e.g. wikipedia/wikidata
reference, etc.) might be sufficient to map the “collective” of
things? The nature would be implied by its members.
The bigger such geographic entities become, the less you will
typically be able to draw a hard line (fuzzyness of many natural
borders, rather smooth transitions). If we want to map all those “meta
areas” with names we would do well to think about additional ways of
delimiting space (i.e. different kind of geometry objects), e.g. a
fuzzy border could be represented by providing different points for
which it seems undisputed that they are in or out of the area in
question. This would be very lightweight for all mappers, because it
avoids clear lines which are confusing when they do not correspond
with something observable. It may be difficult to find these things
though (obviously would require editor/tool support).
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
