[Tagging] Basic cartography features missing, why?

[Anders Torger]

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?