[Tagging] How to put a name tag on an area with more than one type?

[Anders Torger]

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 <anders at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging