"Amacri" <[email protected]> writes: > Very interesting clarification and links, thanks Christoph, the problem is > well spotted there. > > A general concept would be related to pros and cons of an automated model, > able to differentiate rendering of rural PoIs (e.g., a query related to a > newly introduced automated density layer or to manually mapped polygons), > versus a manual one, totally relying on the mapping quality of each single > element (requiring to define and maintain a per-element conventional > attribute). Anyway the fascinating idea of a sort of automated density > correlation would be future proof from one side, for being able to > dynamically manage the development of geographic areas which might change > over time, but from the other it is true that it goes beyond any reasonable > complexity effort.
There are two issues and it would be good to separate them. One is the appropriate zoom to show an object on the map. OSM styles to date are mostly/entirely based on object type (some function of tags) and zoom level, and not context. In traditional cartography, the human has some idea of significance and scale. When the map has little on it at a given scale (zoom level), one can add more objects, even if objects with that same geographical/cultural significance would not be shown in a city at that same scale. The discussion in the linked issue is mostly about using settlment boundaries. But I think that's not really what is needed, because the question is not about boundaries but about local density. (Around me, being inside an admin level 8 is meaningless; every place is.) If there would only be one viewpoint at z12, and few roads, it makes sense to show it. But looking at a city, viewpoints (few probably) and tourism/historic icons probably whould completely overwhelm a z12 map. > landmark tag (provided that this would be the most appropriate attribution > for such aspect and this I do not know) falls into the manual tagging model > and might be a feasible approach to differentiate rural/urban areas (at > least for the most significant cases) even if mappers shall judiciously > manage it case by case. I think this will eventually cause more issues than it helps. One idea I've had over time, but never pursued, is to give a significance radius, saying "this object is more important than any similar object within a radius of X km". This could help on peaks, which are over-rendered by mkgmap, and would be underrendered if I changed the zoom. I want selective suppression based on neighboring peaks, and there are no absolute altitude rules. With peaks, it can be done by height - basically show a peak if it is higher than any other peak within a radius of 1/4 of the viewport. That gets translated to tiles, but could still work better than presently. (I know: this needs more complicated db ops, and I have not sent a patch :-) For historic/viewpoint/etc., we have all issues with peaks, plus needing to have a way to ask if one thing is more important than another. But we don't really need a total ordering -- we just need to know if some object is overwhelmed by the surroundings. Hence suggesting radius.
signature.asc
Description: PGP signature
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
