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.
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
