I should have added that a long-term solution is probably some sort of collective concept to handle fuzzy natural areas, and then this wetland will also be named as a fuzzy natural area, although less fuzzy than your typical natural fuzzy area :-). But how long will that take to get realized, when a single tag can take years? I'd like to have some placeholder tagging for later upgrading so the data can be effective now rather than potentially never. So to me lots of small names all over the wetland and a relation to be able to find them later is indeed an ugly but still an acceptable stepping stone, and not the least a good reminder than something needs to be done.

/Anders

On 2020-12-14 14:01, Anders Torger 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 <and...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to