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

Anders Torger anders at torger.se
Mon Dec 14 14:26:15 UTC 2020 

Yes, I agree in full, and I forgot to add in that post that I believe 
the long-term solution for this wetland and other natural features like 
it is indeed to use some fuzzy-area feature. For some reason (I wonder 
why...?) I've got the sense that such a feature could be debated for 
years to come without actually come into fruition so I'm grateful for 
any ugly-hack-stepping-stone I can use meanwhile, so I can just get on 
with my mapping without having to leave out lots of valuable 
information. Then I, or someone else, can come back later and update the 
tagging when there's a better method.

About fuzzy areas:

These fuzzy areas could actually exist today, and straits and bay areas 
do exist and do even render. Personally, I think it's acceptable to just 
put them on top, as one can filter them out in JOSM very easily when 
working with other stuff, and I suppose a fuzzy area filter wouldn't be 
too complicated to implement in iD either.

That the areas is fuzzy can be defined through the type of area (ie bay, 
strait) or one could add an extra tag "fuzzy". As the renderers will 
only show the name tag, any end user will not see the exact extent of 
the fuzzy area, so I don't think it's a problem.

Or, we have them in a different database. While I personally think it 
would be overkill, if that's the only way forward so be it. But if so I 
think it's required that OSM-Carto makes use of it, otherwise it will be 
so unsatisfactory to contribute to it that regular mappers won't do it, 
and then the project will eventually fade out and die, and give the 
naysayers fuel to say that noone really wanted that feature anyway.

I've heard "tagging for the renderer" argument for these type of areas 
and that a single point (like place=locality) would actually be better. 
However, the way I see it, it's the other way around. When placing a 
point you actually do tag for the renderer, the renderer doesn't get any 
freedom where to place the name label. There's also lots of issues 
figuring out which names to show when zooming out, so all just disappear 
at an early stage making rural areas look rather empty... when placing 
an area you just specify the actual area (in a rough way), and then 
based on that information the renderer can place its name label wherever 
it wants. Advanced renderers could shape the text accordingly, when 
zooming in it could show more than one label off center, etc.

I'm no cartography expert, but I think that the common way others do it 
is to manually place labels at points, and sometimes as bendy lines, so 
this way to automatically render names from fuzzy areas instead of 
placing them manually would be a progressive design choice, but I think 
it could be "the right way"(tm). If we instead come up with a name label 
placement strategy better developed than the overly generic 
place=locality, sure I'd be fine with that too, it makes my mapping work 
quicker although with less information. Anything that works...

I also agree that it is obvious that these features do exist in the real 
world, and I think we should strive to make a platform that is able to 
document that even if those natural features are not squarely defined. 
There are issues and challenges, but if the will is there, they can be 
handled.

/Anders

On 2020-12-14 14:31, Brian M. Sperlongano wrote:

