[OSM-dev-fr] Import addr:housenumber depuis le cadastre

[Frédéric Rodrigo]

Le 31/10/2013 14:05, Tyndare a écrit :
>
> Le 25 octobre 2013 14:53, Frédéric Rodrigo <fred.rodrigo at gmail.com
> <mailto:fred.rodrigo at gmail.com>> a écrit :
>
>     Tu peux également utiliser directement les opérateur de dessin de
>     base du PDF, ça évite un passage en SVG. Soit directement dans le
>     code de Qadastre, soit en exécutant un script depuis Quadastre en
>     lui passant les primitives (c'est comme ça que j'avais fait)
>
>
> Cela serait surement beaucoup plus efficace en terme de performance,
> mais je ne suis pas très à l'aise en C++, et je me suis perdu dans la
> spec du format PDF. SVG m'a parut plus simple, mais je me trompe peut être.

Il n'y a pas grand chose à faire en C++, juste appeler une cmd externe 
et écrire les données dans un fichier. Ensuite tu peux coder en python.
Je n'ai pas retrouvé mon code qui faisait ça.
Coté PDF pas besoin de la spec, c'est aussi simple que le svg pour faire ça.

>
>         Pour détecter les numéros de rue, j'ai codé en dure un "path"
>         (au sens svg) correspondant à chaque numéro (0-9 et les lettres
>         B,T,Q,A,B,C,D,E,F), et je fait une transformation pour les
>         comparer. Je filtre ensuite selon la taille pour ne garder que
>         les numéros de rue (et éviter les numéros de parcelles).
>
>
>     Quel genre de transformations et de comparaison tu fais (je n'ai pas
>     pris le temps de regarder le code) ?
>     J'avais rencontré des problèmes la dessus : détermination de
>     l'orientation du texte, du mal à comparer les shapes entres elles
>     pour déterminer le caractère. Le path variait en fonction de la
>     taille de la commune et de son orientation.
>
>
> Je commence par comparer les commandes qui composent les paths, si ce
> sont exactement les mêmes, alors je compare les coordonnées de la liste
> des points qui composent les paths (par rapport au format SVG j'ai en
> fait normalisé la représentation des path pour n'avoir que des
> coordonnées absolue, pas de valeur relatives). Je transforme donc les
> points avec pour chaque path:
>   - une mise à l'échèle de telle manière que le point le plus loin du
> premier se retrouve à une distance de 1.0
>   - une rotation pour que le premier point et le 6ème (choix arbitraire)
> se retrouvent à l'horizontal
> Une fois ces transformations effectuées, je vérifie que la distance
> maximale entre les points des deux paths soit < 0.05
> Je pense donc avoir une vérification assez fiable et ne pas pouvoir
> confondre un chiffre avec un autre, le risque est plus d'en rater
> certains pour des problème de précision.
>
> J'avais aussi à l'origine un problème de variation des path selon la
> taille de la commune, mais je pense que c'était en fait un problème de
> précision du au format PDF, et je crois l'avoir résolu en découpant la
> récupération du cadastre en plusieurs fichiers PDF de taille raisonnable
> (comme le script import-bati.sh).

Tout est là ! Résoudre le problème à la base et faire simple. Chapeau.

>     J'espère que a court et moyen terme on pourra avoir accès aux
>     données d'adresses du cadastre sans avoir à les extraire depuis le
>     WMS. Ces informations sont dans les EDIGEO et il faut à mon avis
>     pousser pour avoir accès à ces données, on a commencé à la faire
>     département par département, il faut poursuivre
>
>
> Passer par les fichier EDIGEO serait effectivement plus sûr et plus
> logique, mais là on sort de mon domaine de compétence.

Oui, mais pas pour toute la France de toute façon.

Je pense qu'une fois le problème de l'extraction passé le plus important 
est de chercher à créer les relations associatedStreet, sans même tenir 
compte de OSM. Ça nous reprocherait de ce que l'on peut avoir en 
OpenData. L'intégration à OSM est, pour moi, un autre problème. (Même 
s'il est vrais que l'on pourrait se servir des infos de OSM pour créer 
la relation).


Frédéric.