[Talk-us] Multipolygonizing

[Evin Fairchild]

Yeah, using multipolygons for everything is quite overkill, and it
certainly does overcomplicate things, and not just for new users, but for
experienced users as well. I mean, if it requires some plugin that I've
never heard of in JOSM to easily edit it, then it's too complicated. I
typically prefer using Potlatch 2 to edit OSM because I find JOSM to be
really user-unfriendly, (I couldn't for the life of me figure out how to
add a way to a relation!) so I prefer that things are kept simple as
possible for idiots like me.

-Evin (compdude)

On Nov 20, 2017 9:59 AM, "OSM Volunteer stevea" <steveaOSM at softworkers.com>
wrote:

> 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.
>
> 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."
>
> 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."
>
> 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.
>
> With respect,
> SteveA
> California
>
>
> Douglas Hembry <doughembry at hotmail.com> writes:
> > Greetings everyone,
> > I've just had a short changeset discussion with mapper glebius prompted
> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My
> > understanding is that the map of this stretch of coastline has been
> > restructured to avoid adjacent ways that share nodes. Accordingly, only
> > a single way ever connects any set of nodes, and the single way
> > participates, if necessary, in multiple relations. A result of this is
> > that in a high density area like downtown Monterey Bay many small areas
> > like building footprints or pedestrian areas are defined as distinct
> > multipolygons, with several ways (outers) making up the outline. An
> > example at:
> >
> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> >
> > (look at Hovden Way near the top, or the outline of 700 Cannery Row,
> > further down near Bubba Gump, comprised of seven outer ways)
> >
> > glebius believes that this approach (with the help of the reltoolbox
> > JOSM plugin) is easier and less error-prone than having multiple simple
> > closed ways (eg, a building footprint and an adjacent pedestrian area)
> > sharing a set of nodes on their adjacent boundary. . (I hope I'm
> > representing this accurately, glebius will correct me if I'm getting it
> > wrong).
> >
> > In my limited experience I've never encountered this before, and at
> > first sight I'm not convinced, particularly when considering future
> > maintenance. I told glebius that I wanted to find out  what the
> > community thought. Is this just one more valid optional way of mapping?
> > To be recommended for adoption if possible? Or to be avoided? Thoughts?
>
> And Rihards <richlv at nakts.net> writes
> > not an authoritative opinion : it's terrible. mapping contiguous areas
> > as multipolygons results in data that is extremely hard to modify (think
> > splitting landuse from a building) and is more than a minefield for
> newbies.
> >
> > personally, i either redo these as separate ways when i have the time
> > (original authors do not object as they have went either mad or out of
> > energy after working with multipolygons too much), or give up and leave
> > the area outdated - i don't have the skills to maintain that.
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20171120/d5dc10b0/attachment-0001.html>