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

[Anders Torger]

Ok, understood. However as far as I know OSM lacks a standard document 
for render implementors to actually know how data should be interpreted. 
And if OSM-Carto does it wrong (albeit due to technical limitations), 
how can we expect that anyone else would do it right? Unfortunately I 
think the answer is that there is no documentation, and no other data 
consumer will do it correct. I may be wrong though, it would be great to 
know if there is any renderer out there that understands that it is a 
single entity and merge the labels.

I actually don't enjoy being on this list creating havoc or plaguing you 
or anyone else with my daft questions, and I suspect people here doesn't 
enjoy my company much either :-), but don't worry this thread is nearing 
the end and I'll crawl back under my rock again and go back to mapping, 
which is what I truly want to do. But OSM in its current state with the 
way the docs and technical platform is made really begs for this to 
happen as soon as someone like me starts to make high detail mapping, 
and wants answers instead of just skipping, guessing or simplifying when 
tagging challenges arise.

The only reason I get here is when the OSM wiki doesn't have answers, 
and on top of that I get pretty much random answers on OSM Help (which 
seems to be standard), and I need to go here to just get to know how one 
should map certain features, if it even is possible. Even here there are 
various answers and ideas circulating and it's not hard to see the 
cracks in the facade and different ideas even among "high ranking" OSM 
people. The truth is that OSM is not really ready for this type of 
mapping, and that's fine, but it seems to be ultra-sensitive to touch on 
the subject that maybe actually something in the technical platform 
needs development to meet the long-standing goals of OSM.

I also react on the lack of vision and what seems to be a technical dead 
end of the platform. The way you express it makes it seem like OSM is 
dependent on external software providers. Forgive me for my ignorance, 
but don't we have "own" programmers? I know this isn't a traditional 
open-source project (which I'm used to contributing to), but aren't 
there at least some programmers that develop the technical platform 
according to the vision OSM has? Or do we just pick ready-made tools 
that are designed in other projects for other uses and we have no power 
to influence? If it's the latter I'm really worried...

There are levels regarding "high quality cartography". We don't need to 
jump directly to the highest level with smartly scaled/shaped and sorted 
text labels. I would to start with be satisfied with correct rendering, 
and rendering multiple text labels where there by definition should be 
one I consider incorrect. If even that is "too expensive" no meet the 
goal(?) of "low quality low price", well, then I'm speechless.

I've heard big words come out from the OSM foundation, about striving to 
provide the best geodata. Really motivational, making it enjoyable to 
contribute as a mapper. However when I see how the technical platform 
works today, and which features that are missing and on top of that get 
on this list and see the lack of interest and/or capacity to do anything 
about it I see a whole different story.

/Anders

On 2020-12-14 19:41, Christoph Hormann wrote:
>> Anders Torger <anders at torger.se> hat am 14.12.2020 15:49 geschrieben:
>> 
>> Okay, but why does the OSM-Carto renderer, and all other renderers 
>> known
>> to man(?) make multiple text labels then, when it should be a single
>> one?
> 
> OSM-Carto renders labels primarily based on the following constraints:
> 
> * due to the requirement of real time updates more complex operations
> are severely restricted.  Clustering features, aggregating the
> clusters geometry-wise and labeling the aggregates are such
> operations.
> * we want the relationship between the data in the database and the
> rendering results to be intuitively understandable for the mapper so
> they can derive useful feedback from the map.  That also limits the
> complexity of data processing we can use.
> * like all zoomable interactive maps OSM-Carto has to deal with the
> problem that high quality labeling is zoom level dependent.  At the
> same time having different approaches to labeling at different zoom
> levels adds a lot of complexity to the style - and OSM-Carto is
> already one of the most complex map styles in existence.  Hence
> compromises are made that look better on some zoom levels than on
> others.
> 
> As far as other map styles are concerned - i have said that before:
> high quality cartography is expensive and the bulk of the digital map
> market is low quality and low price - hence requires low costs.  And
> the willingness to engage in strategic investment in methods for high
> quality cartography in the wider OSM ecosystem as well as in the open
> source GIS sector is so far rather small.
> 
> What can you do as a mapper:  Produce an accurate representation of
> the geography that is non-complex in structure, is easy for you to map
> and maintain and that is consistent with how others map things and
> don't adjust your mapping to what you believe is most convenient for
> data users.
> 
> --
> Christoph Hormann
> https://www.imagico.de/
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging