[Talk-us] Multipolygonizing

Gleb Smirnoff glebius at glebi.us
Mon Nov 20 19:36:48 UTC 2017


  Hi Steve,

that was a long rant, I enjoyed reading it. Your retelling of my
words is way better than my original text, which you could quote.
I regret that I yet can't produce such a good text in English.
That's why often for me it is easier to yield rather than argue
and stand my position.

TL;DR version of my reply: I'm not going to touch OSM data in USA
anymore.

A longer version (I'll try). I assume we all agree that overlapping
or not reaching polygons where there is adjacency on the ground is
wrong. So how can we properly express adjacency? The simple way is
to run two polygons through the same subset of nodes. The advanced
is to separate this subset into a single line, which will now
belong to two multipolygons. I will try to convince you that using
advanced is easier, when it comes to "heavy" objects, like landuse=
or natural=. Imagine someone has mapped a forest, with a good
detail, precisely following its border with a farmland. Now you
want to map this farmland. In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.

Yes, advanced multipolygons is a professional tool, and newcomers
may find it confusing. Moreover, seasoned mappers who have spent
lot of time may in JOSM, but never encountered them, may also find
it difficult initially. Replies on this thread confirm that. But,
please, guys, don't refuse to learn something new, simply because
it is difficult! C++ is more difficult than Visual Basic, so let's
call it "terrible"? Come on, JOSM itself is difficult, but everyone
who groked JOSM, never returns to Potlach.

Look at Frederik Ramm's reply on this thread. One of the longest
term OSM contributors and member of OSMF Board supports multipolygons.
Doesn't that doubt your conviction? Try it out, before refusing it.

P.S. I know that my attempt to convince you would be as fruitless
as if I tried to convince you to use metric units :)

On Mon, Nov 20, 2017 at 09:58:53AM -0800, OSM Volunteer stevea wrote:
O> I very much agree with Douglas and Rihards that glebius' mapping is (around here) unusual, "terrible" and difficult to parse, even for experienced mappers who have been mapping for most of the history of OSM, like me.  Glebius is right in my backyard and I've found his coastal "restructurings" (e.g. http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often overwriting correct official (county GIS imported) data simply to not "share some nodes" or "improve the mess."  He claims that "the consensus in Russia is that advanced polygons is the way to go."  Well, not here, I assure both Glebuis and the talk-us list of that unequivocally.
O> 
O> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has not yet been built into JOSM's base code!) called "reltoolbox."  It promulgates what he calls "advanced multipolygons" and in the below-noted changeset acknowledges that he believes these "became a world wide consensus," but of course, they have not.  Glebius has glibly assumed reltoolbox and its resulting data is widespread, when in fact it is not:  neither locally, regionally, nor continentally.  He further says the "quality of OSM data in USA is much worse than in other countries" when in fact, my small county of Santa Cruz (through a wiki-documented process of both importing local government landuse polygons and painfully though lovingly improving them over three revisions and many years) actually won a Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  Well, before glebius snarled up a perfectly geometrically valid coastline and many of its landuse polygons, amenities, parks, marinas and recreation areas in Santa Cruz before I manually reverted a good number of his "fixes."
O> 
O> Glebius may believe he is "saving data" by "reducing overlapping nodes," but the added complexity to do this in multipolygons is distinctly confusing to many (most) OSM volunteers, especially beginners who find multipolygons confusing or intimidating.  I'm not saying glebius' practices or resulting data are wrong, but rather that when they overwrite perfectly already-correct data, his time is likely better spent on other OSM tasks.  Especially when he rudely calls correct and even award-winning data "a mess."
O> 
O> Please, glebius, don't do this here.  Everybody else in our community find your submissions to be confusing and difficult to maintain, this practice is ANYTHING BUT widespread (here in North America), you are overwriting valid data in a way that makes it nearly impossible to update with better data (especially when part of import 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 <doughembry at 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 <richlv at 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



More information about the Talk-us mailing list