stevea <stevea...@softworkers.com> writes: > We agree. The issues are both around the different behavior of the > (Carto) renderer when both landuse=residential and natural=wood are > combined (and there are highly complex ways they can be and are > "combined" in the OSM database), and around how mappers understand > these data should be entered. Should both natural=wood and > landuse=residential be "stacked" as two tags on one (multi)polygon?
I would say probably not, as it is highly unlikely, really entirely unlikely, that an extent of landuse=residential, determined by aggregation of property with similar use, lines up exactly with an area that is covered by trees. > That was and is widely done in cases where heavily-wooded residential > polygons exist, though a "better" trend (at least around here) is to > break these apart into two polygons: one explicitly on the > landuse=residential polygon (glom of parcels which are residential, to > the area extent where they are), one on the polygon defining the > extent of natural=wood. Yes, this is sensible. Two areas, entirely disconnected spatially, each defining the area where their property applies. > Unfortunately, Carto doesn't easily (it does consistently, but the > rules are complex, having to do with sizes of the underlying polygons) > render these consistently, requiring frequent "fiddling" by craft > mappers who are looking for both a desired effect and a visual > semiotic which richly and accurately conveys what is going on: heavily > wooded residential landuse. THat's what I meant by suboptimal, which was a polite word: If there is semantic markup of "this area is residential landuse" and "this other area is covered by trees", then the rendering rules should do the same thing regardless of the precise form of the relation/polygon/etc. It is a bug if anyone needs to walk on eggshells to make it come out right. I don't mean in any sense to say "the people that do Carto are bad people". This seems incredibly hard to get right and I don't know how to fix it. I just mean that it is a failure of software to be ideal and a place for improvement, in a descriptive and non-judgemental way. >> The basic problem here is that it's pretty straightforward to render a >> map that primarily shows landuse, and it's pretty straightforward to >> render a map tha primarily shows landcover. What carto does, and what a >> lot of people want, is a way to show both of them. > > I wouldn't necessarily call it a "basic problem," more like the desire > of "let Carto display both" doing so in complex ways, which gives rise > to "well, what are the best practices here?" I think we agree; I'm saying that designing rendering rules that show land use and land cover at the same time is 1) hard and 2) beyond what is typical in cartography. In other words, the "what are best practices" question you pose don't have an easy, consistent answer. >> I would suggest that if tagging heroics are needed there is something >> suboptimal in the renderer. I think renderers probably need fancier >> code to choose which of landuse/landcover to emphasisize depending on >> local scale. Or a deconfliction of symbology. > > Yes, heroics are sometimes employed, yet even that isn't always enough > (it is often, but not always). "Suboptimal" might be too damning, as > I don't think it is "deficiencies" in the renderer, rather I think > there are "projected expectations" of the renderer (that it appears > Carto CAN render "both," so it SHOULD, and it DOES, but in > sometimes-confusing ways). I don't know if you are just trying harder than me to be nice, or if we really see this differently. I see a rendering plan like a specification, something like "an area that is both landuse=residential and natural=wood should have a 40% gray fill with a stipple of tree icons at 20% green" (making that up, details not the point). Then, areas that are covered by each should be like that. And the exact form of tagging should not matter, and people should not feel motivated to mess around with tagging form to make the renderer work. Otherwise, it's a bug to be fixed. Again, this is hard and I get it that people with limited time are working on it. > This is an example of amazing, sometimes > beautiful things going on in the renderer "driving" whether and how > OSM should and does enter data. Yes, there is some "coding (data and > tagging) for the renderer" going on, but it appears to be in the best > longer-term interests of good data entering, not simply and only for > the same of "pretty renderings." I believe we can get there, an > attempt to discuss "best practices" (I'll settle for "better > practices" for now!) is a step in that direction. As always, there is the question of whether people are really coding tagging for renderer behavior that is not justified, or whether there is a sensible semantics in between taggers and interpreters. I feel like you have arrived at having to walk on eggshells to make it come out right, which feels like a bug. > I'm not necessarily suggesting anything, except that we better > articulate our expectations of what the renderer can deliver (it CAN, > because it DOES deliver an agreed-upon solution of "superimposed trees > on gray" for heavily-wooded residential polygons), the issues surround I don't find the phrase "heavily-wooded residential polygons". If you mean "areas that are covered by a landuse=residential polygon, and are also covered by a natural=wood polygon", then I think it's much better to say that, rather than something that sounds prettier, but is more open to misinterpretation. (Yes, my formal training is in Computer Science, not English, in case that's not obvious.) > how we best do this. It is complicated to articulate and achieve in > ways understandable and well-implemented for many. Yes, I agree that > after we say "let's display heavily wooded residential polygons as > superimposed trees on gray," (some of us already do), an excellent > next step might be "how it ought to work," perhaps by the author(s) of > the renderer. That will allow data mongers and craft mappers to > identify whether and where it does or doesn't. If there are > ambiguities (or even bugs / defects), those can then be addressed and > eventually corrected, or identified as "not a bug, your expectations > are incorrect." (If, in fact, that's the case). Sounds good to me. I am a huge fan of specs and interative discussion. One could even have test vectors! > At the risk of introducing a side topic, I have mentioned in wiki that > there are "1980's MacPaint-style fill patterns" for polygons that > could inspire renderers. This is an almost dangerous topic, as way > too many fills, stipples, etc. can severely clutter a map rendering, > making it unusably complex. Let's apply the "Keep It Simple" > approach, starting with what Carto already does, and better understand > how we might best leverage existing machinery by setting expectations > properly as well as articulating "better / best practices." Yes, that's part of my "basic problem". Design of a style that represents more than is comfortable is truly hard. Carto has tried hard to control the complexity of what is represented so that normal people can read the map. > We would also agree that not only was USGS' tinting and shading an > approximation and incomplete (and in many cases, quite a beautiful > representation), but landcover areas do change over decades (trees get > cut down, scrub can naturally develop into trees...). Of course; I didn't mean the old topos are what we should enter as data. I just meant that it is an example of what has stood the test of time as good design of showing land use and land cover, sort of, at once, in a relatively uncluttered style. And hence food for thought. > OSM can approach how we deal with these "visual semiotic" issues from > multiple angles: from the perspective of "what is desired in > rendering?" (the very back end) to "what data do we want in the > database?" (the very front end). This discussion of "full pipeline" > does lack in OSM, and the topic of "heavily-wooded residential > polygons" is only one dimension along which this dialog might happen. Sure. I tend to think that if something is semantically sensible and can be represented, it's good to tag it, and then rendering is another story. I think pretty much everyone agrees that landuse=residential and natural=wood are both sensible to represent. And that how they ought to be rendered in a general purpose landuse/landcover style is much less settled. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
