On Jun 2, 2020, at 4:11 AM, Greg Troxel <g...@lexort.com> wrote: > stevea <stevea...@softworkers.com> writes: >> ...we ask the wider community "what do you think?" and "What are best >> practices here?" > > Agreed this is really hard.
I'm heartened to hear others share not necessarily only frustration, but even some difficulty in articulating the issues! > First, I'm going to assume that polygons for landuse=residential do or > are intended to align with property boundaries. I'm also going to > assume that natural=wood aligns with the actual location of trees, which > is (in mass) almost always not aligned with property boundaries. I have > thought it an error to have natural=wood tagged on a polygon that shows > conservation land, as the adjacent non-conservation land almost always > similarly has trees (around me). Yes, I speak locally (in my county, based on the landuse polygons that have been entered into OSM for over a decade), the (multi)polygons tagged landuse=residential are aligned with property boundaries of residential parcels, agglomerated into a single datum (the polygon), not individual parcels. In my very strong opinion (and others in OSM have told me they agree), OSM absolutely wants these polygons, as they define "this IS residential landuse." (Not COULD BE, but IS). Yes, this land might be "natural" now, including being "treed," but I could still build a patio and bbq there after perhaps cutting down some trees, it is my residential land and I am allowed to do that, meaning it has residential use, even if it is "unimproved" presently. These facts do add to the difficulty: OSM doesn't wish to appear to be removing property rights from residential landowners (by diminishing landuse=residential areas), but at the same time, significant portions of these areas do remain in a natural state, while distinctly and presently "having" residential landuse. For example, I can visually enjoy my trees and creek from my backyard deck, even as they remain natural, this IS (not COULD BE) a residential landuse. (An important one I don't believe OSM wants to remove from the map data). > I would suggest that perhaps a "this land has some trees" landcover tag > (cover != use, strongly agreed) may make sense. I am not sure you are > talking about this, or not. I find natural=wood to imply that the land > has none to very little built structures, mostly trees, and the usual > understory plants. I would definitely not want to use this tag on an > landuse=residential area with houses, but I might use it on the rear > parts of a housing area that are basically trees. I also would not > want to stop at the subdivision line. 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? 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. This has the added benefit of allowing much finer detail on where the actual wooded extents are, as making these distinctions are important to the map as well as to many mappers. 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. > 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 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). 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. > To have a way forward, I think we need a coherent design for a style > (not code, but an articulation of how it ought to work, first) that uses > some kind of symbology for landuse and some other kind for landcover. > I naively lean to solid fill, tending to lighter shades, for landuse, > and stipple patterns for landcover. I think this is what you are suggesting. 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 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). 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." > It is interesting to think about the 80s USGS topo maps, and surely also > interesting to look at other traditional maps for inspiration. The USGS > ones were primarily land cover and very little landuse. But they did > have a gray "house omission tint" in built-up areas, which I'd say is > "this area has many buildings" and is sort of landcover, even though > it's a proxy for landuse. 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...). 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. SteveA California (who has been studying USGS maps for at least a half-century, OSM data for a decade+) _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
