[Tagging] Another multipolygon question

[Kevin Kenny]

On 10/29/18 2:48 AM, Dave Swarthout wrote:
> But I'm still a bit confused about way:427547729. It's tagged as an 
> outer in the Wilcox WF multipolygon but it's located inside of an 
> enclosing way that's also an inner to the same relation. Does that 
> mean the inner/outer roles alternate as you add more and more "nested" 
> objects to the large multipolygon? For example,iIf there was a block 
> of private property inside way:427547729 would that be tagged as inner?

You got it. That's why I chose that specific one as an example, to show 
how 'exclave within enclave' works. It's unusual, but it happens.

> Just to touch on another topic because Kevin mentioned it. Sometimes 
> it's fairly obvious that certain boundaries were meant to follow a 
> riverbank or a coastline but at the present time don't. My first 
> impulse is to delete segments of the original boundary and replace 
> them with the more recent riverbank or coastline. That would probably 
> be considered wrong by some but seeing as we do not and can not 
> guarantee perfect accuracy with the placement of any boundary I don't 
> see it as an absolute no-no. Plus, many of these boundaries use 
> thousands of nodes that follow every little zig-zag to achieve legal 
> accuracy. IMO, OSM doesn't need that level of detail.
>
> Opinions?

I think you're right about the level of detail, and in fact I simplify 
ways fairly often.

Because partly of confusing advice here, in 'imports', in talk-us, and 
on the Wiki, when I did the reimport of the Adirondack protected areas, 
I did them as separate ways. In order to be able to simplify them, I 
used an 'erode' operation (a 'buffer' operation with negative size) 
where the size was slightly larger than the simplification tolerance to 
offset the ways before simplifying. At the time, I couldn't find such a 
beast in JOSM, so I used QGIS to do it.

What happened to change my mind was further discussion here about 
administrative boundaries, and the way that the offset ways looked 
around the corridors that were cut out of some areas for existing roads 
and railroads. I've been sporadically changing the borders from offset 
ways to shared ways. You can see a partly-done example at 
https://www.openstreetmap.org/#map=16/43.8523/-74.2274 where the west 
side of Gooley Club Road is conflated and shared, while the east side is 
not. That's actually a 'not-too-bad' example since the Primitive Area 
corridor extends a hundred feet (~30 m) from the road centerline on 
either side. (Gotta fix the road designation, too - it's yet another 
TIGER Residential!. Grrr.) The corridor at 
https://www.openstreetmap.org/#map=16/44.0071/-73.9362 applies 
'Primitive Area' protection to a three-rod right-of-way, and there was 
absolutely no way to get the ways simplified and aligned without 
conflating them (and in that case, why not make them a shared way?)

I still think my approach was valid for the initial import, particularly 
since the boundaries in the source data were drawn so as to require 
manual conflation otherwise. I discussed this issue at the time in 
'imports' and heard no complaints. In fact, one commenter thought that 
offsetting the ways automatically was fairly clever. For that reason, I 
haven't made the effort to go back and tidy everything. Still, if I 
happen to be maintaining an offset boundary for other reasons, I'll 
generally replace it with a shared way.

> PS: This has been a most beneficial conversation. I feel enlightened.

That's gratifying. The more people who understand how multipolygons help 
with this sort of thing, the more we'll be able to dispel the idea that 
they're unworkable or unmaintainable.