[OSM-talk-fr] Import automatique du bâti

[Pierre]

Salut RatZilla$

On Tuesday 16 November 2010 19:19:37 RatZilla$ wrote:
> Tout d'abord Pierre,
> 
> MERCI (Encore un Pierre à qui je dois du Rhum pour ne pas avoir oublié les
> DOM) MÈCI AN PIL / ONLO / AN CHAY' en remerciement:gcf
De rien :)

> Ensuite voilà mon premier retour de "script runner" pour les DOM et
> les Bouches du Rhône où je suis le plus actif.
> 
> Le fichier rail correspond aussi aux limites de quartier et de
> commune, en les assemblant on obtient la limite de commune.
> Ça c'est génial pour les limites de communes non encore tracées !
Personne ne semble apprécier les cimetières ? :)

> Les piscines apparaissent en natural:water au lieu de
> amenity:swimming_pool. Or Mapnik fait un rendu particulier pour les
> piscines (pour le projet que j'ai avec les pompiers c'est une donnée
> importante pour les feux de forêt)
Ok, ça c'est un truc auquel j'ai pas fait très attention... Les piscines dans le 
Nord, c'est plutôt rare quand même :)
Les scripts bash et perl d'import du cadastre gèrent ça ? J'ai tenté de 
reprendre autant que possible leurs paramètres pour essayer de ne pas faire 
d'erreurs...

> Pour le 13  c'est OK en tout cas pour Lambesc (bâti bien calé donc
> projection correcte).
> Martinique OK (testé sur St Joseph)
> Guyane Échec [Unable to initialize source projection - Aborted testé
> sur Cayenne]
> Réunion Échec [Unable to initialize source projection - Aborted testé
> sur St Denis]
Pour ces cas, la correction serait à faire dans osmgenerator.cpp, fonction 
QList<QPointF> OSMGenerator::convertToEPSG4326(const QList<QPointF> &points)

> Guadeloupe OK sur les communes en GUAD48UTM20 (testé sur Deshaies) en
> effet:
> 
> Sur mon ile natale il y a un petit bug de projection car la Guadeloupe
> est un archipel avec deux projections
> GUADFM49U20 pour:
> Saint Martin ZS127 - SAINT MARTIN (97150)
> Saint Barthelemy ZS123 - SAINT BARTHELEMY (ILE) (97133)
> et
> GUAD48UTM20
> Pour toutes les autres communes
Je prend les données directement depuis le cadastre, et je tente de les 
appliquer directement dans proj4 en les préfixant par IGNF:.
Exemple : IGNF:RGF93CC50
Si le cadastre ne donne pas les bonnes projections pour ces villes (et c'est 
apparemment le cas), c'est plutôt bloquant.
Puisque tu connais bien mieux ces cas que moi, tu peux aller corriger le code 
dans cadastrewrapper.cpp, ligne 153:
pdfRep->setProperty("boundingBox", projExtracton.cap(1).trimmed() + ":" + bbox);

Il te suffit de tester sur les valeurs de cityCode a priori, si tu as un nombre 
d'erreurs limité.

J'ai choisi gitorious pour héberger ce code pour que tout le monde puisse 
librement cloner, patcher, adapter, massacrer, bidouiller... tout en gardant 
public (du moins, je l'espère) le code pour que tout le monde en profite...
Bien sûr, si pour une quelconque raison il fallait passer au SVN 
d'OpenStreetMap, ou si tu ne voulais pas avoir de compte sur gitorious, 
j'accepte les patchs par mail...
> Si j'y arrive je te ferai un commit de correction de ton code.
> 
> Testé sur :
> Debian GNU/Linux squeeze/sid
> Noyau  2.6.32-5-amd64  x86_64
> proj4 version 4.7.0-1
À peu près la même chose ici...


 Pierre
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 198 octets
Desc: This is a digitally signed message part.
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20101116/9af12461/attachment.sig>