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

[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 <marc_marc_irc at hotmail.com> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170720/3548a27c/attachment.htm>