I'm not sure if anyone from the DWG will do anything, but I agree he should be prevented from making changes to Canada. He thinks he knows better than the local mappers
On Sep 1, 2016 8:49 AM, "john whelan" <jwhelan0...@gmail.com> wrote: > It would appear that Michael has no appreciation of how we the local > community work or of how large Canada is nor does he appear to be able to > communicate with us and understand our concerns. > > I suggest we formally request that he is prevented from making any changes > within Canada and his reversals be reverted. > > The Canvec data was imported with the knowledge and support of the local > mappers and I think that's all that matters. > > Cheerio John > > On 1 September 2016 at 08:39, Michael Reichert <naka...@gmx.net> wrote: > >> Hi, >> >> Am 01.09.2016 um 01:21 schrieb dega: >> > On Aug 31, Daniel Bégin wrote: >> >> On the same topic, it has been suggested to split wooded areas in >> smaller >> >> chunks by using features on the ground as outer limits (mostly roads, >> >> streams, rivers) and get rid of arbitrary rectangles from Canvec. >> >> Is it something we are aiming at? >> > >> > The grid is an important source of problems. Here are some examples: >> > 1) If a lake is on the grid, it will be split in 2 parts. Each part >> will have >> > a name tag and and 2 identical names will be displayed on the map, one >> on each >> > part. This problem exist in thousands of lakes. I even saw a lake with a >> > triplicated name. >> > Merging the parts would require modifying 2 or more relations and many >> > importers don't do it (even if they use JOSM) because of the >> complexity. Some >> > have used a quick fix where they remove names from the parts and put it >> in a >> > POI. It looks fine but that's bad for database integrity. >> >> If someone does not merge two lakes because it is too "complex", he >> should evaluate if he is the right person to import such data. If an >> import contains much multipolygon relations, the people how import the >> data should know how they work, what can be done wrong, how to edit and >> how to fix them. :-/ >> >> > 2) A addr:interp way may be split in 2 parts. 2 consequences: >> > - the interpolation way become useless because it's now 2 different >> objects. >> > - the mid-point becomes 2 superposed nodes. Useless duplication. >> > >> > 3) A grid tile has a fixed size. It may be appropriate for unpopulated >> areas >> > but it is too large for urban areas where editors work at a high zoom >> level >> > (17 and up). It's easy to damage a relation without knowing it. >> > >> > But there are other problems (not related to the grid): >> > 4) the relations seem to be designed to be stand-alone. Thus the >> relation >> > borders don't share a way. They use 2 superposed ways. Useless >> duplication. >> > It's very confusing and we frequently alter the wrong way. >> > >> > 5) lakes are represented by 2 superposed identical objects, one for the >> hole >> > and one for the lake. If the hole happen to be on top, the name will >> not be >> > displayed. It's an unjustifiable complexity for the casual user. >> > I've also seen triplicated contour (one for the lake, on for the inner >> role >> > and one for the outer role) >> > >> > Yes, all these quirks can be fixed manually but it's time-consuming and >> error- >> > prone. >> >> What about reverting the tiles which have all these issues and seem to >> be uploaded with too few checks beforehand, run a better version of the >> preprocessor on the CanVec raw data and reimport them again? (That >> causes a loss of OSM history but an import changeset is not as much >> valueable than a manual changeset) >> >> > Ideally, the contour of a forest must not split any object and it's not >> > possible with a grid. >> > The sole advantage of a grid IMHO is to simplify the CanVec exports. >> >> What about replacing the grid by less artificial borders, e.g. roads, >> rivers, powerlines etc. If an area has too few of theses objects, >> artifical borders could be automatically drawn which are optimized to >> cut as few objects as possible into two parts. >> >> > Some years ago I would have proposed that someone write a guide "How to >> fix a >> > CanVec import". But now I would rather propose that someone write a >> "How to >> > pre-process a CanVec export before importing it into OSM". >> >> +1 >> >> All ongoing changesets which import CanVec data should either use an >> improved version of the preprocessor or should undergo the manual >> quality checks I described in my other emails and the changeset comments. >> >> Best regards >> >> Michael >> >> >> -- >> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten >> ausgenommen) >> I prefer GPG encryption of emails. (does not apply on mailing lists) >> >> >> >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ca >> >> > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
