Le 31/10/2013 14:05, Tyndare a écrit :
Le 25 octobre 2013 14:53, Frédéric Rodrigo <fred.rodr...@gmail.com
<mailto:fred.rodr...@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.
_______________________________________________
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
