translation follows ... Jamesla requête overpass ci-dessous extrait pour un bbox les chemins avec role externe dans une relation et avec la même clé natural=wood que sur la relation. De là, il est facile d'effacer la clé en doublon.http://overpass-turbo.eu/s/q5K
Jochen, pour cette première extraction à l'aide de la requête overpass, je constate que la clé en doublon a été ajoutée à plusieurs reprises par un contributeur européen. Merci à lui de nous aider. Puis oui, il faut trouver des façons de progresser comme communauté, cela dans le respect de tous. Vous n'êtes pas le premier à venir dire que la carte est mal foutue au Canada. Cela est très démobilisant. Sur la liste talk-ca, nous discutons aussi en anglais et français. Si vous ne faites pas d'effort pour communiquer avec les francophones, vous diminuez encore davantage vos chances de mobiliser la communauté OSM. Il vaut mieux motiver les contributeurs et tenter de comprendre la réalité de grands espaces plus ou moins désertiques tels le nord du Canada, l'Amazonie et certains territoires d'Afrique et d'Asie (moins importants ??). Je me rappelle la réponse humanitaire du Mali en janvier 2013 où j'expliquais aux contributeurs des pays du nord qu'une route principale est toujours une route principale, même si elle est ensablée, en mauvaise état, non pavée. La carte, les classifications et les styles sont souvent pensés pour une réalité européenne. Ce n'est pas partout que l'on voit un réseau dense d'autoroutes. Regardez au zoom=5, la carte blanche au nord du Canada ou dans d'autres régions du monde peu denses. Essayez d'y repérer des villages, des routes (non pas des autoroutes), des mines, des barrages. Bien sûr, il y en a moins de facilités, commerces, fast-food :) Il y a au nord des villages à des centaines de kilomètres les uns des autres et sans route. Doit-on les ignorer?http://www.openstreetmap.org/#map=5/56.969/-83.979 cordialement ------------------------- James The following overpass query extracts the ways with external role in a relation and with the same key natural = wood as on the relation. From there it is easy to erase the duplicate key.Http://overpass-turbo.eu/s/q5K Jochen, on this first area that I extract data, I find that the duplicate key has been added several times by an European contributor. Thanks to him for helping us. And yes, we have to find ways to make progress as a community, with respect for all. You are not the first to come and say that the map is screwed up in Canada. This is very demobilizing. On the talk-CA list, we also discuss in English and French. If you do not make an effort to communicate with the Francophones, you will further reduce your chances of mobilizing the OSM community. It would be good also for the global community to try to understand the reality of large, more or less deserted spaces such as northern Canada, the Amazon and some territories of Africa and Asia. These areas look deserted ( less important ??), but believe me, they are not. I remember the Mali OSM humanitarian response in January 2013 where I explained to the contributors from northern countries that a major road is always a major road, even if it is sanded, in poor condition, unpaved. The map, classifications and styles are often thought for a European reality. It is not everywhere that we see a dense network of highways. Look at zoom = 5. We see almost nothing in northern Canada or in other areas of the world that are not very dense. Try to locate villages, roads (there are no motorways), mines, dams. Of course, there are less facilities, commerce, fast foods :) Some nordic villages are hundred of km apart. Should we ignore them? http://www.openstreetmap.org/#map=5/56.969/-83.979 regard Pierre De : James <james2...@gmail.com> À : Jochen Topf <joc...@remote.org> Cc : Talk-CA OpenStreetMap <talk-ca@openstreetmap.org> Envoyé le : vendredi 30 juin 2017 16h04 Objet : Re: [Talk-ca] Multipolygon problems If it's just removing tags, on inner polygons of a multipolygon, that should be manageable in itself... is there a way you are querying for said items without setting up a postgresql database? On Jun 30, 2017 3:57 PM, "James" <james2...@gmail.com> wrote: To be fair....your example is from Canvec 4.0.....that's reaaaaaaaaaaallly old....was it possible that was a way of tagging back in the days? Or was it created initially as a polygon and was later converted to a relation? Canvec 10.0 doesnt have the issues of double tagging, just overlapping On Jun 30, 2017 3:22 PM, "Jochen Topf" <joc...@remote.org> wrote: On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote: > Maybe I'm not understanding it, but in the OSM inspector [1] I just see one > case of old style multipolygon, in Manitoba. Last week, when you posted your > original message, I just saw one case in New Brunswick. IIRC, it was a park, > not even from the Canvec import. The types of problems I am talking about don't show up in the OSM inspector. This is not old-style multipolygons (where tags are on the outer ways and not on the relation), but multipolygons where the tags are on the relation AND on the ways. > In the OSM inspector other errors can be seen, but the most prevalent one is > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing > which seems urgent to me. > > Here is an example of a forest multipolygon, imported by me > (canvec_fsteggink). It is still version 1, but it has tags on the relation, > not on the rings (except for the quarries): [2] > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such > cases in the OSM inspector. > > So, I'd like to ask you to give a couple of examples where data imported > from Canvec is clearly wrong with regard to old style multipolygon tagging. Here are all cases in Canada (not only those from the imports): https://tmp.jochentopf.com/954 226a3acab882d28d8500ddef8203d/ same-tags-ca.pbf Here is one example where you can clearly see the problem: http://www.openstreetmap.org/r elation/541821 > When we have clear examples, then it might be easier to come up with a plan > how to fix it. But so far, I see absolutely no reason why Canada stands out > in a negative way. Yes, we all acknowledge that Canvec data is suboptimal, > but as others already have pointed out, mapping everything by hand in > especially remote areas is nearly impossible. Canada stands out in a negative way, because a) there are so many problems. Nearly a third of the cases worldwide are in Canada and b) most of these problems are probably caused by one little program, the program used to convert/import the CanVec data. Mapping Canada "by hand" might be difficult because it is such a huge country and there aren't that many mappers. But the same arguments goes for why you have to be extra careful importing data. If you break something, there are not enough people to fix it manually. And, yes, errors do happen. And if we find them, we fix them and move on. But errors from imports can be so huge there aren't enough people there to fix them manually. So I think it is the job of those who did the import in the first place, to fix their work. If you add data to OSM you take on a certain responsibility. If you add more data, you have a larger responsibility. But saying: We don't have the manpower, so we are taking a shortcut and then, when it turns out the shortcut wasn't so short after all, whining that you don't have the manpower to fix it. That can't be the excuse. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ______________________________ _________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.or g/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