[Tagging] Basic cartography features missing, why?
anders at torger.se
Sun Nov 8 10:28:28 UTC 2020
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
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
> * 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?
More information about the Tagging