On 2017.11.20. 23:29, Kevin Kenny wrote: > I'm somewhat relieved to hear Gleb and Frederik injecting a voice > indicating that 'shared ways' separating regions might be an > acceptable approach, because I've adopted it myself. Well, to some > extent, any way. > > I'm generally against sharing ways EXCEPT when topology demands it -as > it often does. It's pretty nonsensical to start going to shared ways > just because a building abuts a parking field, for instance.
revisiting this thread, i have to clarify that multipolygons for big objects like administrative areas, large national parks and similar entities seem fine to me, and often are the only reasonable approach. where they do not seem to provide benefit and only make things much harder are smaller objects - think most residential/commercial/industrial landuse, parking areas, buildings (except where used to "cut a hole" in a building). i got reminded about this when attempting to improve a fuel station recently. i intended to split car wash in a separate area, move tags from a node to area and similar. in this case, the serviceway area around the building, the building itself, the grassy areas there - they all were mapped as multipolygons from short way segments. i could have untangled that, but it would take some time. i gave up. > Still, if two adjacent polygons are the same sort of thing, or > specifically defined to be conterminous, then I certainly want to > share the boundary. By the "same sort of thing," I mean administrative > regions that share a boundary, or different land uses (following our > presumption that a piece of land has only one land use), or different > types of land cover (including water). And 'specifically defined to be > coterminous' includes things like parks that stop at a waterfront. > > I would tend to avoid shared ways for things like a wood that stops at > the boundary line of a protected area. The trees don't know where the > boundary is, and the boundary won't move if the adjacent landowner > allows his plot to go back to nature. > > There are several reasons for shared ways between topologically adjacent > areas. > > (1) Data consistency. This is the primary reason. As Gleb points out, > if a shared boundary is a single way, there's no chance that someone > will retrace the boundary of one of the neighbouring regions without > retracing the other, or will enter them inconsistently in the first > place. > > (2) Rendering. We've already discovered for boundary=administrative > that representing bordering regions as separate polygons sharing only > nodes rules out using things like dashed-line rendering, because each > boundary will be rendered twice, and there is nothing to ensure that > the dashes will be in the same relative phase; dashed lines tend to > turn into solid lines in such a scheme. That's one of several reasons > that we have tried to keep shared ways on all boundary=administrative > meshes. I foresee in the future (and already confront in my own > rendering) cases where protected areas, or even things like > leisure=park, are rendered similarly and therefore need shared ways to > get a clear display. > > (3) Ease of editing (for better-informed or better-tooled users). At > least for me, working in JOSM, I find updating a mesh of multipolygons > with shared ways to be fairly straightforward. Split the ways at any > new corners, draw any new ways, update the touching regions, delete > any obsolete ways. Sure, it's a different workflow than the one for > simple polygons, but for that workflow, I find myself retracing over > long sets of points, or else splitting, duplicating, reversing and > rejoining ways. The duplicated ways are difficult to work with, since > they share all the points, and I have to puzzle over some pretty > subtle things to understand which copy I'm working with. By contrast, > the split and joined ways in a shared-ways structure always have > distinct geometry. > > By contrast, the chief argument against multipolygons is that they are > unfriendly to newcomers. I'll happily concede this point in part. > They certainly demand a somewhat deeper understanding of the data > model, and the newcomer-friendly tools such as Potlatch don't really > do them competently. This argument is stronger that Gleb and Frederik > appear to recognize. Given the difficulty of recruiting mappers, we > surely want to make life as easy as possible for newbies, even if that > comes at some expense in the ease of use for the old hands. > > That said, how likely is a newcomer to be editing a complex mesh of > land use or land cover and not mess up the topology, however it's > represented? I suspect that new mappers attempting to adjust these > features will always wind up creating overlaps, gores and broken > multipolygons. (SOME multipolygons are unavoidable because areas have > enclaves or exclaves!) Moreover, part of the newcomer-unfriendliness > comes from the fact that examples of shared ways are sparse, and tend > to be on stable things like administrative regions, the shorelines of > large waterbodies, and similar features that newcomers are > (rightfully) a little afraid to edit in the first place. Heck, how > many newcomers will even recognize that topology is important? > > I may have a somewhat warped view of things. I got into using shared > ways when tidying conflicting imports of various public lands in New > York State, where there were many gores among county and township > lines, shorelines, and the boundaries of various sorts of protected > area. The boundaries are topologically complex, and being constrained > to deal with them by retracing partial ways would be a nightmare. > Shared ways was really the only approach that worked, and from what I > hear, for complex cases, it's still considered acceptable. That's a > relief! > > Once I became fluent with the approach of using shared ways, I've come > to use it when, for instance, adding landcover or land use polygons > even in my own neighbourhood. Even there, it could be that the use is > noncontroversial, since I live in a hilly area and as a consequence, > most of the polygons have edges that twist and turn. Nevertheless, I > freely concede that I may have overused the approach. > > I surely don't see a compelling reason to adopt any proposal to use > mechanical edits to replace polygons that share two or more nodes with > a multipolygon mesh. I'll presume that the mappers who entered the > polygons had their own reasons for entering the data as they did. But > I do feel free to introduce shared ways when editing such a beast, > because I struggle with keeping the topology consistent otherwise. > > As long as people don't start to claim that the approach of using > shared ways is invalid, or that I'm committing vandalism by adopting > them when I'm either entering new data or editing adjacent polygons > for other reasons, I'm content. > > And I do consider it unacceptable when someone removes a shared border > for which I've carefully curated a consensus solution from multiple > conflicting data sources, and replaces it with a simple polygon that > fails to align with anything along its margins. (I've recently sent > rather a long laundry list of problems to a mapper who did just that. > No response yet.) Introducing incorrect data in order to make the > format more friendly to newcomers is not the way to move forward. > > We should strive to make simple things easy. But perhaps more > importantly, we need to continue making difficult things possible.-- Rihards _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
