I think the other main issue we have is credability and reliablity. Practically all Ottawa road network is based on CANVEC imports. French versions of the names have since been added. Delete the CANVEC changeset that imported them and you lose all the bilingual capabilities we have worked hard to put in place. At the moment OSM is the only system I know that can display the Ottawa street names in either English or French.
It's not fashionable to think that people use our maps or think they come to rely on them but they do and the data that is in them is important to them. Stats Canada is hoping to use OpenStreetMap as input to some of its surveys. We have been working with others such as metrolink to import addresses which was done with agreement from the local community, with care and I think it has enriched the map from both our points of view. If OSM gets the reputation for this week the data is there and next week its gone then our reputation goes with it and probably many of our mappers as well. In Germany I understand you have many more mappers per cm and dislike imports, we don't. If the Canvec data is deleted what is left? Practically nothing. In parts of Africa OSM is the only map available strangely enough in parts of Canada it is still the best available. If Michael wishes to pop over and map Canada on a bicycle with a hand held GPS device in the traditional manner I'm sure we can find him a few places to sleep in the big cities bit further afield he'll need a tent and depending on the weather a can of mosquito repellent or skis. It may take him a few decades. Cheerio John On 1 September 2016 at 08:54, James <james2...@gmail.com> wrote: > 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
