[Talk-ca] Multipolygon problems
Frank Steggink
steggink at steggink.org
Fri Jun 30 22:42:29 UTC 2017
Cette requête dans JOSM peut aider à cherches des chemins avec
natural=wood et role outer dans une relation: type:way natural=wood
role:outer
S.v.p. utiliser avec prudence ;)
This query in JOSM can help finding ways with natural=wood and role
outer in a relation: type:way natural=wood role:outer
Please use with caution ;)
Frank
On 30-06-2017 23:25, Pierre Béland wrote:
> translation follows ...
>
> James
> la 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
> <https://ssl.microsofttranslator.com/bv.aspx?from=&to=en&a=Http%3A%2F%2Foverpass-turbo.eu%2Fs%2Fq5K>
>
> 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 <james2432 at gmail.com>
> *À :* Jochen Topf <jochen at remote.org>
> *Cc :* Talk-CA OpenStreetMap <talk-ca at 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" <james2432 at gmail.com
> <mailto:james2432 at 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" <jochen at remote.org
> <mailto:jochen at 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
> <https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf>
>
> Here is one example where you can clearly see the problem:
> http://www.openstreetmap.org/r elation/541821
> <http://www.openstreetmap.org/relation/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 jochen at remote.org <mailto:jochen at remote.org>
> https://www.jochentopf.com/ +49-351-31778688
>
> ______________________________ _________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
> https://lists.openstreetmap.or g/listinfo/talk-ca
> <https://lists.openstreetmap.org/listinfo/talk-ca>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
More information about the Talk-ca
mailing list