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? -- Tomas _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging