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 <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
<mailto: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
<mailto: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
<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 joc...@remote.org <mailto:joc...@remote.org>
https://www.jochentopf.com/ +49-351-31778688
______________________________ _________________
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.or g/listinfo/talk-ca
<https://lists.openstreetmap.org/listinfo/talk-ca>
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto: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