Beautiful name label rendering!
Regarding separate database, I think it's a good idea if that is the
only way forward. Something needs to happen. Being able to fulfill basic
cartography needs are not "new" ideas, I really believe that it should
be a priority for a database used for generating maps so it's sad to see
that it's being blocked. This is also a space which seems to be were we
can have an edge when more and more maps are moving into vector. I see
that many providers actually go backwards in cartography when moving to
vector (due to worse name label management), but we could instead go
forward, and topo.openmap.lt is an inspiring example.
To me it seems like an odd "political" design decision to have a
separate database though. Why just not arrange the database in layers,
and this could be a separate layer? From a technical perspective I
suppose it wouldn't have to be layers as such, one layer could in
actuality be a tag filter.
That we get stuck on arguments about cluttering the database with
"unmaintainable polygons" I see simply as a database management problem.
What if we in the future want to have specialty maps like say bedrock
maps? Of course putting those polygons all over the others in the same
database will be a mess. Already the data is slow to manage and edit for
my lowly machine in dense areas as one get all layers at once even if
one only wants to work on say coastlines. Once imported to JOSM I can
work with filters, so it's manageable, but I think it would be *much*
better if layers got to be a more defined feature.
I also see that layers could be an advantage for import processes, you
could create a separate layer for making a huge import which is not used
in rendering, but used by casual mappers during long-term manual
merging. (As a side note I also think that OSM needs a professionalized
import task force working for a year or so to boost countries with good
local public data and bad OSM data, instead of individuals here and
there make their best attempts of making an import which can be really
technically challenging, which we see the effects in our Swedish map
now).
On 2020-11-08 06:51, Tomas Straupis wrote:
2020-11-08, sk, 00:00 Anders Torger rašė:
Maybe this is self-evident to anyone that knows more about this than I
do, but I have to ask, are you saying that when we have to implement
generalization to be able to serve vector tiles, it's also natural to
include generalization of names? Meaning that we could see more names
than we do now when we zoom out, so perhaps rural areas don't get the
empty-map-syndrome? That would be awesome.
Names do not take too much space in vector tile. I was talking about
larger objects like landcover, water, buildings.
In addition I still want some method to name features in the landscape
though, that supports automatic generalization. I thought named areas
was an elegant way to do this, but it seems some have very strong
opinions against it.
If we're talking about fuzzy features (which do not have specific
boundaries) like mountain ranges, bays, straits etc. the problem is
that just a point is not enough, text must have direction, sometimes
even curvature to follow the geometry of the object ant thus "connect"
the label with the object in our consciousness. Additionally, for some
objects, say bays, we need totally different set of labels for
different zooms and that can only be calculated if we have a polygon
(check water labels and how they change
https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with
zoom 16 there is actually a lot of labels placed in different places
of the waterbody). But placing polygons for fuzzy objects have
problems:
* borders are not verifiable on the ground (as there is actually no
border - object is "fuzzy")
* imprecisely drawn boundaries of such objects look bad in the
editor, intersect with other objects and this kind of pushes mappers
to simply use boundaries of existing features (like coastlines) which
makes those object waaaaaay too precise for fuzzy objects.
My personal opinion is that such objects could be moved to a
separate database specific to fuzzy objects. That database should not
have ANY connection to the main database so that mappers would not be
able to reuse geometries of the main database. Thus license would be
the same, toolchain would be the same, data could later be used
alongside the data from the "main" database. Everyone should be happy,
both arguments (Christophs and Frederiks) against such objects would
be satisfied?
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
