<div dir="ltr"><div dir="ltr">On Wed, Aug 11, 2021 at 5:22 PM Minh Nguyen <<a href="mailto:minh@nguyen.cincinnati.oh.us">minh@nguyen.cincinnati.oh.us</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If Brian had done that where I map, I would've pleaded for the import to <br>
be reworked or reverted. Ways sharing nodes, sure, but modeling landuse <br>
areas as relations just because they border each other would be <br>
incredibly unfriendly to any mapper who has to maintain the data as <br>
landuse changes in the future.</blockquote><div><br></div><div>That's a bit strong, but feelings run high. Some mappers strongly prefer shared ways where it's known that two landuses or two types of landcover actually must have a common border. ("The residential area ends where the industrial area begins," "The land ends where the water begins," "The wilderness area ends where the producing forest begins." Others seem to find it difficult or impossible to maintain.</div><div><br></div><div>I have a mild preference for shared ways, myself, in these cases, because I seldom find that the boundary lines are consistent - always, I find that there's an overlap or a gap because a mapper skipped a node in drawing a line. Moreover, I find that drawing the same way multiple times is quite tedious. I'm prepared, however, to edit either configuration.</div><div><br></div><div>My comfort with multipolygons may come from the fact that I routinely curate some extremely diffuse areas such as the Wild Forest areas in the Adirondacks, where there's no escaping the complexity and the capabilities of all the tools are somewhat strained. Even there, I've come under fire - I don't recall who it was - it might have been you - that asserted that every individual parcel of an area like <a href="https://www.openstreetmap.org/relation/6360587">https://www.openstreetmap.org/relation/6360587</a> should be a separate top-level polygon, and multipolygons should be reserved as a matter of last resort only for features with holes, or features with thousands of nodes on their boundaries. The website, Wikidata, name, protection title, and so on should simply be duplicated across all the distinct areas. It was important to me to be able to refer to the facility as a whole, no matter how diffuse its boundaries, and I found the proposed solution of referring to it only by an Overpass query that returns multiple results to be a poor alternative, so I maintained the relation anyway.In any case, the largest parcel is unavoidably a multipolygon because of the inholdings. (And one with an awkward topology at that. including, if memory serves, a "pond on an island in a lake inside the parcel" where neither water area is part of the area in question.)</div><div><br></div><div>Note that I avoided conflation with municipal boundaries because (a) TIGER doesn't have them all right, and (b) the surveys that laid down the townships were often quite primitive, and substantial errors of closure exist to this day. There's no guarantee that the borders align, which is my criterion for conflating shared ways. Similarly I refrain from conflation with shoreline unless I understand that there's a true "the land ends where the water begins" status. (There is such a thing in some of these cases, because the upstream database that I'm using represents "Forest preserve land under water" as a separate landuse, and I know that in that case, the actual shoreline governs, since the landowner of the shore is the landowner of the water.)</div><div><br></div><div>I believe anecdotally that the preference for shared ways vs. redrawn boundaries is correlated with the mappers' choice of software tools. Those who use the more powerful but user-hostile JOSM are more amenable to multipolygons with shared outer ways than those who use more approachable but less comprehensive tools. (I fully concede that JOSM is bug-ugly and has a pretty impenetrable user interface; I use it for its power, and because I'm accustomed to discovering functionality by spelunking the inverted-L menu format, now regarded as unstylish.) </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>