Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet Philippe Verdy 
Non la cause le plus fréquente n'est pas qu'il manque un chemin mais qu'un
chemin a été scindé sans mettre à jour toutes les relations dépendantes.
Le chemin n'est donc pas effacé, il a conservé ses attributs, mais des
relations sont cassées quand même.
Les cas de suppression de chemins (ou suppression d'attributs) sont très
rares.

Cette anomalie arrive souvent par un usage incorrect de JOSM (oubli de
charger les relations dépendantes) quand on a chargé juste une partie des
relations et de leurs chemins enfants, puis qu'on modifie un de ces chemins
sans charger les autres relations), mais il y a des cas aussi avec tous les
autres éditeurs, y compris iD (même si c'est moins fréquent), car le
serveur ne retourne pas toujours à l'éditeur toutes les relations
dépendantes, même dans une zone de recherche géographique dont on charge
tous les éléments.

Pour diverses raisons (y compris des problèmes momentanés de liaison
Internet), il peut manquer ces relations (et il n'y a aucune indication de
cette incohérence puisque le nombre de relations parentes n'est pas indiqué
dans les métadonnées d'un objet, le contrôle de cohérence ne portant que
sur l'objet lui-même (tags, noeuds des chemins, et membres enfants des
relations) qui sont également les seules à affecter le numéro de version
d'un objet (et sa date de dernière modification) ou à indiquer le numéro de
changeset qui a pu l'affecter: il n'y a pas de propagation que ce soit en
amont ou en aval d'un objet vers un autre objet (donc également le
déplacement d'un noeud ou le changement de ses tags n'a aucune incidence
sur le versionnement de ses chemins ou relations parents).

