https://i.imgur.com/8xKttYm.jpg
Image was ridiculously small On Fri, Jun 30, 2017 at 6:28 AM, James <[email protected]> wrote: > Example: > https://i.imgur.com/8xKttYm_d.jpg > > Represents multiple thousand square kilometers of forest/objects. To > actually be able to fix it correctly you NEED to launch JOSM in 64bit mode > with min/max memory values set or else it will crap out/freeze at 2GB of > memory. Now 1. JOSM doesnt document this ANYWHERE/IS VERY VERY HARD TO FIND > for the common user. I doubt many people know about the 2gb limit(other > than power mappers) . > Personally I find it very arrogant of you to say well, it's been a week > might as well contact the DWG and revert all of Canada, cause no one > replied to my email... not everyone has the experiance needed to merge down > polygons/relations on such a large object scale and very wide spread > throughout Canada > > > On Jun 30, 2017 6:12 AM, "James" <[email protected]> wrote: > > The problem that canvec has is multi polygons with different attributes > were stacked on top of eachother(i.e. hole in the forest that is also a > lake? That makes 2 polygons with same shape stacked one of top of > eachother... marshland+water+hole in forest? 3 polygons etc etc. Not that I > wouldnt live it fixed, but as someone that has "fixed" canvec data before > dropping it in, It's a massive undertaking and really complexe/abstract > thing to do. > > On Jun 30, 2017 3:54 AM, "Jochen Topf" <[email protected]> wrote: > > Hi! > > A week ago I wrote this email and nobody answered it yet. Does that > mean that nobody feels responsible for the import that created this data > and nobody here cares for this data? > > I see three ways forward: > * We do nothing. The broken data stays in OSM. Not a good solution, > because every user of the data has to work around this or handle the > complaints. > * The Canadian community steps up and fixes the data, automatically or > manually. > * We ask the Data Working Group to remove the broken import. > > Jochen > > On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote: > > Date: Thu, 22 Jun 2017 11:38:15 +0200 > > From: Jochen Topf <[email protected]> > > To: [email protected] > > Subject: [Talk-ca] Multipolygon problems > > > > Hi! > > > > In the last days the OpenStreetMap Carto Style 4.0 is being deployed on > > the OSMF tile servers. This new version of the style doesn't take > > old-style multipolygons (where the tags are on the outer ways instead of > > on the relation) into account any more. In a huge effort in the last > > months we have converted all old-style multipolygons to the modern > > tagging, so this is a good step! > > > > Unfortunately, as a side-effect of this change, many multipolygon > > relations now appear wrong on the map. This is the case for multipolygon > > relations that have the same tags on the relation as well as on (some of > > the) outer or inner ways. This is *wrong* tagging, and needs to be > > fixed. (Note that this always was wrong tagging, even before we > > deprecated old-style multipolygons, but the way the software worked with > > old-style multipolygons, this problem was not visible on the map. But > > now it is.) > > > > Here is an example: http://www.openstreetmap.org/relation/1330741 . As > > you can see (unless somebody fixes this :-) the clearing in the forest > > that should just have grass, also has tree symbols on it. In many other > > cases it is not this obvious, there are just islands in a river missing > > or so. > > > > There are about 50,000 cases like this worldwide, forests, waterways, > > all sorts of areas. But the worst problem is in Canada. There are about > > 15,000 affected relations, most from the CanVec imports. > > > > First, we have to make sure that there are no further imports of broken > > data. I hope the people who have done those imports (and might still > > continue) are here on this mailing list. If not please make them aware > > of this issue and/or put me in touch with them. Second, somebody needs > > to clean up the broken data, either automatically or manually. 99% of > > the data has not been changed since the import, so it might be feasible > > to do an automatic cleanup, but somebody has to do this. Otherwise we'll > > have to do a manual cleanup, through tools such as Maproulette and the > > OSM Inspector. I am currently in the process of creating Maproulette > > challenges for other areas of the planet, but will not do this for > > Canada at this time. Lets discuss this here first. > > > > I can provide OSM data extracts, statistics, etc. if somebody wants to > > look at the data. > > > > All of this is part of a larger effort to fix areas in OSM. See > > http://area.jochentopf.com/ for more information. There is also a thread > > on the talk mailinglist at > > https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html > > and this issue > > https://github.com/osmlab/fixing-polygons-in-osm/issues/36 . > > News of the effort are posted regularly to > > https://github.com/osmlab/fixing-polygons-in-osm/issues/15 . > > > > Jochen > > -- > > Jochen Topf [email protected] https://www.jochentopf.com/ > +49-351-31778688 > > > > _______________________________________________ > > Talk-ca mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/talk-ca > > -- > Jochen Topf [email protected] https://www.jochentopf.com/ > +49-351-31778688 > > _______________________________________________ > Talk-ca mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-ca > > > > -- 外に遊びに行こう！
_______________________________________________ Talk-ca mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-ca
