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. 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. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
