Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, J'ai deux points que j'aimerais ajouter à ce débat. - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus des chevauchements il y a les vides incorrects entre les bâtiments. - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Frédéric Le 7 février 2012 21:08, DH dhel...@free.fr a écrit : Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un patelin de 300 habitants, c'est moins de boulot qu'une banlieue de plusieurs milliers d'âmes (genre Kingersheim au hasard). L'enjeu et le travail reste le même : 1. on laisse faire les outils en attendant qu'ils s'améliorent (sur quels critères d'abord ?) et on a ce que l'on mérite 2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un seul tour quand elle découvre que des miettes de qualité peuvent être grapillées (la fourmi est écolo dans l'âme). La fourmi est besogneuse, sinon c'est une cigale déguisée en fourmi. L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord A l'analyse, il semble que les outils (et autre méthodes d'import de masse) soient tolérés dans la mesure où la colonie ne s'assied pas sur le tas de données produit d'un air satisfait : ça c'est fait, mais prend pelle et pioche pour remuer le tout et l'intéger au reste de la base. Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. Repense à HAL9000 Chacun est responsable de ses apports (tiens cela ressemble encore trop à imports) à la base. Chaque contributeur est, de fait, responsable du niveau de qualité qu'il injecte dans la base. Noboby is perfect (as a ro(b)ot ?), mais on moins on aura mis de la transpiration dans cette base ; c'est ce qui devrait faire son odeur si particulière, appréciée par certains. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 10:05, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, J'ai deux points que j'aimerais ajouter à ce débat. - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus des chevauchements il y a les vides incorrects entre les bâtiments. - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Frédéric Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) A+ Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
par contre, j'ai justement corrigé pas mal de truc de ce genre dont l'auteur etait le pieren_bot... ;) je tiens a faire ici publiquement mes excuses au bot, il n'est que le dernier modificateur de bâtiments qui était déjà en erreurs. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, DH wrote: Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. C'est même un de ces buts ! confronter des idées et des choix pour tenter d'obtenir une meilleure cohérance. A lire les débats, je crois que moi et christian perdons sur un score sans appel de 7-2 J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat démocratique. C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête de mettre mes cochonneries dans la base. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur Je me qualifierais de fourmi raisonnée ou de cigale assumée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Bruno : Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr que la majorité serait pour un nettoyage automatique, si suffisamment bien fait, de la base OSM (justement pour éviter de se le taper à la main) Le problème a mon avis, il est là : - 10 personnes sur cette liste savent lancer ton programme en python - 6 ont les compétences de l'analyser le tester et l'améliorer - et 0.5 ont le temps de le faire ! En clair, tu as accompli une très bonne première étape : fournir un soft pour nettoyer. Frédéric et/ou jocelyn ont fourni l'outil pour repérer les erreurs (osmose) et Philippe a fourni un export basé sur le soft qadastre de je sais plus qui, qui malheureusement ne fourni pas un export cadastre assez propre (ce n'est pas un reproche) Maintenant, on passe au yaka, c'est à dire trouver celui qui va proposer non pas une brique, mais un résultat final, qui soit facile (ou plutôt très très facile) à contrôler par d'autres. Puis proposer un plan d'action, obtenir l'accord d'une majorité d'exprimés, et le faire. Comme toujours, facile à dire. Donc non, c'est pas qu'on en veut pas, c'est qu'on voudrait bien que tu fasses tout ;-))) Dans la limite de mes compétences+temps, je veux bien filer un coup de main, je vais regarder ce qu'il fait ton bidule et voir comment je peux l'utiliser et voir comment je pourrais par exemple présenter un échantillon avant/après d'un fichier -houses.osm d'une commune. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Romain Le 8 février 2012 14:18, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 7 février 2012, DH wrote: Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. C'est même un de ces buts ! confronter des idées et des choix pour tenter d'obtenir une meilleure cohérance. A lire les débats, je crois que moi et christian perdons sur un score sans appel de 7-2 J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat démocratique. C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête de mettre mes cochonneries dans la base. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur Je me qualifierais de fourmi raisonnée ou de cigale assumée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:54, Romain MEHUT romain.me...@gmail.com a écrit : Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Maj + J ;-) Faut regarder dans les menus ce que propose JOSM ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Wed, 8 Feb 2012 14:32:25 +0100, sly (sylvain letuffe) wrote: Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Bruno : Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr que la majorité serait pour un nettoyage automatique, si suffisamment bien fait, de la base OSM (justement pour éviter de se le taper à la main) C'est peut etre mes expériences désastreuse d’écriture de robot (ou plutot leurs executions), mais je me mefie toujours un peut des correction automatique. Il y aura toujours des cas de la vrai vie auquel on n'aura pas pensé Un exemple tout bete : les batiments http://www.openstreetmap.org/browse/way/81188412 et http://www.openstreetmap.org/browse/way/81188234 sont bien séparés de 20cm, il ne faut pas les recoller. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, De : Etienne Trimaille Le 8 février 2012 14:54, Romain MEHUT a écrit : 2012/2/8 Romain MEHUT : J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. N'empêche que ce temps, aussi long soit il, reste d'un volume ridicule en comparaison de tracer tout le bâti à la main, comme ça se faisait, sans autre choix, jusqu'à juin 2010. Ce temps (Denis parlait de transpiration, on parle de la même chose) figure une forme de valeur ajoutée, qui distingue de l'import brut, associé au recalage ou au tracé du filaire de voies. Ne pas oublier qu'il n'y a aucune obligation à importer du bâti, tout comme il n'y a aucune obligation de faire du chiffre / du volume d'upload. De mon côté je garde une logique assez simple : je n'importe que là où je peux ajouter autre chose que ce que donne le cadastre : ne serait-ce qu'un POI, mais ce sera forcément un endroit où j'ai déjà mis les pieds. Oui, ça limite le nombre de patelins, mais ça limite aussi les imports à l'aveugle. Je pense qu'on met forcément un peu plus d'énergie à bien faire en s'occupant de coins qu'on connaît et qu'on pratique. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Comme ça vient d'être signalé, il y a des bâtiments mitoyens construits indépendamment sur des parcelles voisines (typiquement dans les centres anciens) qui n'ont pas lieu d'être fusionnés. Et inversement, des bâtiments uniques construits sur plusieurs parcelles qui eux doivent être fusionnés. Les données du cadastre seul ne permettent pas de choisir. Donc, pas de fusion/correction automatique, uniquement du manuel après contrôle sur le terrain. Sinon, j'ai aussi rencontré des cas de bâtiments récents sur parcelle unique mais découpés en plusieurs morceaux. Dans ce cas, je serais plus favorable à un traitement automatisé. Il semble qu'à un moment donné (durant automne 2011), cleo carto faisait la fusion en automatique. Vous confirmez? Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
-Message d'origine- De : sly (sylvain letuffe) [mailto:li...@letuffe.org] Envoyé : mercredi 8 février 2012 14:32 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse Mes 0,02€ Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
De : HELFER Denis Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse +1 pour le pré-traitement des fichiers -houses avant leur mise à disposition, pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de Bruno par ex. En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. Pour moi la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains que ces FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou ignorer un FIXME, je vois peu de différence (vu de ma lorgnette). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:57, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Le 8 février 2012 14:54, Romain MEHUT romain.me...@gmail.com a écrit : Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Maj + J ;-) Faut regarder dans les menus ce que propose JOSM ;-) Merci. Voici un peu de temps de gagné! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Les FIXME c'est justement pour ce que le validateur ne détecte pas ou ne peut pas détecter, par exemple des données à affiner ou vérifier sur le terrain. En revanche, mettre FIXME dans une valeur de tag (par exemple name=FIXME) est inutile. Mais FIXME est tout à fait utilisable en tant que clé, et prend alors une valeur textuelle expliquant ce qui devrait être réglé (mais pas la peine de mentionner non plus un FIXME s'il manque soit un nom soit une référence pour une route). Exemples de FIXME : * mentionner qu'il y a désaccord entre plusieurs sources, ou une ambiguité sur les dates de ces sources, ce qui ne permet pas de prendre une décision. * mentionner que des données d'un import n'ont pas pu être traitées de façon automatique, et qu'un tag (par exemple description) contient des données à interpréter depuis la description, données qu'on peut alors reclasser dans d'autres tag. * mentionner un doûte sur une valeur * mentionner un tracé douteux, même si le validateur ne signale rien, par exemple des numéros de voies différents dans la même commune et pour le même nom alors que ces voies sont connectées, ou bien deux voies éloignées (non connectées), qui utilisent le même nom et la même référence au sein de la même zone de numérotation (par exemple dans la commune pour les voies communales, dans le département pour une route départementale ou un chemin départemental, le pays entier pour une route nationale ou une autoroute) Noter cependant ces disjonctions arrivent dans certains cas sur un tronçon où la route change temporairement de classification car le tronçon de raccordement n'est pas encore construit ou aménagé (un exemple en est l'A84 qui est disjointe à Avranche, car le tronçon de raccordement se fait encore par la N 175 qui traverse la ville (et se prolonge ensuite : il manque encore le tronçon autoroutier en rocade d'Avranche, qui ne figure même pas encore sur les chantiers; en attendant c'est la nationale, qui a été réaménagée, mais pas suffisamment pour avoir la classification autoroutière). Ces disjonctions ne sont donc pas toujours des erreurs, raison pour laquelle le validateur ne signale rien. Un FIXME en revanche peut être utilisé temporairement pour des erreurs à vérifier et corriger plus tard. Si la vérification a eu lieu, et qu'il n'y a pas d'erreur, ce FIXME sera à remplacer par une note mentionnant que la disjonction est normale en l'état actuel des lieux. Osmose n'affiche pas réellement les fixme mis en valeurs d'une clé (hormi si cela est contraire à d'autres règles de toponymie ou de typographie et capitalisation), mais détecte bien les noms de clés fixme ou FIXME. La présence d'un tel FIXME ne permet aucune correction automatique. Il faut un contrmole humain qui ne se contentera pas de le supprimer car ils ont une raison d'être. Le 8 février 2012 18:00, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : HELFER Denis Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse +1 pour le pré-traitement des fichiers -houses avant leur mise à disposition, pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de Bruno par ex. En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. Pour moi la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains que ces FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou ignorer un FIXME, je vois peu de différence (vu de ma lorgnette). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
- Mail d'origine - De: partir-en-vtt ad...@partir-en-vtt.com À: talk-fr@openstreetmap.org Envoyé: Tue, 07 Feb 2012 14:45:00 +0100 (CET) Objet: Re: [OSM-talk-fr]Import bâti = nettoyage des données cleo carto JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? + lancer la validation. + dans la fenetre ou apparait l'analyse du validator + clic sur le sens interdit pour faire apparaitre le détail des erreurs + clic sur le type d'erreur = il apparait le bouton réparer. je te dis cela de souvenir, je n'ai pas josm sous la main... didier -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- didier --mapeur amateur-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, De : partir-en-vtt La superposition n'est pas représenté comme une erreur mais un avertissement. De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? Le Validator passe une erreur pour 2 bâtiments rigoureusement superposés (même suite de nodes pour définir les 2 bâtiments). Dans ce cas, on a une erreur Chemins dupliqués et la possibilité de réparer en un clic. Idem pour des noeuds superposés. En revanche pour des bâtiments partiellement superposés (chacun n'ayant qu'une partie de sa surface superposée à l'autre), on n'a en effet qu'un warning Bâtiments se chevauchant, et là, il faut sa souris, son clavier, et un peu de temps :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
- Mail d'origine - De: partir-en-vtt ad...@partir-en-vtt.com À: talk-fr@openstreetmap.org Envoyé: Tue, 07 Feb 2012 15:39:08 +0100 (CET) Objet: Re: [OSM-talk-fr]Import bâti = nettoyage des données cleo carto Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. = les noeuds ne doivent pas avoir exactement les memes coordonnées ... De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? = cela semble la seule issue ... oui ! -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- didier --mapeur amateur-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Tue, 7 Feb 2012 06:39:08 -0800 (PST), partir-en-vtt wrote: Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. le validator leve plusieurs erreurs - des ways en double, donc des batiments en double/triple depuis le cadastre - des points qui ont les même coordonnées mais qui sont deux points différents - des points qui sont mis deux fois dans le même way (et pas pour boucler le batiment) - d'autres dans les 2 premiers cas, je crois qu'il propose l'action de correction De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? pour certains cas, oui tu a un ID de way ? -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
C'était pour un nouvel import et bon 70 retouches à la mano, ce n'est quand même pas la joie. Je vais donc continuer à créer une moulinette corrigeant ces soucis. -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463462.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, partir-en-vtt wrote: JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est pas bien. Explications : - C'est un boulot manuel de fou - Y'a déjà du pourri dans la base - un logiciel pourrait en réparer une grande partie automatiquement - D'autres ne feront de toute façon pas cette effort J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait : 1) développer un robot qui nettoye le merdier des bâtiments 2) ne rien faire Dans les deux cas, rien ne justifie selon moi de perdre du temps contributeur qui serait mieux employé à autre chose. ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était pas une bonne idée, je dis que ça n'est de toute façon pas suffisant -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 7 février 2012 16:31, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 7 février 2012, partir-en-vtt wrote: JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est pas bien. Explications : - C'est un boulot manuel de fou - Y'a déjà du pourri dans la base - un logiciel pourrait en réparer une grande partie automatiquement - D'autres ne feront de toute façon pas cette effort J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait : 1) développer un robot qui nettoye le merdier des bâtiments 2) ne rien faire Dans les deux cas, rien ne justifie selon moi de perdre du temps contributeur qui serait mieux employé à autre chose. ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était pas une bonne idée, je dis que ça n'est de toute façon pas suffisant +1 Je ne vois pas non plus quel problème cela pose réellement d'avoir des petits chevauchements de bâti et un de ces 4 on aura bien un algo qui remettra ça au propre. Par contre, les chevauchements avec les highway existants sont à corriger... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
2012/2/7 Christian Quest cqu...@openstreetmap.fr: +1 -1 (comme d'hab) Corriger le bâti ne nécessite pas tant de travail que ça. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées (c'est un peu ce qu'on lit entre les lignes, après tout, ça n'est pas si grave). Et à partir de quel pourcentage on considère que le chevauchement est grave, donc une erreur ou un doublon ? Faudra-t-il aussi accepter ce genre de chevauchements pour d'autres entités comme les landuse ou les boundaries ? Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Notre discours dans ce domaine doit vraiment rester dans la recherche constante de l'amélioration des données et non du statu quo (c'est aussi très important vis-à-vis des nouveaux arrivants qui peuvent nous lire). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le mardi 07 février 2012 17:49:24, Pieren a écrit : 2012/2/7 Christian Quest cqu...@openstreetmap.fr: +1 -1 (comme d'hab) Corriger le bâti ne nécessite pas tant de travail que ça. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées (c'est un peu ce qu'on lit entre les lignes, après tout, ça n'est pas si grave). Et à partir de quel pourcentage on considère que le chevauchement est grave, donc une erreur ou un doublon ? Faudra-t-il aussi accepter ce genre de chevauchements pour d'autres entités comme les landuse ou les boundaries ? Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Notre discours dans ce domaine doit vraiment rester dans la recherche constante de l'amélioration des données et non du statu quo (c'est aussi très important vis-à-vis des nouveaux arrivants qui peuvent nous lire). Pieren +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Je ne suis pas d'accord sur le c'est pas grave, je pense juste que corriger à la main est une perte de temps qui serait mieux employé. Je suis bien évidement pour qu'un courageux nous développe l'outil qui corrigera ce qui peut se corriger de manière automatique. Corriger le bâti ne nécessite pas tant de travail que ça. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... Tant pis pour eux, justement, on a pas cette non-chance, c'est pas parce que c'est pire ailleurs qu'on doit accepter de se transformer en robots ! L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées Pas d'accord, quand bien même l'hypothèse qu'aucun script n'existe jamais, cela n'invalide pas que l'on puisse quand même le faire, a posteriori, à la main. Alors entre le faire tout de suite, et le faire peut-être plus tard, je préfère le peut-être plus tard Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Tue, 7 Feb 2012 17:49:24 +0100, Pieren wrote: 2012/2/7 Christian Quest cqu...@openstreetmap.fr: +1 -1 (comme d'hab) +1 avec pieren par contre, j'ai justement corrigé pas mal de truc de ce genre dont l'auteur etait le pieren_bot... ;) j'essaye de faire en sorte qu'il n'y ai plus d'erreur validator/JOSM quand j'importe du bati. Ou tout du moins que je ne rajoute pas d'erreurs. Corriger le bâti ne nécessite pas tant de travail que ça. ca depend des communes quand il y a +300 erreurs, c'est un peut decourageant. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées (c'est un peu ce qu'on lit entre les lignes, après tout, ça n'est pas si grave). Et à partir de quel pourcentage on considère que le chevauchement est grave, donc une erreur ou un doublon ? Faudra-t-il aussi accepter ce genre de chevauchements pour d'autres entités comme les landuse ou les boundaries ? Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Notre discours dans ce domaine doit vraiment rester dans la recherche constante de l'amélioration des données et non du statu quo (c'est aussi très important vis-à-vis des nouveaux arrivants qui peuvent nous lire). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 7 février 2012 18:43, sly (sylvain letuffe) li...@letuffe.org a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. +1 pour Pieren ce qui fait 3-2 ;) Pour avoir fait pas mal d'import du bâti, je me suis toujours astreint à corriger les chevauchements. Cela me semble normal que de ne pas envoyer des données pleines d'erreurs et franchement ce n'est pas si la mort que ça... Je ne suis pas d'accord sur le c'est pas grave, je pense juste que corriger à la main est une perte de temps qui serait mieux employé. Je suis bien évidement pour qu'un courageux nous développe l'outil qui corrigera ce qui peut se corriger de manière automatique. Corriger le bâti ne nécessite pas tant de travail que ça. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... Tant pis pour eux, justement, on a pas cette non-chance, c'est pas parce que c'est pire ailleurs qu'on doit accepter de se transformer en robots ! L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées Pas d'accord, quand bien même l'hypothèse qu'aucun script n'existe jamais, cela n'invalide pas que l'on puisse quand même le faire, a posteriori, à la main. Alors entre le faire tout de suite, et le faire peut-être plus tard, je préfère le peut-être plus tard Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Salut,
Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les
fichiers Cléo.
http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html
Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des
testeurs pouvaient faire un retour sur la qualité des fiabilisations. Pas
la peine de faire un import, un petit coup de validator avant/apres, une
superposition des couches pour vérifier que l'on respecte la géométrie,
qu'on perd pas les relations multipolygone Et on pourrait mettre ça
dans la chaîne de génération Cléo, et (presque) fermer le robinet.
L'étape suivante c'est l'automate évoqué par sly : appliquer l'équivalent
au bâti OSM détecté en ano par Osmose.
A+
Bruno
#!/usr/bin/python
# -*- coding: utf8 -*-
from rtree import Rtree
import OsmSax, sys
DIST_MIN = 1.0e-12
def coords(n):
return (n.lat, n.lon)
def distance2(a,b):
xa, ya = coords(a)
xb, yb = coords(b)
return (xa-xb)**2 + (ya-yb)**2
class Node(object):
def __init__(self, id=None, lon=None, lat=None, tags=None):
self.id = id
if lon != None: self.lon, self.lat = float(lon), float(lat)
if tags:
self.tags = tags
else:
self.tags = {}
self.inWay = set()
self.inRel = set()
class Way(object):
def __init__(self, id=None, nodes=None, tags=None):
self.id = id
if nodes:
self.nodes = nodes
else:
self.nodes = []
if tags:
self.tags = tags
else:
self.tags = {}
class Relation(object):
def __init__(self, id, members=None, tags=None):
self.id = id
if members:
self.members = members
else:
self.members = []
if tags:
self.tags = tags
else:
self.tags = {}
def __repr__(self):
return Relation(id=%r, members=%r, tags=%r) % (self.id, self.members, self.tags)
class Cache:
def __init__(self):
self.nods = {}
self.ways = {}
self.rels = {}
def NodeCreate(self, data):
self.nods[data[id]] = Node(id=data[id],lon=data[lon],lat=data[lat],tags=data[tag])
def WayCreate(self, data):
self.ways[data[id]] = Way(id=data[id],nodes=data[nd],tags=data[tag])
def RelationCreate(self, data):
self.rels[data[id]] = Relation(id=data[id],tags=data[tag],members=data[member])
###
fout = sys.argv[2]
data = OsmSax.OsmSaxReader(sys.argv[1])
cache = Cache()
print 'Parse du fichier...'
data.CopyTo(cache)
idxNode = Rtree()
tabindx = {}
print 'Indexation...'
i = 0
for k in cache.nods.keys():
i += 1
idxNode.insert(i, coords(cache.nods[k]))
tabindx[i] = cache.nods[k]
# set des chemins utilisant un noeud
for w in cache.ways.values():
for nid in w.nodes: cache.nods[nid].inWay.add(w)
# set des relations utilisant un noeud
for r in cache.rels.values():
for m in r.members:
if m['type'] == 'node': cache.nodes[m['ref']].inRel.add(r)
print 'Simplification des noeuds...'
# balayage des noeuds à simplifier
for noeud in cache.nods.values():
#print 'traitment', noeud.id
# le noeud a-t-il déjà été supprimé
if not cache.nods.has_key(noeud.id): continue
# recherche des noeuds proches
for i in idxNode.nearest(coords(noeud),4):
np = tabindx[i]
if np == noeud: continue
if distance2(noeud, np) DIST_MIN:
noeud.tags['fixme']='simplify'
#remplacement du np par noeud dans les ways
for w in np.inWay:
while np.id in w.nodes :
ind = w.nodes.index(np.id)
w.nodes[ind]=noeud.id
#suppression np de l'index
idxNode.delete(i,coords(np))
#suppression de la liste des noeuds
del cache.nods[np.id]
print 'Nettoyage des chemins...'
for w in cache.ways.values():
i = 1
# balayage des segments d'un way
while (len(w.nodes) 1) (i len(w.nodes)):
if w.nodes[i-1] == w.nodes[i]:
w.nodes.pop(i)
continue
i += 1
print 'Ecriture...'
out = OsmSax.OsmSaxWriter(fout, UTF-8)
out.startDocument()
out.startElement(osm, {'version':'0.6'})
for n in cache.nods.values():
out.NodeCreate({'id':n.id,'lon':n.lon,'lat':n.lat,'tag':n.tags})
for w in cache.ways.values():
out.WayCreate({'id':w.id,'nd':w.nodes,'tag':w.tags})
for r in cache.rels.values():
out.RelationCreate({'id':r.id,'member':r.members,'tag':r.tags})
out.endElement(osm)
#!/usr/bin/python
# -*- coding: utf8 -*-
from rtree import Rtree
import OsmSax, sys
from shapely.geometry import Point, LineString
DIST_MIN = 2.0e-6
def coords(n):
return (n.lat, n.lon)
def procheWay(nd, p1, p2):
#renvoie vrai si node est pres du segment formé par p1,p2
no=Point(coords(nd))
no1=Point(coords(p1))
no2=Point(coords(p2))
seg = LineString([coords(p1),
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Personnellement, j'ai développé un traitement sous FME qui enlevait/corrigeait les superpositions. Les points dupliqués peuvent être aussi traités. Le seul souci résidait dans le fait de détecter les mauvaises découpes dans le bâti...Malheureusement on aura pas un noyau FME à dispo pour les traitements à moins que safe software fasse un geste en nous mettant à dispo un FME server à disposition pour le projet OSM. -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5464122.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
- Mail d'origine - De: sly (sylvain letuffe) li...@letuffe.org À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Tue, 07 Feb 2012 18:43:59 +0100 (CET) Objet: Re: [OSM-talk-fr]Import bâti = nettoyage des données cleo carto Je ne suis pas d'accord sur le c'est pas grave, je pense juste que corriger à la main est une perte de temps qui serait mieux employé. sur ce point je suis et d'accord et pas d'accord j'ai recherché les zones ayant le plus grand nombre d'erreur de chevauchement (cumul des erreurs detectées par osmose) La premiere source d'erreur , c'etait des upload ratés (beaucoup trop...) après soit - il n'y avait que des erreurs de chevauchement minime - beaucoup d'autres erreur : highway residential/unclassified vs building - probleme de delimitation de communes et de batiment sur 2 communes pour les fichiers cadastre, le nombre d'erreurs que j'ai corrigé est compris entre 0 et plus de 800... (ce n'est pas forcement lié au nombre de building). didier --mapeur amateur-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un patelin de 300 habitants, c'est moins de boulot qu'une banlieue de plusieurs milliers d'âmes (genre Kingersheim au hasard). L'enjeu et le travail reste le même : 1. on laisse faire les outils en attendant qu'ils s'améliorent (sur quels critères d'abord ?) et on a ce que l'on mérite 2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un seul tour quand elle découvre que des miettes de qualité peuvent être grapillées (la fourmi est écolo dans l'âme). La fourmi est besogneuse, sinon c'est une cigale déguisée en fourmi. L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord A l'analyse, il semble que les outils (et autre méthodes d'import de masse) soient tolérés dans la mesure où la colonie ne s'assied pas sur le tas de données produit d'un air satisfait : ça c'est fait, mais prend pelle et pioche pour remuer le tout et l'intéger au reste de la base. Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. Repense à HAL9000 Chacun est responsable de ses apports (tiens cela ressemble encore trop à imports) à la base. Chaque contributeur est, de fait, responsable du niveau de qualité qu'il injecte dans la base. Noboby is perfect (as a ro(b)ot ?), mais on moins on aura mis de la transpiration dans cette base ; c'est ce qui devrait faire son odeur si particulière, appréciée par certains. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Pour ma part, quand j'ai un doute, je regarde avec l'imagerie disponible. Il est vrai que dans le Puy de Dôme, j'ai la chance de disposer de Bing 2010-11 avec une précision de 30cm ainsi que CRAIG 2009. (même précision). Reste que c'est un boulot de ... dentelière. ( :) ) -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5432997.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote: J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était de proposer une moulinette pour nettoyer les erreurs de l'import du bâti. L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me semble qu'il y a moins d'erreurs qu'avant. Pour autant tout n'est pas parfait et j'ai repéré que la majorité des erreurs sont : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Qu'il y a parfois une utilisation trop importante de nœuds, Qu'il y a des coupures dans les bâtiments qui sont inutiles. comment savoir si la coupure est justifié ou pas ? C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment déterminer automatiquement si oui ou non il s'agit d'un artefact ? Faut-il fusionner les morceaux qui sont triangulaires et/ou qui ont une surface déterminée ? Je fais appel à vos idées. josm propose une selection par la surface. On peut sortir tous les building qui ont une surface = 0m^2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 26 janvier 2012 15:56, jul...@krilin.org a écrit : On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote: J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était de proposer une moulinette pour nettoyer les erreurs de l'import du bâti. L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me semble qu'il y a moins d'erreurs qu'avant. Pour autant tout n'est pas parfait et j'ai repéré que la majorité des erreurs sont : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Qu'il y a parfois une utilisation trop importante de nœuds, Qu'il y a des coupures dans les bâtiments qui sont inutiles. comment savoir si la coupure est justifié ou pas ? Ce sont effectivement les erreurs les moins évidentes à identifier. De mon côté, je m'aide de la couche cadastrale, de l'imagerie Bing et en dernier ressort de l'observation sur le terrain mais tout ça c'est à la main donc long. C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment déterminer automatiquement si oui ou non il s'agit d'un artefact ? Faut-il fusionner les morceaux qui sont triangulaires et/ou qui ont une surface déterminée ? Je fais appel à vos idées. josm propose une selection par la surface. On peut sortir tous les building qui ont une surface = 0m^2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 26/01/2012 15:56, jul...@krilin.org a écrit : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Si quelqu'un veut se pencher sur le code de Qadastre (le mieux) ou créer un code/script pour nettoyer les fichiers cléo (pis aller), pas de soucis, je le mets en place. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
