Some more points after a night's sleep:
I just remembered, another issue with opentopomap is that it doesn't
render wetland names at all, which may be a bit strange for a map with
topology. But we could look at some other map, geofabrik for example,
and of course it renders the same way as OSM-Carto. I don't think you
will find any renderer, except Ture's which just implemented it in this
thread that does this.
The thing is that this "well-established method" doesn't make much sense
as far as I can understand. A renderer needs for each area with a name
label scan for all adjacent areas to see which have same names. If names
are the same it needs to calculate the area to figure out dominant
nature type and then merge to a new area so it knows where to place the
label. But sure, it's far from impossible. It's however strange having
this algorithm that needs activation all the time (scanning for adjacent
names) for still quite rare cases, and it's even more strange to leave
it undocumented and expect that "other renderers" will implement it. But
I'm not dumb (oh well, maybe a little) I really don't think that anyone
believes that other renderers would implement it, it's just a standard
argument to neutralize criticism of OSM-Carto's limited rendering. The
answer is *always* that "some other renderer will do it properly". It's
not exactly ideal for making progress.
I think that having limited and "soft advice" wiki documentation of how
geodata should be interpreted and rendered is a bad idea. However I
think it could still work *if* OSM-Carto took on the role as being a
reference renderer rather than just an "example renderer" which does
some things right, and other things wrong. That does not mean that
OSM-Carto needs to have the best most advanced cartography (although it
would be nice), it just means that it needs to properly render the
concepts which is supposed to work. If it did, maybe we would find out
that the algorithm for doing so is unreasonably expensive, and we would
need to change how data is arranged or introduce a new concept (I think
fuzzy areas is the real answer here). I think it's really risky to
design data arrangement concepts without having an own renderer to test
them with.
And about wasting mapper's time. What about that we have to punch holes
and make river areas for rivers nowadays? Punch holes for waters in
forest areas? And about wetlands, couldn't those be just rendered on top
of forests so we didn't have to make these complex multipolygons?
Managing multipolygons in complex nature is by faaaaar what I spend most
time with. And imagine how much easier it would be to draw if
multipolygons were allowed to have inners that touches outers. Now when
you need to pull up an inner towards the outer edge, you need to change
the shape of the whole outer multipolygon to go around. The tools
available in JOSM for managing multipolygons is still very rudimentary.
Split and join tools only work for the simplest cases, so you generally
need to do these operations manually by cutting ways, making new ways
and hand-edit the multipolygon relation.
Simple-to-draw-but-hard-to-render multipolygons could still be converted
to render-friendly polygons in a middle layer. Conversion and
generalization is required regardless as soon as we move to vector
tiles.
Personally I don't have that big issue with those multipolygons,
although not very effective it's kind of fun to make and manage these.
But I do note that my fellow mappers in Sweden still typically just
ignore that forest is drawn on top of their lakes and overall that the
multipolygon concept is just difficult to grasp for many. So if we are
really serious about "not wasting mappers' time", we should surely look
into ease of editing, and think twice before we introduce a new drawing
rule that makes it more difficult to edit.
/Anders
On 2020-12-14 22:25, Anders Torger wrote:
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
_______________________________________________
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
