Le 8 février 2012 17:44, sly (sylvain letuffe) <li...@letuffe.org> a écrit :
> On mardi 7 février 2012, Bruno Cortial wrote: > > 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 > > Je te propose de passer sur la liste dev-fr histoire de ne pas remplir > plus ce > sujet avant d'y revenir si on a réussi à avancer. > > > 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. > > Hé bé c'est pas facile à lancer ton truc ! les modules python nécessaires > ne > semblent pas présents dans les debian stables, bon, j'ai réussi à m'en > dépêtrer quand même. > > Merci d'y avoir passer du temps ! Je crois que le plus dur est de lire mon code :-) En plus il faut que je m'y remette, j'y ai pas touché depuis des mois... > Quelques remarques à prendre avec pincettes, j'ai pas tout testé : > - En effet, comme s'inquiète julien, si deux bâtiments ou deux murs du même > bâtiment sont séparés par moins que la tolérance ils sont fusionnés. Si ça > pouvait être réservé aux bâtiments qui se chevauches (erreur claire) ça > limiterais les fausses corrections > Je crois que la valeur de tolérence est de l'ordre de 5 centimètres. doit doit pouvoir tuner çà. Sinon la condition d'overlap doit être facilement réalisable avec shaply. D'ailleur il y a eu des release de cette lib depuis, et il y sans doute des choses intéressantes pour ce code. > - Concernant les noeuds dupliqués, a priori rien à dire, cette correction > là > me semble tranquille, mais il faudrait peut-être encore abaissé le seuil. > J'ai eu le cas d'une entrée d'immeuble qui formait un truc genre : > > _||__||_ > > Transformée en : > _/\__/\__ > > C'est juste sur les script des noeuds dupliqués ? Ca m'intéresse. Tu as la commune et l'adresse ? Ca serait ptet' 50 cm finalement :-) > Si d'autres veulent se faire une idée de ce que fait le soft de bruno sur > un > fichier osm réél, on peut s'en faire une idée ici : > http://download.letuffe.org/correction-auto-bati/ > > En bref, ça passe de 320 erreurs de bâtiments se chevauchant, à 60 (selon > le > validateur) > 260 usure de la touche J en moins > > == concernant le "déjà dans la base osm" == > > - J'ai fais une correction pour que le soft conserve les attributs > "version" > des relations/ways/noeuds, ce qui permet de travailler sur des données déjà > dans osm alors que ta version est prévue pour des fichiers osm neufs (id > négatifs) et donc, sans n° de version. > Ce qui est logique, pour être lancé juste après l'export par cleocarto > > C'est le but final, mais déjà qu'on limite le flux de nouveaux cas. Sinon il y a deux autres axe d'amélioration des fichiers Cleo, pour les courageux : * la simplification des géométries, des centaines de points en moins à chaque import. C'est faisable par JOSM, mais il ne simplifie pas les segments partagés par 2 polygones (à contrôler parce ca fait un moment que j'ai pas utiliser cette fonction). J'avais creusé les fonctions shaply, mais sans aboutir, car il y a un risque de perdre la topologie. * Faire le boulot de validator avant en mettant des fixme sur les objets se chevauchant: on gagne du temps, et comme mon script créé des cas qui passe sous le radar de validator... exemple : +-------------+ | | | | +-+------+ | | | | | | +------+------+ +--------+ Après les scripts: +-------------+ | | | | +------+ | | | | +------+------+ Cette situation de chevauchement n'est pas détectée par validator Bruno
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
