Le 5 mai 2012 12:19, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > Le samedi 5 mai 2012 07:26:09, Philippe Verdy a écrit : >> Note: je suis tombé aussi sur d'autres cas de géométries qui son mal >> résolues lors de la conversion OSM vers OGC. > > Mon avis est que cette question n'a pas sa place sur cette liste car trop > technique; et, spécifique, à mon avis, à l'outil de conversion utilisé.
Peut-être mais l'outil utilisé sert absolument à tout le monde (et pas seulement les moteurs de rendus) dès qu'on cherche à interpréter le contenu de la base OSM. Je maintiens le fait que ce qu'on met dans le base est ambigu pour le cas des polygones qui se touchent car ce cas n'est pas documenté du tout (alors que la doc des multipolygones d'OSM prétend que c'est compatible avec le GIS standard). Il manque une règle non écrite (et en fait pas respectée du tout puisque jamais vérifiée explicitement et non nécessaire la plupart du temps car l'immense majorité des multipolygones d'OSM ne contiennent pas de polygones qui se touchent). Ce n'est PAS spécifique à l'outil utilisé. L'ambiguité est intrinsèque à la représentation OSM actuelle. Ta demo2 je l'avais déjà essayée aussi (exactement comme tu l'as envoyée, regarde l'historique de la même municipalité) : elle ne marchait pas non plus, car elle contient la même ambiguïté d'interprétation au vu des règles OSM décrites actuellement. On ne sait pas dire à partir des données OSM quels ways interconnecter (ou pas) pour former les polygones fermés, ou si on doit générer un seul polygone ou plusieurs (en modèle GIS standard ce devrait être plusieurs, car il n'est pas permis aux sommets d'un même polygone d'être visité plus d'une fois par le chemin qui le traverse, sauf les 2 sommets terminaux du chemin lui-même qui peuvent être identiques pour produire un polygone fermé). Il n'y a aucune règle dans OSM pour faire les paires correctes de ways. Comment te convaincre ? Pourtant j'avais réduit le cas à quelque chose de plus simple dans un schéma pour éviter d'avoir à comprendre le cas concret bien plus compliqué. Il n'est décrit nulle part dans les règles de modélisation OSM quels ways d'un multipolugone se connectent à quel autre, et c'est bien pour ça qu'osm2gis se trompe (et ce n'est pas un bogue de cet outil). Ce qui est décrit en revanche c'est que : - les ways ne doivent pas se croiser (que ce soit sur un point non décrit par un noeud commun, ou sur un noeud intermédiaire qui n'est pas un des 2 noeuds terminaux d'un way). - il décrit aussi le fait que les noeuds terminaux des ways se touchent par paire (puisque c'est la seule façon de les connecter pour former des polygones fermés), - mais pas écrit combien de ways peuvent utiliser le même noeud terminal Dans le modèle OSM actuel, cela marche bien quel que soit le rôle indiqué pour les ways, à condition que nulle par il y ait plus de 2 ways terminés sur un même nœud), les rpoles "inner" et "outer" ne sont qu'indicatifs et servent davantage au contrôle de cohérence entre ce qu'on peut déduire de la géométrie et ce qui est dans la base, mais ces rôles ne servent encore à rien pour générer la géométrie. De fait: - peu importe comment on renseigne les rôles tant que les polygones ne se touchent pas et sont tous fermés sans se croiser eux-mêmes, et peu importe si les polygones sont décrits en un seul ou plusieurs ways, avec ou sans partage des ways pour les frontières communes de deux zones limitrophes cela marche, il n'y a pas d'ambiguîté réelle au fait de connecter systématiquement toute paire de way qui partagent un même noeud terminal. Ce n'est pas le cas ici. Il faut une règle de résolution en plus, propre à OSM lui-même, et dont ensuite les outils (osm2gis ou un autre) devront tenir compte. Bref cela a a bien place sur cette liste avant même d'aller sur la liste DEV, car c'est un problème de modélisation OSM, propre et intrinsèque au schéma OSM lui-même pour demander qu'on modifie les outils pour tenir compte d'une règle supplémentaire de résolution de l'ambiguïté. Oui c'est technique, mais on est encore loin de la solution finale. Je maintiens que le problème est encore insoluble dans le modèle OSM actuel qui mélange les rings distincts dans une même relation Sachant aussi : - qu'il n'est pas possible de déterminer depuis la liste des ways membres, même correctement ordonnée, où s'arrête la sous-liste d'un polygone fermé et ou commence la sous-liste du polygone fermé suivant, si ces deux polygones fermés (internes ou externes peu importe) partagent un noeud commun : on utilise quoi pour les séparer ? l'ordre ne suffit pas. les rôles différents ne suffisent pas non plus (et sont encore assez souvent incohérents. - et que la plupart du temps et presque partout ces ways sont très souvent dans le désordre, l'ordre pouvant être brisé à tout moment simplement en scidant un way en deux parties, selon son orientation). - que les rôles sont souvent aussi aléatoires : tant que les polygones fermés ne se touchent pas (cas le plus fréquent) ce n'est pas un problème, on peut les ignorer... - souvent aussi des polygones internes n'ont pas de rôle défini, ou utilisent à tord un rôle "outer". Ce n'est pas non plus un problème tant que ces polygones d'un même multipolygone ne se touchent pas et sont tous correctement fermés. c'est pour ça que osm2gis ignore les rôles actuellement (il suppose que ces polygones ne peuvent pas se toucher, ce qui est vrai avec la doc actuelle des multipolygones). Tu ne comprends pas le problème visiblement. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
