Re: [Talk-us] Multipolygonizing

2017-11-21 Thread Gleb Smirnoff
  Steve,

On Mon, Nov 20, 2017 at 04:34:18PM -0800, OSM Volunteer stevea wrote:
O> If the reltoolbox plug-in as as powerful as I am beginning to understand it 
may be (I appreciate the introduction, Gleb), and given my agreement that 
certain use cases (especially landuse) benefit greatly from multipolygonized 
boundaries (they do), I actually CAN imagine that the SCCGIS V4 landuse import 
data (in 2019 or 2020) could become multipolygon.  This likely would involve a 
pre-upload translation of polygon data into mulitipolygon using the tool, then 
conflation (which has to be done anyway).  Except, we upload multipolygons as 
we delete existing polygons during the conflation-and-upload phase.
O> 
O> I wanted to offer that bright spot of hope to anybody's lingering beliefs 
that I am "mule-entrenched" in my beliefs that existing polygons are always 
superior.  They are not.  They make updates harder, but I think I can get over 
that, as I can be convinced that "once done, the time investment is worth it" 
for the future benefits that multipolygons bring.

Okay, I will withhold myself from touching polygons in the Santa Cruz County
for next couple of years, and let's see how your future experience with
SCCGIS goes on. We can get back to this question later in scope of Santa Cruz.

Meanwhile, do I understand that my initial understanding of strong consensus
against multipolygons in the USA overall was wrong reading? First few emails
in the thread made me think so.

I'd like to continue working on coastline, and map all remaining SMRs and
later maintain them. I also want keep using multipolygons in any regular
edits. Are there any objections?

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Multipolygonizing

2017-11-20 Thread Gleb Smirnoff
  Kevin,

On Mon, Nov 20, 2017 at 04:29:56PM -0500, Kevin Kenny wrote:
K> (3) Ease of editing (for better-informed or better-tooled users). At
K> least for me, working in JOSM, I find updating a mesh of multipolygons
K> with shared ways to be fairly straightforward. Split the ways at any
K> new corners, draw any new ways, update the touching regions, delete
K> any obsolete ways. Sure, it's a different workflow than the one for
K> simple polygons, but for that workflow, I find myself retracing over
K> long sets of points, or else splitting, duplicating, reversing and
K> rejoining ways. The duplicated ways are difficult to work with, since
K> they share all the points, and I have to puzzle over some pretty
K> subtle things to understand which copy I'm working with. By contrast,
K> the split and joined ways in a shared-ways structure always have
K> distinct geometry.

Thanks for this paragraph! This was text that was right on my tongue,
but I failed to wordsmith it properly.

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Multipolygonizing

2017-11-20 Thread Gleb Smirnoff
On Mon, Nov 20, 2017 at 02:13:44PM -0800, OSM Volunteer stevea wrote:
O> Plug-ins that offer "power tools" beyond that?  Well, caveat usor.

Note that a large part of current JOSM base functionality before was
in plugins. So, doesn't make sense to diminish some tool because it
isn't in base. Whether some code goes into JOSM or stays as plugin is
driven by two things: 1) number of plugin users 2) willingness of plugin
author to yield his code to JOSM repo, meaning disown his code. And
for many people that also means lose commit access to their code.

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Multipolygonizing

2017-11-20 Thread Gleb Smirnoff
On Mon, Nov 20, 2017 at 11:43:34AM -0800, Mark Wagner wrote:
M> > (I couldn't for the life of  me figure out how to add a way to a
M> > relation!)
M> 
M> Select a way currently part of the relation.  Shift-click on the way
M> you want to add.  Select "Update multipolygon" from the "Tools" menu,
M> or hit Ctrl+Shift+B.  Simple.
M> 
M> Of course, this only works for ordinary relations.  If the way you
M> clicked on is shared by two or more relations, you need to go
M> through the far more complicated method of playing with the
M> relation-editor dialog.

Or use "reltoolbox" plugin, where there is a notion of current  
 
relation, and while you got your relation selected as current,  
 
adding or removing objects to it is clicking "+" or "-" icon on 
 
the sidebar, having object selected. For multipolygons it will also 
     
set "outer" or "inner" role automatically.  

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Multipolygonizing

2017-11-20 Thread Gleb Smirnoff
port updates) and whatever small cost you believe you are saving 
in either elegance or the amount of data in the map is very much outweighed by 
"simpler is better."  Simple, while it may share a few nodes or overlap some 
ways, isn't wrong, it is far easier to understand and maintain, especially for 
novice mappers, and ESPECIALLY when updates to imported data essentially rely 
on the "simple polygon" paradigm which already works so well in our map.
O> 
O> With respect,
O> SteveA
O> California
O> 
O> 
O> Douglas Hembry <doughem...@hotmail.com> writes:
O> > Greetings everyone,
O> > I've just had a short changeset discussion with mapper glebius prompted 
O> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My 
O> > understanding is that the map of this stretch of coastline has been 
O> > restructured to avoid adjacent ways that share nodes. Accordingly, only 
O> > a single way ever connects any set of nodes, and the single way 
O> > participates, if necessary, in multiple relations. A result of this is 
O> > that in a high density area like downtown Monterey Bay many small areas 
O> > like building footprints or pedestrian areas are defined as distinct 
O> > multipolygons, with several ways (outers) making up the outline. An 
O> > example at:
O> > 
O> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045
O> > 
O> > (look at Hovden Way near the top, or the outline of 700 Cannery Row, 
O> > further down near Bubba Gump, comprised of seven outer ways)
O> > 
O> > glebius believes that this approach (with the help of the reltoolbox 
O> > JOSM plugin) is easier and less error-prone than having multiple simple 
O> > closed ways (eg, a building footprint and an adjacent pedestrian area) 
O> > sharing a set of nodes on their adjacent boundary. . (I hope I'm 
O> > representing this accurately, glebius will correct me if I'm getting it 
O> > wrong).
O> > 
O> > In my limited experience I've never encountered this before, and at 
O> > first sight I'm not convinced, particularly when considering future 
O> > maintenance. I told glebius that I wanted to find out  what the 
O> > community thought. Is this just one more valid optional way of mapping? 
O> > To be recommended for adoption if possible? Or to be avoided? Thoughts?
O> 
O> And Rihards <ric...@nakts.net> writes
O> > not an authoritative opinion : it's terrible. mapping contiguous areas
O> > as multipolygons results in data that is extremely hard to modify (think
O> > splitting landuse from a building) and is more than a minefield for 
newbies.
O> > 
O> > personally, i either redo these as separate ways when i have the time
O> > (original authors do not object as they have went either mad or out of
O> > energy after working with multipolygons too much), or give up and leave
O> > the area outdated - i don't have the skills to maintain that.
O> 
O> 

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us