> It sounds like what we are asking for is the ability to tag a rough 
> polygon in the approximate area where a label should be placed for a 
> known but not strictly bounded toponymic feature (mountain range, water 
> body, etc).  That would give a hint to renderers as to the location and 
> most importantly, size, of a label for such features.  This would also 
> solve the current problem of tagging large coastline-bounded marine 
> features, such as seas, bays, straits, etc., without creating overly 
> complex polygons resulting from re-use of the coastline ways.  It would 
> also fix the inability to tag such basic features as oceans.  When you 
> type "Atlantic Ocean" into any map other than OSM, it shows you the 
> ocean.  When you type it into openstreetmap.org [1], it shows you a 
> super-close zoom-in to a single node - not very helpful.
> 
> It is reductio ad absurdum to say that features like "Pacific Ocean", 
> "Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a 
> project that aims to create a map of the world simply because these 
> features don't have a fence or sign around them to indicate their exact 
> boundary.  Features exist in approximation in the real world, and it is 
> a perfectly valid opinion to want those things to appear, also in 
> approximation, on the map.  These things are verifiable because people 
> know what these toponyms mean and represent.  If it is possible to 
> write a wikipedia article on "Indian Ocean", it is possible to draw a 
> rough polygon in openstreetmap which means "this is roughly where the 
> Indian Ocean is, and renderers should consider drawing a label".
> 
> Note that this is not "tagging for the renderer" (which is often code 
> for "tagging that I don't like"), these are real, major features that 
> actually exist in the real world and their absence makes OSM weaker.
> 
> On Mon, Dec 14, 2020 at 8:04 AM Anders Torger <anders at torger.se> wrote:
> 
>> To make a specific answer to "what additional verifiable local
>> knowledge" this relation is intended to cover, is that the wetland is 
>> a
>> single named entity, not multiple entities named the same.
>> 
>> And here's some elaboration. This is 4 km wide wetland, in the real
>> world named as a single entity, but it does consist of both bog and
>> marsh, in the screenshot named each separate part as you suggested:
>> 
>> https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
>> 
>> "Verifiable" is tricky in terms of names of natural features as we all
>> know, as many of those haven't defined borders. Wetlands maybe so, but
>> even in this case, are the small satellite wetlands part of Rijmmoàhpe
>> or not? Noone knows, it was never defined. That's the way these names
>> work. Does that mean that these type of names should not be in OSM at
>> all? You tell me. I just try to contribute geodata to make maps for
>> outdoor use. If OSM is not the platform, let me know.
>> 
>> I'm not particularly experienced in how OSM use relations and why the
>> are so "obnoxious" as Mateusz put it, but I have worked with arranging
>> data in many projects and to me this is an obvious case of data that
>> should be arranged as a container with all its parts. I also think 
>> that
>> it would make it much easier to fix the renderer, it can easily get 
>> all
>> parts for the single name, and as a added bonus get to know the 
>> "master
>> type" (instead of having to go through all parts calculate the area to
>> figure out which nature that is dominant to get the tag styling 
>> right).
>> Etc.
>> 
>> I didn't add it thinking about any renderer though, it was actually 
>> for
>> myself to more easily keep track of all parts when editing on JOSM. 
>> With
>> a parent relation I just need to click on one, and then on the parent
>> relation to get all selected. Otherwise I need to create a filter on 
>> the
>> name or something, so to me it's also more efficient for the mapper.
>> 
>> And in the end I think that the individual parts should not have name
>> tags at all, it should only be on the parent relation. The reason we 
>> put
>> it on the individual parts now is to me obviously just because there 
>> is
>> no renderer support available anywhere for naming these type of 
>> natural
>> entities, and probably will stay that way for the foreseeable future.
>> 
>> Having a relation on these new features makes them easy to find in the
>> database and one can upgrade the tags later. I suppose it's much more
>> complicated to make a filter to find parts named the same with shared
>> borders, I don't really know how to do it in JOSM (but maybe one 
>> can?).
>> 
>> So that's my reasons, but if you think they're bad I'll remove the
>> relation. I would like to hear how you want to solve the problem 
>> instead
>> though. As you see on the screenshot, the current situation is far 
>> from
>> optimal with lots of tiny name tags where there should be only one.
>> 
>> /Anders
>> 
>> On 2020-12-14 13:28, Christoph Hormann wrote:
>>>> Anders Torger <anders at torger.se> hat am 14.12.2020 07:59 
>>>> geschrieben:
>>>> 
>>>> 
>>>> I'll gladly answer questions, but I think you need to rephrase. I
>>>> suppose it is some hidden critique in there, but I honestly do not
>>>> understand the question. It would be better for me if you put words 
>>>> on
>>>> the critique instead of wrapping it in a question.
>>> 
>>> There is no critique in there, i have not formed an opinion on the
>>> concept, i like to understand the reasoning behind this.  Hence the
>>> question.
>>> 
>>> The premise is that in OSM we record verifiable local knowledge about
>>> the geography of the world.  And we try to record that in a form that
>>> is most efficient for the mapper.  Hence the question what additional
>>> verifiable knowledge you intend to record with the additional data
>>> structures you propose to create that is not yet in what we already
>>> record today.
>>> 
>>> --
>>> Christoph Hormann
>>> https://www.imagico.de/
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



Links:
------
[1] http://openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201214/c9df1e4a/attachment-0001.htm>

More information about the Tagging mailing list