[OSM-dev-fr] Relation 82629, séquence des ways
Bonjour à tous, En analysant les données, j'ai trouvé un truc bizarre dans la relation 82629http://www.openstreetmap.org/browse/relation/82629 En effet, le contour se déroule correctement jusqu'au chemin 122190376, qui n'a pas de noeud commun avec le chemin suivant (53227067). En revanche, le dernier chemin de cette relation (122190375) lui fait la relation entre les deux. Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ? Merci à vous, A bientôt ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Relation 82629, séquence des ways
On vendredi 2 septembre 2011, Aurélien FILEZ wrote: Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ? C'est normal, une relation n'a pas l'obligation d'avoir ses membres ordonnés. C'est cependant plus pratique pour les cartographe quand c'est le cas pour repérer des cassures dans la continuité. Le développeur d'outil de contrôle, de construction, ou d'analyse devrait donc prévoir son algorithme de manière générique en ne pré-supposant pas cet ordonnement. -- sly qui suis-je : http://sly.letuffe.org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Relation 82629, séquence des ways
Hello, Je n'ai pas regarder ce cas spécifique, mais au début des relations ce n'étais pas obligatoire que les chemins soient dans l'ordre, mais cela n'enpeche pas que cela facilite énormément la gestion, je conseillerais donc de le remettre en place (comprendre à la suite) ;-) CU Stéphane 2011/9/2 Aurélien FILEZ kinj...@gmail.com: Bonjour à tous, En analysant les données, j'ai trouvé un truc bizarre dans la relation 82629 En effet, le contour se déroule correctement jusqu'au chemin 122190376, qui n'a pas de noeud commun avec le chemin suivant (53227067). En revanche, le dernier chemin de cette relation (122190375) lui fait la relation entre les deux. Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ? Merci à vous, A bientôt ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- Envoyé depuis mon lapin -- Catalogue de cartes OpenStreetMap - http://map.stephane-brunner.ch Un peu d'espace qui vous suis partout - https://www.getdropbox.com/referrals/NTk2OTU2Mjk -- ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Relation 82629, séquence des ways
Hi ! Est-ce que c'est pareil pour les relations simples ? Car dans la table des relations, il y a la notion de séquence.. En analysant quelques sources d'outils, j'ai vu que pour déterminer si une relation était fermée ou ouverte, ils testaient l'égalité entre le premier noeud de la première way et le dernier noeud de la dernière way, sans procéder, d'après mes souvenirs à un trie quelconque en amont.. Si ce n'est pas le cas, vivement que l'utilité des super-relations soient officielle et que des règles s'imposent, car étant développeur, cette pseudo anarchie concernant les super-relations est pas mal difficile à gérer et surtout très longue à l'exécution. Pour le moment mon besoin (et celui de bien d'autres d'après les listes) n'est que ponctuel (récupérer le polygon d'un pays sous différentes formes), mais quand ça viendra à l'échelle d'un département, d'une ville enfin de n'importe quelle relation collée à une autre relation, là ça va être la super-misère si des règles n'imposent pas un minimum de structure (établies par le mapper ou automatiquement) Kin 2011/9/2 Stéphane Brunner courr...@stephane-brunner.ch Hello, Je n'ai pas regarder ce cas spécifique, mais au début des relations ce n'étais pas obligatoire que les chemins soient dans l'ordre, mais cela n'enpeche pas que cela facilite énormément la gestion, je conseillerais donc de le remettre en place (comprendre à la suite) ;-) CU Stéphane 2011/9/2 Aurélien FILEZ kinj...@gmail.com: Bonjour à tous, En analysant les données, j'ai trouvé un truc bizarre dans la relation 82629 En effet, le contour se déroule correctement jusqu'au chemin 122190376, qui n'a pas de noeud commun avec le chemin suivant (53227067). En revanche, le dernier chemin de cette relation (122190375) lui fait la relation entre les deux. Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ? Merci à vous, A bientôt ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- Envoyé depuis mon lapin -- Catalogue de cartes OpenStreetMap - http://map.stephane-brunner.ch Un peu d'espace qui vous suis partout - https://www.getdropbox.com/referrals/NTk2OTU2Mjk -- ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Relation 82629, séquence des ways
On vendredi 2 septembre 2011, Aurélien FILEZ wrote: Hi ! Est-ce que c'est pareil pour les relations simples ? C'est vrai quel que soit le type d'élément membres d'une relation (noeud, way ou relation) L'API osm les restituant dans l'ordre dans lequel ils ont été envoyés mais ne réalisant aucun test concernant une topologie quelconque : http://wiki.openstreetmap.org/wiki/Elements En analysant quelques sources d'outils, j'ai vu que pour déterminer si une relation était fermée ou ouverte, ils testaient l'égalité entre le premier noeud de la première way et le dernier noeud de la dernière way, sans procéder, d'après mes souvenirs à un trie quelconque en amont.. Mauvais outils ? Que se soit osm2pgsql, l'analyseur d'osmose ou http://ra.osmsurround.org/ ils le supportent tous. F. Ramm a même décrit un algorithme possible pour gérer cela : http://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm Si ce n'est pas le cas, vivement que l'utilité des super-relations soient officielle et que des règles s'imposent, car étant développeur, cette pseudo anarchie concernant les super-relations est pas mal difficile à gérer et surtout très longue à l'exécution. Rien n'est gagné pour toi car la priorité est souvent donnée pour que cela soit plus facile aux cartographes : data is king et non aux développeurs. Et je partage cette philosophie : si un algo est possible, autant donner le boulot aux ordinateurs plutôt qu'aux humains ! Pour le moment mon besoin (et celui de bien d'autres d'après les listes) On attends toujours que quelqu'un se plonge un peu dans le code pour nous fournir l'outil ;-) n'importe quelle relation collée à une autre relation, là ça va être la super-misère si des règles n'imposent pas un minimum de structure (établies par le mapper ou automatiquement) Avec ou sans les super relation c'est déjà la super misère car les outils n'imposent pas qu'une relation qu'on s'attend à former une topologie (polygone, ligne brisée) la forme véritablement. Pour l'instant on a donc des outils de contrôle a posteriori pour tenter de trouver les ruptures. Il y a des voies de recherche pour l'avenir (API 0.7) pour établir un nouveau type area que l'api pourrait imposer comme étant fermé, mais rien ne dit comment on va gérer les frontières de la france qui totalise une quantité astronomique de noeuds http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction -- sly qui suis-je : http://sly.letuffe.org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
