<div dir="ltr">Kevin,<div><br></div><div>Okay, I see understand the offset now and the reasons for doing it but wow, such attention to detail is unusual in OSM mapping methinks. It was clever indeed. I just began to use QGIS but I'm a complete noobie at it. My only use of it so far has been to select and save into its own folder a single shapefile (for a national Park or National Wildlife Refuge) from a monster master file containing many individual shapefiles and even that took some searching on Youtube before I could  pull it off. That is one powerful program and learning how to use it isn't for the fainthearted. I love the Adirondacks region and fear that at my age and physical remove (Alaska for summers, Thailand winters) I'll never get a chance to hike there again. I'm glad you are working to map that wonderful wilderness area.</div><div><br></div><div>Gosh, it seems I'll never run out of questions. Here's yet another.</div><div><br></div><div>Someone added the Arctic National Wildlife Refuge to OSM but did not add a bunch of inner areas that aren't part of the refuge. I have the inners in a shapefile that end up in a separate layer when I import them into JOSM. I would like to add those inners to the existing boundary of the refuge. How can I transfer those inners from the shape layer to my data layer?</div><div><br></div><div>I've tried everything I can think of, including the special paste function inside the Relation Toolbox I learned about recently, but cannot get them to transfer <i>en masse</i>. I can copy and paste them one at a time but there are a few dozen tiny parcels. I also tried pasting them in place and then using JOSM's Search function to select "type:way untagged new" and that worked but it's clumsy.<br></div><div>There must be a better way to do this.</div><div><br></div><div>Thanks for your help, everyone.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 7:06 PM Kevin Kenny <<a href="mailto:kevin.b.kenny@gmail.com">kevin.b.kenny@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/29/18 2:48 AM, Dave Swarthout wrote:<br>
> But I'm still a bit confused about way:427547729. It's tagged as an <br>
> outer in the Wilcox WF multipolygon but it's located inside of an <br>
> enclosing way that's also an inner to the same relation. Does that <br>
> mean the inner/outer roles alternate as you add more and more "nested" <br>
> objects to the large multipolygon? For example,iIf there was a block <br>
> of private property inside way:427547729 would that be tagged as inner?<br>
<br>
You got it. That's why I chose that specific one as an example, to show <br>
how 'exclave within enclave' works. It's unusual, but it happens.<br>
<br>
> Just to touch on another topic because Kevin mentioned it. Sometimes <br>
> it's fairly obvious that certain boundaries were meant to follow a <br>
> riverbank or a coastline but at the present time don't. My first <br>
> impulse is to delete segments of the original boundary and replace <br>
> them with the more recent riverbank or coastline. That would probably <br>
> be considered wrong by some but seeing as we do not and can not <br>
> guarantee perfect accuracy with the placement of any boundary I don't <br>
> see it as an absolute no-no. Plus, many of these boundaries use <br>
> thousands of nodes that follow every little zig-zag to achieve legal <br>
> accuracy. IMO, OSM doesn't need that level of detail.<br>
><br>
> Opinions?<br>
<br>
I think you're right about the level of detail, and in fact I simplify <br>
ways fairly often.<br>
<br>
Because partly of confusing advice here, in 'imports', in talk-us, and <br>
on the Wiki, when I did the reimport of the Adirondack protected areas, <br>
I did them as separate ways. In order to be able to simplify them, I <br>
used an 'erode' operation (a 'buffer' operation with negative size) <br>
where the size was slightly larger than the simplification tolerance to <br>
offset the ways before simplifying. At the time, I couldn't find such a <br>
beast in JOSM, so I used QGIS to do it.<br>
<br>
What happened to change my mind was further discussion here about <br>
administrative boundaries, and the way that the offset ways looked <br>
around the corridors that were cut out of some areas for existing roads <br>
and railroads. I've been sporadically changing the borders from offset <br>
ways to shared ways. You can see a partly-done example at <br>
<a href="https://www.openstreetmap.org/#map=16/43.8523/-74.2274" rel="noreferrer" target="_blank">https://www.openstreetmap.org/#map=16/43.8523/-74.2274</a> where the west <br>
side of Gooley Club Road is conflated and shared, while the east side is <br>
not. That's actually a 'not-too-bad' example since the Primitive Area <br>
corridor extends a hundred feet (~30 m) from the road centerline on <br>
either side. (Gotta fix the road designation, too - it's yet another <br>
TIGER Residential!. Grrr.) The corridor at <br>
<a href="https://www.openstreetmap.org/#map=16/44.0071/-73.9362" rel="noreferrer" target="_blank">https://www.openstreetmap.org/#map=16/44.0071/-73.9362</a> applies <br>
'Primitive Area' protection to a three-rod right-of-way, and there was <br>
absolutely no way to get the ways simplified and aligned without <br>
conflating them (and in that case, why not make them a shared way?)<br>
<br>
I still think my approach was valid for the initial import, particularly <br>
since the boundaries in the source data were drawn so as to require <br>
manual conflation otherwise. I discussed this issue at the time in <br>
'imports' and heard no complaints. In fact, one commenter thought that <br>
offsetting the ways automatically was fairly clever. For that reason, I <br>
haven't made the effort to go back and tidy everything. Still, if I <br>
happen to be maintaining an offset boundary for other reasons, I'll <br>
generally replace it with a shared way.<br>
<br>
> PS: This has been a most beneficial conversation. I feel enlightened.<br>
<br>
That's gratifying. The more people who understand how multipolygons help <br>
with this sort of thing, the more we'll be able to dispel the idea that <br>
they're unworkable or unmaintainable.<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dave Swarthout<br>Homer, Alaska<br>Chiang Mai, Thailand<br>Travel Blog at <a href="http://dswarthout.blogspot.com" target="_blank">http://dswarthout.blogspot.com</a></div></div>