I certainly agree that we should not waste mapper's time, but in this
case it was mainly actually to make it easier for myself with JOSM to
find my way back to all small pieces in a fragmented landscape. Not
having this relation makes editing a fair bit harder as you can't really
see which parts belong to the same (name labels are really not that
visible in JOSM) and you need to click your way through or create a
filter on the name, but since you don't want it I will remove it. It
will probably lead to more work for me rather than less, but I won't
invent something that everyone is against. It's a value in keeping it
simple too. So we can put that to the side, don't worry there will be no
relations.
Opentopomap has some interesting features, but also it's own family of
problems. The largest problem (except for limited server capacity) I
think is that it renders borders between same tag areas, which causes
lots of borders of technical polygon splitting visible, which exists
everywhere in the map if you like it or not. The development also seems
to have stopped, so any issues it has now won't probably be fixed.
And does it render this "well-established method" by automatically
finding adjacent parts and showing only one label. I'm still waiting for
the result, but I would be *very* (happily) surprised if it does.
If OSM had been a normally managed project there would be numbered
releases of a well-defined specification how OSM data should be
interepreted by renderers. When there is no such thing, how can we
expect that other renders should solve things, without documentation?
There's so often reference to "other renderers" that does things right,
but where's the examples? There may be one renderer that make some
things right, but then others wrong (like opentopomap)... that there
really is no showcase renderer under the control of OSM itself I
personally think is the largest waste of mapper's time we do. I see
people skipping things, guessing, making "creative" incorrect mappings
just because OSM-Carto is so limited in what it can do. Not only
beginners, also experienced mappers. Just one example, some are so fed
up of that OSM-Carto cannot remove text of rivers inside lakes so they
cut up the river and remove the name instead. If OSM-Carto quality and
feature set would go up and the documentation (for mappers) with it, so
would the geo data, of that I'm convinced.
/Anders
On 2020-12-14 21:45, Joseph Eisenberg wrote:
Re; "Don't adjust your mapping to what you believe is most convenient
for data users"
I know this recommendation is unpopular with some mappers, because many
of us just want to see a good-looking map, and if it takes duplicating
relations and extra mapping work we will do it.
But remember that your time as a mapper, even though you give it to
OpenStreetMap freely, is actually valuable and should never be wasted
on doing things that can be solved by better software on the database
user end of things.
We should never ask 10,000 mappers to spend 10 hours a year each to add
something to the database which saves 10 hours of work for a database
user.
Sometimes this means that the rendering on openstreetmap.org [1] won't
look perfect, but we can expect better results in the future with more
advanced renderers. Consider for example how OpenTopoMap has really
great natural=peak and natural=saddle rendering, which uses elevation
and topography to adjust the rendering to look good with the contour
lines and different zoom levels. This is somewhat complex, but it was
done by an open-source, free map style.
Once upon a time I planned to add prominece=* tags to all the peaks in
my area so I could get good rendering results, but the solution which
OpenTopoMap uses is much better: it's fully automated and fast. Adding
the topographic prominence to every natural=peak to get better
rendering is a huge waste of mapper time, when you can instead
calculate it (or better yet the topographic isolation) at the time of
rendering.
Similarly mappers shouldn't map a huge relation which includes all
parts of the water in a long river, since it is much easier to map and
maintain smaller closed ways for each short part of the river water. If
database users need one big area, they can pre-process the data to
create the polygons: don't make life harder for mappers to save the
database users a few CPU cycles.
Your time is priceless, fellow mappers. The time of database users is
usually a business expense.
-- Joseph Eisenberg
On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann <o...@imagico.de>
wrote:
Anders Torger <and...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Links:
------
[1] http://openstreetmap.org
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
