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 <[email protected]> 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
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