Note bien que dans les pays supposés ne pas utiliser ces tags 'redondants"
on voit partout des anomalies sur les rendus où des frontières sont
invisibles. Cela affecte même Mapnik. la raison semble en être le coût
élevé pour aller chercher toutes les relations parentes d'un objet, et
notamment les relations frontières qui sont souvent très complexes et
lourdes en données (ne serait-ce qu'un "petit" pays comme la France à cause
de ses frontières maritimes, mais même pour l'Allemagne ou encore la Suisse
qui n'a pas de frontière maritime complique c'est un volume important du
fait de la précision des données. Et la complexité s'étant aussi aux
niveaux inférieurs (regarde par exemple la Bretagne).

Ce n'est pas aussi pathologique que tu le penses et il y a même une
exception totale concernant les lignes de côtes qui ne sont pas du tout
représentées par des relations fermées et qui imposent également un sens de
tracé, car sinon c'est beaucoup trop lourd en données.

Pour le reste les objets sont assez petits pour ne pas avoir besoin de
telles redondances: les frontières restent une exception même si pour elles
on a pu mettre des relations (en levant toutefois certaines barrières qui
existaient dans le nombre de membres par relations qui a du être relevé
notamment pour la France, les USA, le Canada ou la Russie, mais là encore
c'est très lourd de chercher si une frontière est une frontière nationale
de ces pays en chargeant ses relations membres et le serveur ne retourne
même pas toujours cette information quand on le lui demande et qu'il est un
peu trop chargé de travail).


Le 20 juillet 2017 à 22:13, marc marc  a écrit :

> Pour répondre brièvement
>
> Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > > cette redondance (partielle)
> > > est encore très pratique pour pas mal de recherches.
> > un exemple ?
> > Justement pour réparer quand une relation est cassée.
> si quelqu'un efface un chemin, la relation est cassée et tes tags de
> "secours" sont perdus également.
> quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon,
> on utilise les changeset pour "remonter" le temps.
> autre solution : réelles sauvegardes hors osm des relations critiques
> les limites des communes changent peu, c'est ultra efficace.
> C'est ce qui est fait il me semble pour les points géodésiques.
>
> > il y a encore des moteurs de rendu
> > qui ont besoin de cette redondance partielle, ne serait-ce que pour
> > représenter les "pointillés"
> D'autres pays voisins s'en passent très, jamais vu de problème de rendu
> des limites parfois très tortueuse qu'ils ont.
> Rédiges un rapport de bug si un rendu particulier a un soucis au lieu
> d'avoir des milliers de tag comme béquille.
>
> Bref, toutes les fonctionnalités que tu cites existent dans des pays
> n'utilisant pas ce système de tags dupliqués.
> Peut-être faudrait-il un jour se demander si leur utilité théorique
> n'est pas largement engloutie par la complexité que cela entraîne sur
> des stats aussi basique qu'une liste des noms des communes de France.
>
> D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet Jérôme Amagat 
je crois que le rendu osm fr se sert de ces tag admin_level sur les way et
c'est pour ça qu'il manque des morceaux de frontières sur le rendu à de
faible zoom. par exemple ici on voit des manques sur des pays d’Afrique :
http://tile.openstreetmap.fr/?zoom=5=-9.41895=26.29572=B00FF

Je viens de regarder très rapidement plusieurs frontières dans des pays
voisins et je suis à chaque fois tombé sur un way avec le tag admin_level=*

Le 20 juillet 2017 à 22:13, marc marc  a écrit :

> Pour répondre brièvement
>
> Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > > cette redondance (partielle)
> > > est encore très pratique pour pas mal de recherches.
> > un exemple ?
> > Justement pour réparer quand une relation est cassée.
> si quelqu'un efface un chemin, la relation est cassée et tes tags de
> "secours" sont perdus également.
> quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon,
> on utilise les changeset pour "remonter" le temps.
> autre solution : réelles sauvegardes hors osm des relations critiques
> les limites des communes changent peu, c'est ultra efficace.
> C'est ce qui est fait il me semble pour les points géodésiques.
>
> > il y a encore des moteurs de rendu
> > qui ont besoin de cette redondance partielle, ne serait-ce que pour
> > représenter les "pointillés"
> D'autres pays voisins s'en passent très, jamais vu de problème de rendu
> des limites parfois très tortueuse qu'ils ont.
> Rédiges un rapport de bug si un rendu particulier a un soucis au lieu
> d'avoir des milliers de tag comme béquille.
>
> Bref, toutes les fonctionnalités que tu cites existent dans des pays
> n'utilisant pas ce système de tags dupliqués.
> Peut-être faudrait-il un jour se demander si leur utilité théorique
> n'est pas largement engloutie par la complexité que cela entraîne sur
> des stats aussi basique qu'une liste des noms des communes de France.
>
> D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet marc marc 
Pour répondre brièvement

Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > cette redondance (partielle)
> > est encore très pratique pour pas mal de recherches.
> un exemple ?
> Justement pour réparer quand une relation est cassée.
si quelqu'un efface un chemin, la relation est cassée et tes tags de 
"secours" sont perdus également.
quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon, 
on utilise les changeset pour "remonter" le temps.
autre solution : réelles sauvegardes hors osm des relations critiques
les limites des communes changent peu, c'est ultra efficace.
C'est ce qui est fait il me semble pour les points géodésiques.

> il y a encore des moteurs de rendu 
> qui ont besoin de cette redondance partielle, ne serait-ce que pour 
> représenter les "pointillés"
D'autres pays voisins s'en passent très, jamais vu de problème de rendu 
des limites parfois très tortueuse qu'ils ont.
Rédiges un rapport de bug si un rendu particulier a un soucis au lieu 
d'avoir des milliers de tag comme béquille.

Bref, toutes les fonctionnalités que tu cites existent dans des pays 
n'utilisant pas ce système de tags dupliqués.
Peut-être faudrait-il un jour se demander si leur utilité théorique 
n'est pas largement engloutie par la complexité que cela entraîne sur 
des stats aussi basique qu'une liste des noms des communes de France.

D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet Philippe Verdy 
Le 20 juillet 2017 à 13:03, marc marc  a écrit :

> Le 19. 07. 17 à 13:59, David Crochet a écrit :
> Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> > cette redondance (partielle)
> > est encore très pratique pour pas mal de recherches.
> un exemple ?
>

Justement pour réparer quand une relation est cassée. C'est juste
informatif de ce qui pouvait être là avant et évite de sélectionner le
mauvais chemin à reprendre pour réparer les relations cassées.

De plus les requêtes sur les relations parentes d'un chemin ne fonctionnent
pas toujours (le serveur en oublie très souvent dans ses résultats!) ou
sont très lentes. Et il y a encore des moteurs de rendu qui ont besoin de
cette redondance partielle, ne serait-ce que pour représenter les
"pointillés" et aussi parce que certaines frontières sont incomplètes (et
ne seront jamais complètement fermées). Le modèle a encore besoin de cette
redondance partielle.

En revanche pour des relations administratives actuelles (je ne parle pas
des autres types de frontières), il devrait toujours y avoir une relation
fermée: un simple tag admin_level sur un chemin est toujours insuffisant
pour décrire la frontière, c'est toujours une relation qu'on ira chercher.
Reste à savoir comment ces relations sont renseignées et là tu es tombé sur
une relation mal fichue qui n'avait rien à voir avec une frontière mais
très mal taguée voire pas du tout: c'est la conversion de cette relation
qui a entrainé un effet de bord en créant une pseudo-frontière en allant
chercher des tags manquants n'importe où: cela ne devrait jamais avoir
lieu, ce traitement de "compatibilité" devrait être en liste noire pour
certains tags et notamment pour "admin_level" qui ne peut pas être récupéré
s'il n'y a pas un tag "boundary=administrative" correspondant et déjà
présent dans la relation où un admin_level manquerait:

il faudrait modifier l'outil de conversion SQL vers GIS pour qu'il bannisse
la récupération ascendante des tags "admin_level" manquants. Ce type de
traitement a surtout servi pour les multipolygone de landuse (qui ont
normalement été tous nettoyés masivement récemment mais il en réapparaît ça
et là). Tant pis si ça veut dire que certains polygones disparaissent des
rendus ou des recherches faute de tags suffisants. Et tant pis si des
polygones sont incomplets (mal fermés): on peut s'en sortir en "bouchant
les trous" par des segments fictifs mais sans ajouter aucun autre tag ni
chercher à les importer d'autres chemins voisins, et le rendu sera plus ou
moins corrigé partiellement avec des "artefacts" visibles restant près de
ces trous (mais ce type d'anomalie est déjà pris en compte dans les outils
de contrôle qualité qui les recherchent pour les signaler car la plupart
des trous sont maintenant minuscules et pas faciles à débusquer sur la
carte sauf en tombant dessus à un niveau de zoom avancé et à condition que
le rendu soit à jour à ce niveau, ce qui prend du temps)

Mais on a des cas particuliers dans certaines régions où les frontières
sont contestées par plusieurs entités qui se recouvrent partiellement (les
exemples sont en fait nombreux sur la carte du monde et on a même des cas
sur les frontières françaises avec nos voisins, notamment avec l'Italie ou
en outre-mer, bien que là ce soit surtout les frontières maritimes qui sont
beaucoup plus simples et dont les chemins ne servent pas aussi à délimiter
autre chose).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet marc marc 
Le 19. 07. 17 à 13:59, David Crochet a écrit :
> si ce chemin fait parti de plusieurs relations, 
> quelle étiquette va  t'il prendre de quel relation ?
Selon moi aucun tag de relation ne devrait être dupliqué sur le chemin.
Le chemin a les tag qui décrivent sa fonction en tant que chemin.
La limite administrative est décrite par les tags sur les relations.
Tu peux toujours et facilement trouver si un chemin est une limite 
administrative (il fait partie d'une relation "boundary")
A l'inverse, trouver les chemins qui n'ont pas de parent décrivant la 
même chose est complexe, voir fin de message-

Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> Tu peux penser que taguer les admin_level sur les chemins membres
> est redondant,
Oui je pense que c'est redondant voir même sémantiquement erroné.
Par analogie pour décrire une foret entouré par 4 chemins. la 
description de la forêt est uniquement sur le polygone.
On ne tag par chaque chemin comme étant une chemin+limite de forêt.
Autre analogie, les rues utilisée par une ligne de bus n'ont aucun tag 
disant "ceci est un morceau de ligne de bus no 42". l'info est 
uniquement présente sur la relation.

Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> cette redondance (partielle)
> est encore très pratique pour pas mal de recherches.
un exemple ?

Le 20. 07. 17 à 01:50, Jérôme Amagat a écrit :
 > (ce admin_level sur les way en france fait doublon et est inutile car
 > toutes les relations représentant les différent admin_level (commune
 > arrondissement departement...) existent et on peut en déduire pour
 > chaque way quelle frontière c'est. Mais c'est la règle actuellement)
Merci pour ce bon résumé. je n'y toucherais donc pas.

Du coup, une requête basique comme lister le nom de toutes les communes 
est complexe puis que le même tag va à la fois faire ressortir des 
chemins individuels constituant les frontières communales et les petites 
communes décrites par un chemin fermé.
il faut donc lister tous les éléments qui ont le tag.
Il faut en retirer les chemins ayant un tag dupliqué càd si le chemin 
fait partie d'un polygone ayant le même tag.
Idem si le chemin fait partie d'une relation ayant le même tag.
Et c'est insuffisant puis qu'on pourrait avoir une relation de polygone 
ou une relation de relation...
Quelqu'un a déjà ce genre de requête sous le coude ? histoire de ne pas 
réinventer la roue...

Merci pour vos éclaircissements, sans jeux de mot :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet Jérôme Amagat 
sur une relation, le tag admin_level donne le niveau hiérarchique
administratif donc en france permet de savoir si la relation représente une
commune, departement, region, ...
mais ce tag est aussi utiliser sur tous les way frontières donc sur tous
les way qui font partie d'une relation admin_level et on prend le plus
petit nombre sur ces relations pour mettre dans le admin_level=* de la
frontière. Cela permet de savoir que tel way fermé ou non est une frontière
entre 2 communes, département, région ...
Normalement tous les way faisant partie d'une relation
boundary=administrative doivent avoir un tag admin_level

(ce admin_level sur les way en france fait doublon et est inutile car
toutes les relations représentant les différent admin_level (commune
arrondissement departement...) existent et on peut en déduire pour chaque
way quelle frontière c'est. Mais c'est la règle actuellement)


Le 19 juillet 2017 à 13:49, marc marc  a écrit :

> Je comprend très bien la fusion d'un chemin avec la limite
> administrative, c'est très courant et très pratique,
> le problème n'est pas là.
>
> Une département est décrit par une area via une relation utilisant de
> nombreux chemin. Dans le cas de mon mon premier exemple
> https://www.openstreetmap.org/relation/7401
> Le tag sur la relation dit que cette area est un département.
> jusque là c'est parfaitement juste.
>
> https://www.openstreetmap.org/way/457978185
> mais pourquoi est-ce que ce bout de chemin est tagé en admin_level ?
> quelques mètres plus loin il ne l'est plus
> quelques metres avant non plus
> ce chemin est un simple chemin, ce n'est pas un département, ce n'est
> qu'un membre de la relation qui décrit le département.
> le tag "département" est sur la relation,
> il n'y a aucun sens qu'un élément individuels de la relation ai lui
> aussi le tag admin_level
> sinon à te lire, si ce tag était justifié sur un chemin, il devrait
> l'être aussi sur le bout de chemin quelques mètres plus loin.
>
> c'est comme pour un itinéraire de bus. tu met les tag de la ligne de bus
> uniquement sur la relation, tu ne dupliques pas une partie des tag de la
> relation sur un chemin individuel.
>
> est-ce que c'est plus clair ainsi dit ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet osm . sanspourriel 

Un gros tas de tels polygones sont les imports CLC (tu y as fait allusion).

Par contre beaucoup existent encore en France (les terres associées aux 
fermes).


Comme tu as de gros bousins à la topographie imprécise et devenue fausse 
(grignotage d'environ un département depuis l'import) les reprendre n'a 
pas grand sens.


J'ai un doute ces données ont été supprimées ? Par chez moi je ne les 
retrouve effectivement pas.


Quant aux niveaux administratifs, trouver le bon niveau c'est juste 
prendre le max des valeurs des relations (si une frontière sert une 
limite de commune et une limite de département on la voit comme une 
limite départementale), je ne vois pas de cas où la valeur se justifie 
au niveau d'un way s'il fait partie d'une relation de type 
administratif. Sinon il doit être fermé.


admin_level=3 sur une relation ça veut dire que les chemins de la 
relation sont au moins de niveau 3.


admin_level=5 sur une relation ça veut dire que les chemins de la 
relation sont au moins de niveau 5.


Si un chemin fait partie de ces deux relations alors il est représenté 
comme admin_level=3 au moins.



Le 19/07/2017 à 14:11, Philippe Verdy - verd...@wanadoo.fr a écrit :
Là on tombe sur un vieux traitement effectué par la conversion OSM 
vers GIS: c'est lui qui essaye de "deviner" les tags manquants des 
relations en allant les chercher sur les membres afin de produire un 
polygone GIS avec assez de tags significatifs.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet Philippe Verdy 
Là on tombe sur un vieux traitement effectué par la conversion OSM vers
GIS: c'est lui qui essaye de "deviner" les tags manquants des relations en
allant les chercher sur les membres afin de produire un polygone GIS avec
assez de tags significatifs.

Il y a eu des discussions récemment pour supprimer à terme ce traitement
(issu d'anciennes façons de taguer partiellement les multipolygones ou de
ne pas les taguer du tout). Ce traitement devrait être supprimé maintenant
(le nettoyage de la base a eu lieu massivement sur ce sujet, mais il en
reste encore par endroit de ces relations mal fichues et incomplètes assez
souvent tant dans leurs tags que dan la liste de leurs membres qui ne
décrivent pas des contours fermés).

Tu peux penser que taguer les admin_level sur les chemins membres est
redondant, certes mais ce n'est pas suffisant pour transformer une chemin
en polygone frontière valide (d'autant plus qu'il y a plusieurs admin_level
candidats : la convention prise est de prendre la plus petite valeur parmi
les candidats). Mais cette redondance (partielle) est encore très pratique
pour pas mal de recherches.

Ce n'est en tout cas pas le tag admin_level sur un chemin qui en fait une
frontière. Les conditions nécessaires et suffisantes ne sont pas réunies
par ce seul fait et la velur indiqué sur le cemin n'est pas nécessairement
celle applicable aux polygones frontières qui doivent avoir leurs propres
tags de classification indépendamment des chemins membres référencés.


Le 19 juillet 2017 à 13:59, David Crochet  a écrit :

> Bonjour
>
>
> Le 19/07/2017 à 13:49, marc marc a écrit :
>
>> est-ce que c'est plus clair ainsi dit ?
>>
>
> Mais si ce chemin fait parti de plusieurs relations, quelle étiquette va
> t'il prendre de quel relation ? Le système ne peut pas le lui dire, donc on
> le lui dit.
>
> Si une limitre administrative est "département", elle est "arrondisement",
> elle est "canton", et elle est "commune". Ces informations là seront dans
> chacune des relations.
>
> Pour dire que ce bout de chemin (donc pas l'avant ni l'après) est une
> limite administrative, on le lui dit et on lui attribut le niveau
> administrative de niveau le plus "élevé" si l'on peut lui donner une
> hiérarchie.
>
> Cordialement
>
> --
> David Crochet
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet David Crochet 

Bonjour


Le 19/07/2017 à 13:49, marc marc a écrit :

est-ce que c'est plus clair ainsi dit ?


Mais si ce chemin fait parti de plusieurs relations, quelle étiquette va 
t'il prendre de quel relation ? Le système ne peut pas le lui dire, donc 
on le lui dit.


Si une limitre administrative est "département", elle est 
"arrondisement", elle est "canton", et elle est "commune". Ces 
informations là seront dans chacune des relations.


Pour dire que ce bout de chemin (donc pas l'avant ni l'après) est une 
limite administrative, on le lui dit et on lui attribut le niveau 
administrative de niveau le plus "élevé" si l'on peut lui donner une 
hiérarchie.


Cordialement

--
David Crochet


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet marc marc 
Je comprend très bien la fusion d'un chemin avec la limite 
administrative, c'est très courant et très pratique,
le problème n'est pas là.

Une département est décrit par une area via une relation utilisant de 
nombreux chemin. Dans le cas de mon mon premier exemple
https://www.openstreetmap.org/relation/7401
Le tag sur la relation dit que cette area est un département.
jusque là c'est parfaitement juste.

https://www.openstreetmap.org/way/457978185
mais pourquoi est-ce que ce bout de chemin est tagé en admin_level ?
quelques mètres plus loin il ne l'est plus
quelques metres avant non plus
ce chemin est un simple chemin, ce n'est pas un département, ce n'est 
qu'un membre de la relation qui décrit le département.
le tag "département" est sur la relation,
il n'y a aucun sens qu'un élément individuels de la relation ai lui 
aussi le tag admin_level
sinon à te lire, si ce tag était justifié sur un chemin, il devrait 
l'être aussi sur le bout de chemin quelques mètres plus loin.

c'est comme pour un itinéraire de bus. tu met les tag de la ligne de bus 
uniquement sur la relation, tu ne dupliques pas une partie des tag de la 
relation sur un chemin individuel.

est-ce que c'est plus clair ainsi dit ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet Philippe Verdy 
En particulier la relation à problème est comme celle-ci
https://www.openstreetmap.org/relation/2606660#map=13/47.3181/-1.7153

Là on a un multipolygone complètement invalide, sans tag, et non fermé
(pour un vieux landuse de CORINE mal découpé et mal tagué): on tombe sur le
cas où la conversion OSM vers GIS essaye d'interpréter ce polygone mal
fichu en cherchant des tags sur les chemins membres.

C'est cette relation qu'il faut corriger. Le chemin en question en revanche:

https://www.openstreetmap.org/way/30828584

est correctement tagué aussi en tant que frontière et est bien membre d'une
dizaine de relations frontières tout à fait correctes.



Le 19 juillet 2017 à 13:22, Philippe Verdy  a écrit :

> Je crois que tu comprends mal... Osmose ne fais pas comme ça. Non pas
> besoin de chemin fermé, les admin_level sur les chemins ne sont pas
> invalides mais hautement recommandés, mais ils doivent effectivement être
> membres d'une relation boundary pour prendre sens en tant qu'objet
> "département" d'autant plus que cette valeur est surtout destiné à pas mal
> de moterus de rendus pour afficher les pointillés qui sinon disparaissent.
>
> Bref ce que tu demandes est complètement faux, tu as mal lu la doc.
>
> Ici tu as un chemin qui est AUSSI une partie membre d'une frontière
> administrative. C'est un cas très fréquent sur les routes et rivières: la
> fusion des chemins superposés n'est pas fausse, c'est même une
> recommandation. Si ces tracés sont différents on les détache et il n'y a
> plus de fusion des tags non plus.
>
> Nulle part ce tag indique "qu'une route se prend pour un département". Si
> cela arrive c'est parce qu'il y a d'autres relations qui ont été taguée, là
> par erreur, comme des frontières adminsitratives et reprennent ce chemin.
> Ce n'est pas le chemin qui est en cause mais ces autres relations.
>
>
> Le 19 juillet 2017 à 12:34, marc marc  a écrit
> :
>
>> Bonjour,
>>
>> Il me semble qu'il y a de nombreuses anomalies avec ce tag
>>
>> exemple
>> https://www.openstreetmap.org/way/457978185
>> un bout de chemin en forêt qui se prend pour un département
>> depuis le changeset 44193985
>>
>> https://www.openstreetmap.org/way/30828584
>> une route qui se prend pour un arrondissement
>> difficile de retrouver le changeset problématique. cela semble avoir
>> lieu y a 4 ans sur le changeset 14088954
>>
>> en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
>> Sans doute une partie sont réellement des limites communales constitué
>> d'un seul chemin qui fait un boucle.
>> mais en piochant pour 10 pour vérif, ce sont des chemins qui ne
>> devraient pas avoir le tag de limite communale en tant que tel
>> exemple http://www.openstreetmap.org/way/221500211
>> exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
>> serrais-ce un import qui a foiré ?
>> un habitude jadis de dupliquer les tag sur la commune sur chaque chemin
>> de sa frontière ?
>>
>> osmose détecte 3 bouts erronés parce qu'inclus dans une relation
>> > https://osmose.openstreetmap.fr/fr/map/?item=6010
>> Même si je ne comprend pas pourquoi cette liste est vide
>> https://osmose.openstreetmap.fr/fr/errors/?country=france=6010
>>
>> Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion
>> d'ajouter le test dans osmose qu'une limite administrative doit être un
>> polygone fermé
>>
>> c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?
>>
>> l'autre solution plus rapide c'est de scripter pour faire par exemple
>> ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui
>> d'une commune réelle et virer le(s) tag de ces chenins concernés.
>> Si quelqu'un est motivé.. :)
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet Philippe Verdy 
Je crois que tu comprends mal... Osmose ne fais pas comme ça. Non pas
besoin de chemin fermé, les admin_level sur les chemins ne sont pas
invalides mais hautement recommandés, mais ils doivent effectivement être
membres d'une relation boundary pour prendre sens en tant qu'objet
"département" d'autant plus que cette valeur est surtout destiné à pas mal
de moterus de rendus pour afficher les pointillés qui sinon disparaissent.

Bref ce que tu demandes est complètement faux, tu as mal lu la doc.

Ici tu as un chemin qui est AUSSI une partie membre d'une frontière
administrative. C'est un cas très fréquent sur les routes et rivières: la
fusion des chemins superposés n'est pas fausse, c'est même une
recommandation. Si ces tracés sont différents on les détache et il n'y a
plus de fusion des tags non plus.

Nulle part ce tag indique "qu'une route se prend pour un département". Si
cela arrive c'est parce qu'il y a d'autres relations qui ont été taguée, là
par erreur, comme des frontières adminsitratives et reprennent ce chemin.
Ce n'est pas le chemin qui est en cause mais ces autres relations.


Le 19 juillet 2017 à 12:34, marc marc  a écrit :

> Bonjour,
>
> Il me semble qu'il y a de nombreuses anomalies avec ce tag
>
> exemple
> https://www.openstreetmap.org/way/457978185
> un bout de chemin en forêt qui se prend pour un département
> depuis le changeset 44193985
>
> https://www.openstreetmap.org/way/30828584
> une route qui se prend pour un arrondissement
> difficile de retrouver le changeset problématique. cela semble avoir
> lieu y a 4 ans sur le changeset 14088954
>
> en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
> Sans doute une partie sont réellement des limites communales constitué
> d'un seul chemin qui fait un boucle.
> mais en piochant pour 10 pour vérif, ce sont des chemins qui ne
> devraient pas avoir le tag de limite communale en tant que tel
> exemple http://www.openstreetmap.org/way/221500211
> exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
> serrais-ce un import qui a foiré ?
> un habitude jadis de dupliquer les tag sur la commune sur chaque chemin
> de sa frontière ?
>
> osmose détecte 3 bouts erronés parce qu'inclus dans une relation
> > https://osmose.openstreetmap.fr/fr/map/?item=6010
> Même si je ne comprend pas pourquoi cette liste est vide
> https://osmose.openstreetmap.fr/fr/errors/?country=france=6010
>
> Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion
> d'ajouter le test dans osmose qu'une limite administrative doit être un
> polygone fermé
>
> c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?
>
> l'autre solution plus rapide c'est de scripter pour faire par exemple
> ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui
> d'une commune réelle et virer le(s) tag de ces chenins concernés.
> Si quelqu'un est motivé.. :)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-19 Par sujet marc marc 
Bonjour,

Il me semble qu'il y a de nombreuses anomalies avec ce tag

exemple
https://www.openstreetmap.org/way/457978185
un bout de chemin en forêt qui se prend pour un département
depuis le changeset 44193985

https://www.openstreetmap.org/way/30828584
une route qui se prend pour un arrondissement
difficile de retrouver le changeset problématique. cela semble avoir 
lieu y a 4 ans sur le changeset 14088954

en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
Sans doute une partie sont réellement des limites communales constitué 
d'un seul chemin qui fait un boucle.
mais en piochant pour 10 pour vérif, ce sont des chemins qui ne 
devraient pas avoir le tag de limite communale en tant que tel
exemple http://www.openstreetmap.org/way/221500211
exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
serrais-ce un import qui a foiré ?
un habitude jadis de dupliquer les tag sur la commune sur chaque chemin 
de sa frontière ?

osmose détecte 3 bouts erronés parce qu'inclus dans une relation
> https://osmose.openstreetmap.fr/fr/map/?item=6010
Même si je ne comprend pas pourquoi cette liste est vide
https://osmose.openstreetmap.fr/fr/errors/?country=france=6010

Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion 
d'ajouter le test dans osmose qu'une limite administrative doit être un 
polygone fermé

c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?

l'autre solution plus rapide c'est de scripter pour faire par exemple 
ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui 
d'une commune réelle et virer le(s) tag de ces chenins concernés.
Si quelqu'un est motivé.. :)

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr