Contactez-nous
 

Le géocodage à petits points


Session Etat et Collectivités Locales
 


Philippe Lézé
philippe.leze@mairie-boulogne-billancourt.fr
Direction des Systèmes Informatiques

 
Mairie de Boulogne-Billancourt
26, avenue André-Morizet
92100 Boulogne-Billancourt
 

 

Mots-clés, logiciels ESRI utilisés et publics visés
 


Mots-clés :

Logiciels ESRI utilisés :

Public visé :

 

Introduction


Boulogne-Billancourt est la ville la plus importante de la région parisienne, après Paris, et possède une population d'environ 110 000 habitants pour une superficie de 617 hectares. On imagine donc très bien que c'est une ville dense. Cette densité a eu comme conséquence la création, dans le milieu des années 90, de sept quartiers.
J'avais déjà été confronté, lors du Recensement Général de la Population, en 1990, au problème du géocodage : lorsque je reçois un bulletin de recensement qui a été retourné par la Poste, comment vais-je pouvoir identifier l'agent recenseur concerné ? J'avais dès lors pris toute la mesure et la difficulté de ce que je ne connaissais pas encore sous le terme de géocodage : une rue pouvait être recensée par une petite vingtaine d'agents…, et à cette époque je n'étais que le responsable du Bureau des élections, organisateur au sein de la mairie, et pour l'INSEE, de ce recensement.
Lorsque, quelques années et quelques métiers après, je commençais à mettre en place le SIG de la Ville, je fus rapidement confronté à ce problème que nous avions à cette époque un peu évacué, faute de solution suffisamment pratique.
Emballé par les outils fabuleux mis à notre disposition par ArcView 3.0a, je décidais, grâce à une licence Géoroute acquise auprès de l'IGN, de mettre en œuvre ce fameux géocodage.

Après une période d'apprentissage qui fut plus ou moins fastidieuse (je rappelle seulement pour mémoire que le géocodage français était livré à part), je pus enfin me livrer aux joies de l'approximation orthographique et de la numérotation.

Le principe même du géocodage à la française repose sur deux éléments :
1)      L'existence des voies sous forme de polylignes
2)      La constitution des attributs, selon le modèle gauche-droite, mis en œuvre par le décret du 4 février 1805 (en ce qui concerne la numérotation des rues à Paris, système étendu plus tard à toute la France, l'article 4 précise que la série des numéros sera formée des nombres pairs pour le côté droit de la rue, et des nombres impairs pour le côté gauche).


Si le premier point ne pose en général que peu de problèmes, le second, en revanche, se révèle beaucoup plus retors, sous des aspects assez anodins, tout au moins pour une ville comme Boulogne-Billancourt.

Le contexte géographique : Boulogne-Billancourt est une ville baignée par la seine, et à l'urbanisation dense.
Dans ces conditions, le système de numérotage trouve assez vite ses limites : sur un bord de fleuve, la numérotation n'est plus sur le mode 2-4-6-8, mais est effectuée en continu (1-2-3-4-5).

Le modèle de géocodage donne donc un résultat correct, pour les rues qui ne sont pas bordées par un fleuve ; dans le cas présent, il faut accepter que les points placés ne correspondent pas exactement à la réalité… en effet, lorsque l'on habite sur une péniche, la numérotation s'effectue de la manière suivante : "Face au n°". Il est donc difficile, techniquement, de compléter des attributs de type numérique par des attributs de type texte.

L'autre écueil de ce type de numérotation vient de la densification toujours plus importante de la ville. Il est fréquemment arrivé qu'une parcelle de grande taille, suite aux vicissitudes de la vie et à l'augmentation du prix du foncier, soit divisée en plusieurs petites parcelles. La numérotation traditionnelle étant déjà implantée, on se trouve donc dans l'obligation, pour différencier les immeubles, de rajouter un attribut de type bis, ter, quater, voire quinto !!!
 
À ces deux écueils, on peut en rajouter un troisième, qui se révèle au final au moins aussi redoutable que les deux premiers réunis : je veux parler de la qualité des données à géocoder. L'informatique ne supportant que le mode noir/blanc, on constate rapidement que la normalisation des noms de rue est une pure vue de l'esprit… je veux parler ici de l'imagination quasiment sans limites des agents affectés à la saisie des adresses : un même nom de rue peut être écrit de multiples façons, jusqu'à notre record de 88, pour l'avenue Jean-Baptiste-Clément…


La méthode


Tout d'abord je vais parler de notre équipement en matière de Sig :
Nous possédons une architecture relativement complète, car elle se compose de licences ArcView et Arc Editor, ainsi que d'un serveur ArcSDE sous Oracle. Et puis, bien sûr, de licences Excel, car c'est à partir de cet interface que l'on procède au géocodage.

Le fonds disponible :


1)      il est constitué d'une couche de ponctuels et a été élaboré à partir des données cadastrales fournies par la DGI (à l'époque, en DXF). Ces données issues d'AutoCad ont été intégrées dans notre système notamment grâce à la licence Imacad que nous possédions alors. Le principe retenu dès cette époque a été de coder les adresses sur le principe d'un n° (aussi bien alphanumérique que numérique) concaténé avec un code de rue. Divers autres attributs ont bien sûr été ajoutés au fur et à mesure des besoins, mais le fonds est réellement constitué par ce code. 
Un circuit de diffusion des arrêtés municipaux permet la mise à jour quasiment en temps réel.

2)      Nous avons par ailleurs une table Oracle des noms de rues qui intègre la totalité des manières d'écrire un libellé de rue.
La mise à jour de cette table se fait lorsqu'un utilisateur nous fournit une table Excel avec des données à géocoder : si une rue n'existe pas dans notre table de référence, le résultat retourné est un message d'erreur de type "#N/A". On a donc ainsi une vérification et une possibilité d'enrichissement permanent des tables de référence.

3)      À la suite de cette table, et toujours dans un souci de rationalisation, nous avons créé une table des noms de rue uniques. Les attributs de cette table sont donc composés d'un nom de rue, d'un code commun à tous les utilisateurs, et d'un nom disponible pour la saisie alphabétique sous la forme "Jean-Baptiste-Clément (Avenue)".
Il est donc, là encore, assez facile de procéder à la création d'une rue, ce que nous pouvons vérifier assez régulièrement en ce moment, avec la métamorphose des terrains Renault.
 
4)      Une fois que cette architecture est mise en place, ne reste plus à réaliser que la consultation de ces données.
Cette étape est réalisée assez simplement, grâce à Excel. La mise en œuvre d'une feuille de calcul permet à un utilisateur, par les partages réseau, de faire la saisie des ses adresses par un copier/coller. Dans le cas ou les adresses fournies n'ont pas la séparation du n° et des noms de rue, un onglet permet cette séparation.
 
À partir du moment où ce contrôle formel est réalisé, il ne reste plus qu'à effectuer un copier/coller des informations pour pouvoir récupérer plusieurs types d'attributs, en fonction de l'utilité que l'on en aura : si l'on veut simplement créer une couche temporaire ou une couche qui supporte une relation de n à 1 (plusieurs élèves, électeurs à 1 adresse), il suffira de réaliser un tableau, et de l'incorporer à un projet mxd, avec les attributs X et Y. un export pourra ensuite permettre une création de table avec un ObjectID, si le besoin s'en fait sentir.
 
Dans le cas ou l'on souhaite récupérer des informations issues des attributs d'origine de la table de points, voire de réaliser une cartographie régulière avec une mise à jour permanente des données sources, on pourra réaliser une jointure attributaire sur le Code_Rue. C'est l'exemple de la cartographie du logement social (un bâtiment, une adresse)
En ce qui concerne les données d'origine, les traitements Excel sont suffisamment puissants pour que l'on puisse affiner au fur et à mesure des résultats (par exemple, enlever le tiret lorsque l'on ne trouve pas une adresse de type 81-85).

Les besoins, tout au moins à Boulogne-Billancourt, sont suffisamment connus aujourd'hui pour que l'on sache que la précision réclamée lors d'un géocodage est assez approximative, puisque l'on géocode rarement avec une précision supérieure au 1/1000. Une approximation –légère- est donc tout-à-fait supportable.


Cette architecture a donc été réalisée grâce à Excel et à ses capacités à se connecter à une source de données externe.


Les limites :


Outil assez puissant de géocodage, car évolutif, cet outil n'en est pas moins pourvu de quelques défauts :-          une adresse recherchée doit avoir une exacte correspondance avec la cible, sous peine de se voir retourner un code d'erreur.
- Comme un utilisateur n'hésite pas à créer un nom de rue parfois orthographiquement douteux, il faut pouvoir analyser les données saisies. L'avantage de l'inconvénient, c'est que l'on a les moyens d'interpeller le demandeur sur la réalité de l'adresse qu'il nous a soumise, et de lui restituer un fichier avec la mise en valeur de ces adresses douteuses.
- La mise à jour, nettement améliorée sous ArcGis dès la version 9.2 reste quand même un moment parfois un peu lourd…
- Lorsque l'on parle de géocodage, on pense souvent au géocodage postal, mais, lorsque l'on travaille dans une mairie, et que l'on a à faire avec la quasi-totalité des services, on se rend compte que souvent, le positionnement d'évènements ne se produit pas forcément sur une adresse postale : on peut avoir à positionner un point sur un carrefour (en matière de sécurité notamment), ou sur une portion de carrefour (positionnement de corbeilles à papier).
           o   Le 1er cas oblige à créer, dans la feuille de calcul, une colonne de référencement spécial. L'utilisateur y perd parfois son latin. Cela implique donc des vérifications de saisie.
           o   Le second cas permet de réaliser un positionnement plutôt approximatif, qu'il est assez facile de rectifier avec un minimum de manipulations manuelles.
- S'il semble difficile de faire réaliser par un néophyte un géocodage assez correct, sa mise en œuvre, à travers Excel, est là, envisageable, bien que l'on soit obligé de construire un tableau pour chaque utilisation.


L'avenir


Le processus de géocodage que nous avons mis en place nous donne suffisamment de satisfactions pour que nous n'envisagions pas d'évolution majeure. Il s'agira bien plutôt d'aménagements pour pouvoir minimiser les interventions manuelles. Je pense particulièrement au cas des carrefours qui, aujourd'hui sont traités graphiquement sous une forme peu satisfaisante : il existe un point par entrée de carrefour. Un rond-point comme la place Marcel-Sembat rencontre 8 autres routes. Le nombre de points représentant ces carrefours s'élève donc à une petite vingtaine !!! il nous faudra donc sérieusement envisager la création d'une table de conversion qui limitera le nombre de points de la couche des adresses, et facilitera la saisie pour les utilisateurs.

Pour plus d'informations sur le géocodage à points, cliquez ici.
Taille : 1285 ko - Dernières modifications : 25/08/2009
 

© ESRI France
Accueil - Communications Utilisateurs - Plénière - Ateliers - Concours - Partenaires