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" <stevea...@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 <doughem...@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 <ric...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us