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_...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr