The fifth alternative is move the big areas to an outside repository: https://github.com/dieterdreist/OpenGeographyRegions
This might be a great alternative until we find a better solution. And there might not be a better solution. Janko pon, 21. pro 2020. u 10:22 Anders Torger <[email protected]> napisao je: > Next question. > > In the mountains we have an number of named plateaus. There is a tag > proposal for natural=plateau, but just like with natural=peninsula and > similar tags there is an underlying question that we really need an > answer to first: should we have fuzzy areas or should we not? > > Plateau, peninsula etc are naturally mapped like an additional low > detail fuzzy area polygon on top of other land covers. My opinion has > been made clear in other threads: I think fuzzy areas on top is an > elegant solution for naming nature and something we should have. I think > the cluttering issue can be solved with filters, but as these will be > used in low numbers to start with I think cluttering will not be an > issue for some time to come so it's something we could look into later. > In any case that's a tool issue, not a database issue. > > If we don't want fuzzy areas, an other alternative is to have these as > named points, (previously often made as "place=locality"). I think that > is okay too, but then we need size classification on them like we have > on residental isolated dwelling/hamlet/village etc so the renderer have > enough information to know how large to make texts and which zoom level > to show them. Having the same level for all names doesn't work. > > Fuzzy areas has the advantage of solving the text size automatically > (not a mapper decision), and gives freedom to the renderer to place (and > even shape) the text. Fuzzy areas also scale well up to huge sizes (like > the Sahara desert) if we want that as well, which point text doesn't in > the same way. We could decide to have fuzzy areas over a certain size in > an external database too. I'm not super-stoked over the external > database method though, as I think then it risks becoming like > elevation/contours is today, ie not generally available and with varied > quality. > > A disadvantage is that fuzzy areas have limits in verifiability and it > arguably requires more knowledge/judgment from the mapper than roughly > placing a point. On the other hand, optimal point placement also have > cartography and verifiability issues. The underlaying issue here is of > course that these type of names have never have defined borders and > never will, but I think we cannot continue to pretend that they aren't > relevant for a database mainly used to generate maps. We need to > represent them in some way. > > A third alternative is not having names of this type at all. While I > just said that it's not the way to go, if someone still has that as a > clear opinion please make that clear rather than just point at > disadvantages of every suggested solution without coming up with an > alternative. We know there are disadvantages and no solution is 100% > perfect, but sometimes there's a higher goal to fulfill. > > The fourth and current alternative is leaving the question undecided, > with some fuzzy areas active (bays and straits), some not rendered > (peninsula), and passively see how it plays out in the coming years (or > decades!). It's the simplest alternative, but as a mapper and OSM end > user I hope we can make some real progress now. > > Worth mentioning is also the alternative to make a fuzzy cutout of the > dominant landcover and name that. I've done quite some forest naming > that way. However it's quite complicated and time-consuming to make > these cutouts (complex multipolygon editing), and it only works well > when the name is actually tied to the landcover as such, eg the name is > on the forest, not a forest-covered peninsula or plateau. While I think > it's okay to mix this cutout naming method when it works, and use fuzzy > areas on top when that is required, I also think a viable option would > be to name forests with fuzzy areas on top as well, but then we need a > specific tag (or tag combination) so the renderer knows that it > shouldn't make landcover rendering for that. > > I'd like to at least know where we are headed. I could use a tag which > is not yet rendered, but it would be nice to know if the information > will potentially ever be used, or if I'm maybe just wasting my time... > > /Anders > > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
