Le 5 mai 2012 10:23, DH <dhel...@free.fr> a écrit : >> Ton lien est très bien et j'étais déjà tombé dessus mais il parle de la >> primitive "POLYGON" de l'OGC pas de la primitive MULTIPOLYGON dont il est >> question ici, qui elle autorise que deux polygons distinct se touchent au >> sein >> d'une primite MULTIPOLYGON >> > Exact. Pour un multipolygon ça ne le rend pas invalide. Comment se prend la > décision de passer un way en polygone ou en multipolygone (hors cas faciles)
Le problème n'est pas celui de la validité (selon le modèle OSM actuel) mais vient de l'ambiguité d'interprétation du modèle OSM, parce que le cas que j'ai donné n'ai pas clairement documenté et défini pour que la conversion OSM>GIS puisse se faire sans difficulté. Une présupposition non décritedu modèle Multipolygone d'OSM s'avère fausse et c'est bien là le problème. Et ce n'est pas non plus un bogue à proprement parler d'osm2gis puisqu'il fait de son mieux pour interpréter ce que lui indiquent les données OSM, afin de savoir quoi générer : un ou plusieurs plolygnes fermés ou non, selon les connexions de segments qu'il trouve dans la base. > Si les bordures constitutives de la commune sont transformées en polygon, il > y une erreur de validité de la figure. Si les bordures dont converties en > multipolygon, ça passera sans souçi. Si un noeud est utilisé par 4 segments (donc utilisés par au moins 2 ways différents), osm2gis ne sait pas comment joindre les segments car il n'a pour l'instant encore strictement aucun de critère défini (et documenté) Il connecte tout ce qu'il peut (et pas dans l'ordre qui serait approprié) puisqu'il ne tient pas compte (et ne peut PAS ENCORE tenir compte) des rôles des membres d'une relation ni de leur ordre relatif dans la relation, à cause des différentes façons de créer des multipolygones (avec des rôles incohérents, avec ou sans tri, il doit se débrouiller pour reconnecter le tout, et si ça marche pour les cas simples et les plus fréquents où les polygones ne se touchent pas entre eux, l'algo ne PEUT PAS fonctionner si ces polygones se touchent). Sans ces critères clairement défini, les multipolygones d'OSM ne peuvent pas gérer correctement les polygones qui se touchent (alors qu'ils sont nécessaires et standards dans les modèles GIS, même pour le profil Simple Features). Moi je propose une solution simple : le critère de choix pour les connexion c'est le **rôle** (sans même lui attribuer une signification "outer" ou "inner", c'est un simple nom symbolique permettant d'identifier et séparer les polygones distincts). Si on fait ça correctement, et si on le documente il devrait alors être possible de modifier osm2gis pour qu'il en tienne compte au lieu de connecter n'importe quelle paire de segments. Pour la compatibilité, il faut toutefois que le rôle anonyme et les rôles "outer" et "exclave" soient reconnus comme équivalentsau seul rôle étiqueté "outer" (mais en continuant à ignorer leur signification en tant que contour externe ou interne, car osm2gis le déterminera tout seul), et de même pour les rôles "enclave" et "inner". Et d'autres rôles de la forme "outer:*" ou 'inner:*" devraient être acceptés, mais distingués pour permettre la séparation des polygones qui ne doivent pas s'interconnecter. En revanche l'ordre des membres dans la relation ne doit jouer strictement aucun rôle (cet ordre des membres dans la relation ne sert strictement à rien, on pourrait même éviter de le stocker dans la base OSM, ce qui lui éviterait aussi de passer du temps et de l'espace disque temporaire dans les tris pendant les requêtes de chargement ou pour mettre à jour un index si le tri est précalculé et stocké dans l'index). L'ordre des membres dans la liste n'est qu'une facilité de présentation dans les éditeurs, mais les éditeurs peuvent trier ces listes eux-mêmes automatiquement, et soumettre les listes dans n'importe quel ordre (le serveur n'a pas besoin de stocker cet ordre dans un index, ni même de trier les requêtes de chargement : il ira d'autant plus vite !). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
