Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
Bonjour, Je suis en train d'exporter les petites polygones issus de la découpe au niveau des étranglements d'un gros polygone. Je produis une liste de fichier GML et je voulais savoir comment ajuster les tags de la relation pour conserver la trace qu'il s'agit d'un unique polygone CLC qui a été découpé. Une relation de relations ne m'enchante pas car les relations sont dans des fichiers séparées et elles ne disposeront d'un id que lorsqu'elles auront été importées. tag k=source v=Union européenne - SOeS, CORINE Land Cover, 2006./ tag k=CLC:year v=2006/ tag k=CLC:id v=FR-73751/ tag k=CLC:code v=311/ Une idée? Cedric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
Le 18/02/10 23:05, sylvain letuffe a écrit : Le jeudi 18 février 2010 22:07:48, Cedric Dumez-Viou a écrit : Les polygones découpés seront dans un fichier unique, ou dans des fichiers séparés ? (fichier unique = même problème de lecture avec JOSM) Des fichiers séparés. Je voudrais moi aussi ouvrir les forêts de ma région avec JOSM ;) c'est encore d'actualité cette histoire ? Je croyais que les gros polygones avaient été importés dans osm (de force) qu'il y ait overlap ou pas, mais avec un tag pour les différentier... Si y'a besoin, j'avais déjà fait un test avec un gros (relation de plusieurs centaines de ways) et je l'avais importer avec bulk_upload. je peux relancer ça si on me donne la liste des urls des gros à bulk uploader PS: a moins qu'un problème n'ait été repéré dans cette logique de fonctionnement Oui ! On fait comment, nous avec nos petits bras pour les éditer ? On appelle SuperJOSM ? Et on prend le café, le repas pendant qu'il charge ? Il est là le problème ! Des polygones moins gros, ça y'en a être la solution. Déjà qu'avec des multi-outers certains, croyant à une erreur se posaient des questions sur la validité de la relation et parlaient de fermer le way et osmarender qui avait besoin d'aspro... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés (fusion/découpage)
Bonjour, quelqu'un as-il (ou elle) trouvé(e) une solution pour découper les énormes polygones non importés? ce serait vraiment dommage de les laisser traîner sans les utiliser. manuellement, je n'ai pas réussi de les découper dans les étranglements avec JOSM. J'ai trop de problèmes avec les inner/outer. cantece 2009/11/4 ..cant...@web.de Salut, j'ai jeté un coup d'oeil au polygones énormes: * FR-96080 * FR-73751 * FR-6749 * FR-246825 * FR-202617 * FR-21767 * ... Est-il possible de les découper en petits morceaux? Ceci faciliterait l'import. Ces polygones complexes ont des endroits avec un étrangelement de la surface donne une marque pour une coupure. Ce découpage ne ferait pas seulement des polygones plus petits, mais aussi plus facilement attribuables.Éventuellement certains des composants pourrait etres importés automatiquement, car le critère de rejet (recouvrement) ne les toucherait plus. Mais: comment faire un découpage/partage automatique? Comment trouver les goulet/étranglement qui facilitent la découpe? Peut on utiliser des limites administratives ou des routes croiseantes pour découper? Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. Utiliser des limites administratives pour couper est très facile. Utiliser une route sera dur car il faut être sur que la route traverse entièrement le polygone. Ça implique alors de fusionner les différents ways qui font partie de cette route, ce qui est déjà beaucoup moins simple. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
J'étais un peu géné dans l'article de ne pas voir beaucoup de chose sur les trous (inner) dans les polygones. J'ai attendu de trouver un papier qui en parle avant de le souligner. Le site http://cs.gmu.edu/~jmlien/research/app-cd/ regroupe des travaux (récents: 2006) d'un thèsard sur la segmentation 2D-3D (on se fiche du 3D...) de polygones avec trous et concavitées. Il y a même un executable qui prend un polygone décrit dans un fichier txt (standard???) (le soft est soit-disant est GNU mais dont les sources ne sont dispo que sur demande... Encore un collègue chercheur qui veut recevoir du mail... ;) ) Je n'ai pas réussit à faire marcher son soft (on a une jolie image mais pas de segmentation comme dans ses rapports), mais là je suis assez confiant pour que ce soit de ma faute! Est-ce qu'un expert en donnée vectorielle veut-peut jouer avec l'outil pour vérifier que je ne sois pas la source du bug? Puis-je le contacter en lui disant qu'avec un peu de son aide, son outils pourrait être utilisé pour faire de belles cartes? (quand j'étais à sa place, j'aimais bien qu'on me dise que ce que je faisait servait à quelque chose ;) ) A+ Cedric Le Thursday 05 November 2009 10:58:34 Guillaume Allegre, vous avez écrit : Le Wed 04 Nov 2009 à 14:49 +, Emilie Laffray a ecrit : Bah si tu as une implementation potentielle, je peux voir si je peux coder cela si je comprends ce qu'on me demande de faire. C'est l'avantage pour moi d'utiliser Postgis; je n'ai pas a réfléchir a comment implémenter les modifications géométriques que j'ai besoin. Mais bon je ne suis pas convaincue qu'une telle solution soit très intéressante a moins que tous les polygones aient des excroissances très régulières et qu'il n'y ait pas de grosse masse. Enfin, peut être que je n'ai pas compris comment ces algorithmes fonctionnent. Emilie Laffray En cherchant un peu dans les publications de géo algo, j'ai trouvé ça : Mirela Tanase, Remco C. Veltkamp. Polygon Decomposition based on the Straight Line Skeleton. In: Proceedings ACM Symposium on Computational Geometry (SoCG 2003), 58-67. http://www.cs.uu.nl/groups/MG/multimedia/publications/art/socg03.pdf Qui est assez proche de l'idée intuitive que j'en avais, mais je l'ai juste parcouru rapidement. Les exemples de décomposition donnés sont assez convaincants, mais pour des polygones assez simples. Je ne suis pas sûr de ce que ça peut donner avec des vrais polygones CLC un peu tortueux. Par contre, ça m'étonnerait que ce soit simple à implémenter en PostGIS (je ne connais rien aux primitives PostGIS, mais si y'a un calcul de squelette intégré, je serai sur le cul). Eventuellement, on peut essayer une méthode plus bourrine mais peut-être plus efficace en PostGIS, inspirée de l'érosion en géo discrète. - on part d'un polygone CLC P - on calcule une rétractation d'offset d (à estimer) R - on regarde si le polygone R reste simple ou s'il a des auto-intersections En cas d'auto-intersections, on scinde le polygone, au niveau des sommets en question. - A régler : estimation de l'offset d : une fraction (par ex. 5%) du diamètre D du polygone de départ (on peut approcher D par la diagonale de la boîte englobante de P). - est-ce qu'on itère ? Quel critère d'arrêt ? est-ce qu'on augmente d en itérant ? Voilà, ce ne sont que des idées en vrac. J'espère avoir un peu de temps pour tester dans les semaines à venir. signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés (fusion/découpage)
Salut, j'ai jeté un coup d'oeil au polygones énormes: * FR-96080 * FR-73751 * FR-6749 * FR-246825 * FR-202617 * FR-21767 * ... Est-il possible de les découper en petits morceaux? Ceci faciliterait l'import. Ces polygones complexes ont des endroits avec un étrangelement de la surface donne une marque pour une coupure. Ce découpage ne ferait pas seulement des polygones plus petits, mais aussi plus facilement attribuables.Éventuellement certains des composants pourrait etres importés automatiquement, car le critère de rejet (recouvrement) ne les toucherait plus. Mais: comment faire un découpage/partage automatique? Comment trouver les goulet/étranglement qui facilitent la découpe? Peut on utiliser des limites administratives ou des routes croiseantes pour découper? Salutations, Cantece ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés (fusion/découpage)
2009/11/4 Hans-Christian Bohlmann cant...@web.de Salut, j'ai jeté un coup d'oeil au polygones énormes: * FR-96080 * FR-73751 * FR-6749 * FR-246825 * FR-202617 * FR-21767 * ... Est-il possible de les découper en petits morceaux? Ceci faciliterait l'import. Ces polygones complexes ont des endroits avec un étrangelement de la surface donne une marque pour une coupure. Ce découpage ne ferait pas seulement des polygones plus petits, mais aussi plus facilement attribuables.Éventuellement certains des composants pourrait etres importés automatiquement, car le critère de rejet (recouvrement) ne les toucherait plus. Mais: comment faire un découpage/partage automatique? Comment trouver les goulet/étranglement qui facilitent la découpe? Peut on utiliser des limites administratives ou des routes croiseantes pour découper? Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. Utiliser des limites administratives pour couper est très facile. Utiliser une route sera dur car il faut être sur que la route traverse entièrement le polygone. Ça implique alors de fusionner les différents ways qui font partie de cette route, ce qui est déjà beaucoup moins simple. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
Mais: comment faire un découpage/partage automatique? Comment trouver les goulet/étranglement qui facilitent la découpe? Peut on utiliser des limites administratives ou des routes croiseantes pour découper? J'étais en train d'écrire une réponse à ce mail mais on arrive au même conclusion. Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. J'avais envisagé un traitement morphologique pour trouver les étranglements (une ouverture: http://fr.wikipedia.org/wiki/Morphologie_math%C3%A9matique#Ouverture_et_fermeture) mais ça nécessite de passer de vectoriel à raster sur de très grandes images, donc gourmand en mémoire, tps de calcul,... Utiliser des limites administratives pour couper est très facile. Utiliser une route sera dur car il faut être sur que la route traverse entièrement le polygone. Ça implique alors de fusionner les différents ways qui font partie de cette route, ce qui est déjà beaucoup moins simple. Et je me demandais si couper ces polygones avec des limites administratives était difficile (Je ne travaille pas avec des données vectorielles, je ne saurais même pas comment dire si un point est dans une surface ou pas...). Si il existe un méthode simple pour couper ces polygones avec des limites de communes, je suis preneur!!! Vers quel outils-bibliothèques faut-il regarder pour manipuler des ways issus de OSM? Cedric signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
2009/11/4 Cedric Dumez-Viou cedric.dumez-v...@obs-nancay.fr Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. J'avais envisagé un traitement morphologique pour trouver les étranglements (une ouverture: http://fr.wikipedia.org/wiki/Morphologie_math%C3%A9matique#Ouverture_et_fermeture) mais ça nécessite de passer de vectoriel à raster sur de très grandes images, donc gourmand en mémoire, tps de calcul,... Oui utiliser du raster n'a pas vraiment d'intérêt car on perd en qualité au final car il faut repasser en vectoriel si l'on veut repasser en fichier OSM a moins que j'ai manqué un épisode. Utiliser des limites administratives pour couper est très facile. Utiliser une route sera dur car il faut être sur que la route traverse entièrement le polygone. Ça implique alors de fusionner les différents ways qui font partie de cette route, ce qui est déjà beaucoup moins simple. Et je me demandais si couper ces polygones avec des limites administratives était difficile (Je ne travaille pas avec des données vectorielles, je ne saurais même pas comment dire si un point est dans une surface ou pas...). Si il existe un méthode simple pour couper ces polygones avec des limites de communes, je suis preneur!!! J'utilise tout simplement la base de donnée pour cela. Il suffit de faire une intersection entre la commune et le polygone corine. Tu obtiens alors un tout nouveau polygone qui sera coupe précisément avec la forme de la limite. A noter que ça peut augmenter la complexité du polygone puisque les limites administratives sont complexes. Ce n'est donc pas forcement une bonne idee :) Vers quel outils-bibliothèques faut-il regarder pour manipuler des ways issus de OSM? Tout dépend de ce que tu veux faire. Ce que je fais c'est de manipuler des géométries dans Postgis et ensuite de les exporter en SHP puis en OSM. C'est de cette manière que Corine a été crée. Pour manipuler des fichiers OSM, il te faut utiliser Osmosis, qui te permettra de découper un fichier OSM mais ça ne fait pas de découpage logique. Ça ne fait qu'une découpe géographique des objets sans recreer de nouvelles relations ou ways ou il faut. Bien sur, il est possible d'utiliser libgeos directement dans un programme (librairie qui fait tourner Postgis) en transformant la géométrie en WKB (si je ne me trompe pas). C'est d'ailleurs ce que fait partiellement osm2pgsql afin de stocker les données dans la base de donnée. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
2009/11/4 Cedric Dumez-Viou cedric.dumez-v...@obs-nancay.fr Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. J'avais envisagé un traitement morphologique pour trouver les étranglements (une ouverture: http://fr.wikipedia.org/wiki/Morphologie_math%C3%A9matique#Ouverture_et_fermeture) mais ça nécessite de passer de vectoriel à raster sur de très grandes images, donc gourmand en mémoire, tps de calcul,... Je viens de regarder la page et je viens d'avoir peur :) Ca fait longtemps que je n'ai pas fait de maths a ce niveau la! Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
Le Wed 04 Nov 2009 à 13:56 +0100, Cedric Dumez-Viou a ecrit : J'avais envisag� un traitement morphologique pour trouver les �tranglements (une ouverture: http://fr.wikipedia.org/wiki/Morphologie_math%C3%A9matique#Ouverture_et_fermeture) mais �a n�cessite de passer de vectoriel � raster sur de tr�s grandes images, donc gourmand en m�moire, tps de calcul,... C'est clair que couper au niveau des �tranglements para�t la bonne m�thode, mais que c'est pas forc�ment facile. Pour ce qui est de l'article cit�, oui, c'est l'id�e, dans un contexte math�matique pur. Au niveau applications informatiques tu as deux domaines assez diff�rents. En simplifiant � fond : - en g�om�trie discr�te, tu travailles sur du raster (grille de pixels) - en g�om�trie algorithmique, tu travailles sur du vectoriel L'article cit� est carr�ment du c�t� de la g�o discr�te. C'est pas ce qu'on cherche. En g�o algo (ce fut mon domaine de th�se dans une vie ant�rieure), la d�tection d'�tranglement est g�n�ralement trait�e � partir de l'axe median (googler medial axis polygon). J'ai peu de temps pour approfondir aujourd'hui, mais je peux chercher des algos pr�cis si �a int�resse du monde. -- � /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
2009/11/4 Guillaume Allegre allegre.guilla...@free.fr C'est clair que couper au niveau des étranglements paraît la bonne méthode, mais que c'est pas forcément facile. Pour ce qui est de l'article cité, oui, c'est l'idée, dans un contexte mathématique pur. Au niveau applications informatiques tu as deux domaines assez différents. En simplifiant à fond : - en géométrie discrète, tu travailles sur du raster (grille de pixels) - en géométrie algorithmique, tu travailles sur du vectoriel L'article cité est carrément du côté de la géo discrète. C'est pas ce qu'on cherche. En géo algo (ce fut mon domaine de thèse dans une vie antérieure), la détection d'étranglement est généralement traitée à partir de l'axe median (googler medial axis polygon). J'ai peu de temps pour approfondir aujourd'hui, mais je peux chercher des algos précis si ça intéresse du monde. Bah si tu as une implementation potentielle, je peux voir si je peux coder cela si je comprends ce qu'on me demande de faire. C'est l'avantage pour moi d'utiliser Postgis; je n'ai pas a réfléchir a comment implémenter les modifications géométriques que j'ai besoin. Mais bon je ne suis pas convaincue qu'une telle solution soit très intéressante a moins que tous les polygones aient des excroissances très régulières et qu'il n'y ait pas de grosse masse. Enfin, peut être que je n'ai pas compris comment ces algorithmes fonctionnent. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés ( fusion/découpage )
Le Wednesday 04 November 2009 15:00:02 Emilie Laffray, vous avez écrit : 2009/11/4 Cedric Dumez-Viou cedric.dumez-v...@obs-nancay.fr Découper automatiquement est relativement facile si tu fais un damier. Trouver un goulet/un étranglement qui facilite la découpe, ça devient beaucoup beaucoup plus dire. J'avais envisagé un traitement morphologique pour trouver les étranglements (une ouverture: http://fr.wikipedia.org/wiki/Morphologie_math%C3%A9matique#Ouverture_et_fermeture) mais ça nécessite de passer de vectoriel à raster sur de très grandes images, donc gourmand en mémoire, tps de calcul,... Je viens de regarder la page et je viens d'avoir peur :) Ca fait longtemps que je n'ai pas fait de maths a ce niveau la! Emilie Laffray Je crois qu'à l'origine les opération de morphologie étaient plutôt de la bidouille d'informaticien pour faire du traitement d'image. Ça a ensuite été théorisé... et j'avoue que mes cours de traitement d'images étaient beaucoup plus simple que la page wiki... En fait le lien n'apprend rien, je voulais plutôt parler des figures. Ce qu'il faut retenir, c'est la figure http://fr.wikipedia.org/wiki/Fichier:Illustration_ouverture.png . C'est obtenu par une érosion (http://fr.wikipedia.org/wiki/Fichier:Illustration_erosion.png) suivie par une dilatation (http://fr.wikipedia.org/wiki/Fichier:Illustration_dilatation.png). L'érosion supprime les étranglements et la dilatation redonne aux surfaces pleines leur taille d'origine. Faire la différence entre image d'origine et image ouverte permet d'indiquer les zones qui présentent des étranglements. Enfin, ça reste toujours difficile à utiliser pour les données OSM. On peut certainement clore cette suggestion. Cedric signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] outils pour traiter les CLC non impo rtés (fusion/découpage)
Salut, l'import de surfaces CLC à bien généré une carte plus complete et présentable. Mail les non-importés me posent encore des problemes. Je cherche un outil JOSM qui décompose des surfaces qui s'entrecoupenet ou se chevauvent. Ici deux examples: surface à découper en petites surface: http://osmose.openstreetmap.fr/clc/cgi-bin/get-osm.sh%3FFR-42229 découper les surfaces suivant les intersections: http://osmose.openstreetmap.fr/clc/cgi-bin/get-osm.sh%3FFR-49672 Avez vous une idée? J'imagine un outil qui montres les surfaces et identifies les parties qui se chavauchent et laisse le choic quelle partie garder et quelle partie supprimer ou fusionner. Il faudrait dans certains cas aussi créer des inner/outer. Pas facile, mais ca faciliterait d'importer les surfaces restantes sans trop perdre des surfaces existantes. Contrairement 'a l'import automatique, l'utilisateur aurait un choix ou des modifs à faire. Merci, Cantece ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outils pour traiter les CLC non impo rtés (fusion/découpage)
2009/11/2 Hans-Christian Bohlmann cant...@web.de Salut, l'import de surfaces CLC à bien généré une carte plus complete et présentable. Mail les non-importés me posent encore des problemes. Je cherche un outil JOSM qui décompose des surfaces qui s'entrecoupenet ou se chevauvent. Ici deux examples: surface à découper en petites surface: http://osmose.openstreetmap.fr/clc/cgi-bin/get-osm.sh%3FFR-42229 découper les surfaces suivant les intersections: http://osmose.openstreetmap.fr/clc/cgi-bin/get-osm.sh%3FFR-49672 Avez vous une idée? J'imagine un outil qui montres les surfaces et identifies les parties qui se chavauchent et laisse le choic quelle partie garder et quelle partie supprimer ou fusionner. Il faudrait dans certains cas aussi créer des inner/outer. Pas facile, mais ca faciliterait d'importer les surfaces restantes sans trop perdre des surfaces existantes. Contrairement 'a l'import automatique, l'utilisateur aurait un choix ou des modifs à faire. Le moyen le plus simple est de faire ceci dans la base de donnée directement. La base de donnée peut faire tous les trous nécessaires si besoin a partir de l'existant, ainsi que de découper les polygones. Pour découper le polygone, on peut utiliser Osmose ou même un programme manuel. Le programme devrait faire la chose suivante: - Obtenir la bounding box du polygone OSM - Découper le fichier OSM en plusieurs bouts selon les paramètres rentrés par l'utilisateur - Être sur de créer les ways et les relations correctement Je vais voir si cette semaine j'ai le temps d'écrire le programme en Python et de voir si on peut intégrer cela avec Osmose. Cela proposerait donc plusieurs fichiers a telecharger. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
