Memoire Online - Automatisation et optimisation de chaà®nes de traitements visant à consolider l'attribution d'informations géographiques aux bà¢timents

La chaîne de traitement Building_Use (ou usage des bâtiments) permet de définir pour chaque bâtiment le ou les usages qui l'occupent, que cet usage relève d'une activité économique, d'un équipement ou d'une occupation résidentielle. Chaque usage étant associé à une surface d'occupation et, éventuellement d'un effectif d'emploi ou de ménages et d'habitants. Ces usages doivent être définis afin d'alimenter les modèles TULIP et DYNEX. Le workflow est développé sous FME et fonctionne en trois temps :

- Identification des usages autres que résidentiels principalement en s'appuyant sur les usages. - Génération des bâtiments et locaux d'habitats par SPOC, ainsi que définition des ménages et des personnes.

- les usages des bâtiments d'un territoire ainsi que les surfaces occupées par ces usages (usages

Le workflow traite les usages par grandes catégories d'usages. Ce type de traitement permet de filtrer au fur et à mesure des workflows, les entités en fonction des usages déjà déterminés. Un premier workflow permet de créer la base bâti de référence, de formater et consolider les données SIRENE, les zones d'exclusion et de définir les usages de type indéterminé liés aux bâtiments trop petits.

Les workflows suivants traitent les différentes catégories d'usages. Pour chaque workflow, on ramène les précédents résultats aux bâtiments afin de filtrer les bâtiments dont les usages sont incompatibles. Les points définissant les usages sont snappés soit au bâtiment, soit à la parcelle, soit à la zone d'activité (cela dépend de la catégorie d'activité). La dernière étape consiste à formater les données en fonction du modèle que le workflow devra alimenter. Pour le modèle DYNEX, les données sont consolidées au bloc. Pour le modèle TULIP Expert, les données seront consolidées au bâtiment.

« Le géocodage consiste à affecter des coordonnées géographiques (latitude/longitude) à une adresse postale. Ce procédé conduit à la mise en place de traitement automatisés de manière ponctuelle ou sur des fichiers d'adresses (individus, entreprises, points d'intérêt, etc.).

Les coordonnées géographiques permettent de situer chaque adresse sur une carte numérique via un Système d'Informations Géographiques (SIG). Le géocodage est une des techniques de géolocalisation

Je trouve cette définition appropriée pour une définition générale. Cependant, il me semble que celle-ci ne fournit pas assez de détails quant au processus mis en jeu. J'ai trouvé cette définition sur un site de statistique Canadien :

Le géocodage est le processus utilisé pour attribuer des identificateurs géographiques (codes ou coordonnées x,y) aux détails cartographiques et aux enregistrements de données. Les géocodes ainsi créés permettent d'apparier géographiquement les données à un endroit sur la terre.

Les ménages, les codes postaux et les données sur le lieu de travail sont appariés aux points représentatifs (coordonnées) de côté d'îlot lorsque la rue et l'adresse sont connues, autrement ils sont appariés aux points représentatifs d'îlot de diffusion (ID). En certain cas, les codes postaux et les données sur le lieu de travail sont appariés aux points représentatifs d'aire de diffusion (AD) lorsqu'il n'est pas possible de les apparier aux ID. De plus, les données sur le lieu de travail sont appariées aux points représentatifs de subdivision de recensement lorsqu'il n'est pas possible de les apparier

Cette définition du géocodage, malgré qu'elle ne puisse être utilisée comme définition globale étant donné qu'elle utilise des termes propres à la région canadienne (îlot et aire de diffusion), me parait pertinente. Tout d'abord parce qu'elle ne limite pas le géocodage à une affection de coordonnées géographiques sur une adresse postale, mais aussi parce qu'elle apporte plus de détails sur le procédé en question. En effet le géocodage, peu importe la région sur terre, utilise des échelles géographiques comme niveau de détail et de perfectionnement du résultat. Le mécanisme cherche le plus haut niveau de détails pour affecter les coordonnées, s'il ne trouve pas, il attribuera l'adresse à une échelle plus grossière. En France, les niveaux de détails du géocodage sont les suivants, du plus précis au moins précis (attention, tous les géocodeurs ne permettent pas forcément ce niveau de détails) :

1. Au pays, département, ou à la commune (voire à l'arrondissement) : le point retourné est situé au centroïde de l'entité concernée.

Pour l'entreprise ForCity, le type d'usage de géocodage utilisé est le géocodage de masse. En effet, ForCity utilise un grand nombre de données de toutes sortes provenant de plateforme territoriales denses, à l'échelle des grandes agglomérations, des départements, régions, etc... Plus particulièrement sur les territoires de l'île de France, les agglomérations de Lyon et Rouen, ainsi que Hong Kong à l'étranger.

Pour les besoins de l'entreprise, il est nécessaire de géocoder ces données le plus précisément possible. Il faut savoir que la précision en France du géocodage est moindre, ceci notamment dû au

fait qu'un même code postal couvre un très grand nombre d'adresses (en opposition avec le système anglais, où chaque code postal correspond à une adresses unique géo-référencée).

Comme dis précédemment sur les précisions de ma mission, j'ai dû travailler sur le data-set usage du bâtiment. Autrement dit, travailler à l'échelle du bâtiment, et importer les informations des données géocodées sur les bâtiments correspondants. Hors le géocodage ne permet pas un tel degré de précision. Il y a donc une seconde étape à effectuer pour récupérer ces données et les affectés au bâtiment à proximité. Cette étape se nomme le « Snapping », je détaillerai cette étape plus tard dans le rapport.

Néanmoins, la précision obtenue en sortie du géocodage est véritablement importante car elle simplifie fortement l'opération de Snapping obligatoire qui suit.

Tous les tests que j'ai réalisés ont été effectués à partir d'un fichier CSV qui correspond aux adresses SIRENE. En effet, les données qu'il fallait géocoder au niveau du bâtiment correspondent aux données Sirène de l'Insee, disponibles sur : http://www.sirene.fr/sirene/public/accueil

Les données du répertoire SIRENE portent sur l'ensemble des établissements qui ont une activité sur le territoire Français. Comme je l'ai précisé précédemment, ma mission est focalisée sur le data-set

« usage des bâtiments », les données SIRENE alimentent en grande partie ce data-set notamment pour certains secteurs d'activités comme l'industrie. D'autres sources de données plus spécifiques ont été privilégiées pour d'autres secteurs, comme par exemple le RES¹ pour les équipements sportifs, ou encore les données FINESS² pour les établissements hospitaliers.

L'échantillon sur lequel j'ai testé les différentes solutions comprend les adresses de commerces basées sur le 7ém arrondissement Lyonnais, environ 14 000 adresses. Pour chaque solution, j'ai donné le temps de traitement ainsi que le degré de confiance du résultat obtenu si cela est possible.

J'ai détaillé au possible l'obtention des chiffres qui représentent le degré de confiance, qui dépend du géolocaliseur utilisé. Le but de l'opération étant de comparer les différentes solutions testées pour cibler celles qui pourraient être susceptibles de subvenir aux besoins de l'entreprise en termes de géocodage.

Nombre d'adresses	Intervalle des degrés de confiance	Pourcentage
373	20% à 40%	2,6
216	40% à 60%	1,5
8642	60% à 80%	61,9
6547	80% à 90%	46,9

Le degré de confiance est censé représenté la pertinence du résultat obtenu après l'opération de géocodage. Pour l'API du gouvernement, c'est une note comprise entre 0 et 1, plus elle est proche de 1, plus haute est la précision.

Le code du moteur de géocodage de l'API est basé sur un outil du nom d'Addok. Celui-ci ne donne pas vraiment d'explication sur le calcul de la précision des adresses géocodées.

² Sélection d'informations sur les établissements sanitaires, sociaux, médico-sociaux, et de formation aux professions de ces secteurs

Cette API offre la possibilité de géocoder des adresses en ligne directement sur une API à l'adresse : https://mesadresses.ign.fr/geocod/

Cette API est limitée au géocodage de 100 000 adresses sur 30 jours, et offre la possibilité de sauvegarder ses résultats (donc la base d'adresses géocodée) si l'on possède un compte utilisateur. En ce qui concerne la précision du résultat, l'API assure une finesse de précision élevé car basé sur les données de l'IGN. Je n'ai pas jugé utile de joindre les résultats obtenu étant donnés que l'API de l'IGN requête sur la BAN, comme l'API du gouvernement, les degrés de précision sont les mêmes. Il y a également possibilité de déplacer les marqueurs manuellement, et d'ajouter des adresses sur l'interface graphique qu'offre le logiciel.

Le temps de traitement sur l'échantillon du fichier SIRENE (13992 adresses) est d'environ 28 minutes.

-Précision du géocodage : elle est attribuée par une note (colonne accuracy) qui va de 0 à 8 :

La solution ne semble clairement pas adapté/adaptable à du géocodage de masse.

Il existe une possibilité de géolocaliser en masse grâce au logiciel R et un certain nombre de packages python, notamment les packages Nominatim et Photon qui sont disponibles sur GitHub. Cette solution est basé sur les données OSM et l'Open Data, même s'il est possible sous réserve de bien maîtriser les outils de travailler avec une autre source de données telle que la BAN.

Les résultats donnés par Nominatim et par photon ne sont pas les mêmes. Nominatim semble beaucoup mieux répondre à des requêtes structurées tandis que photon semble mieux s'en sortir quand les requêtes sont un peu floues. Cela est probablement dû au moteur de recherche employé par photon, conçu pour la recherche par auto complétion (et entre autre basé sur les algorithmes n-grams).

Je n'ai pas eu le loisir de tester cette solution, notamment dû aux connaissances confirmées en langage R et Python qu'imposent cette solution.

Ce plugin de QGIS permet de géolocaliser vos adresses issues d'un fichier excel ou CSV. Il se sert de la base BAN (Base Adresse Nationale).

Le fichier des adresses doit être ouvert dans Qgis. L'adresse doit être contenue dans une seule colonne (numero, rue, code postal, ville). Une fois la géolocalisation effectuée, une colonne "score" permet de connaitre la fiabilité de l'adresse, 1 étant la meilleure note (à partir de 0,5, la localisation est fiable).

J'ai testé ce plugin sur un échantillon de 2000 adresses du fichier Sirene, voici les résultats : - Temps de traitement : environ 2 minutes.

J'ai pu tester d'autres solutions de géocodages, qui sont disponibles en annexes. Parmi celles-ci, des solutions web services gratuites comme les précédentes, mais aussi un listing de solutions payantes avec leurs caractéristiques.

Au sein de ForCity, deux solutions de géocodage de masses ont été développées. Une des solutions par Mr. Leysens Thomas se nommant geoloc_csv, et l'autre par Mr. Valorge Amaury se nommant Mass_Geocoder. J'ai obtenu un premier entretien avec Thomas, afin qu'il m'explique les tenants et aboutissants de sa solution, qui se nomme geoloc_csv, puis un second entretient avec Amaury pour les mêmes raisons.

Cet outil a été développé en interne par Mr Leysens Thomas. Il permet à l'aide d'un script python d'interroger un serveur local où distant (data Gouv). On lui fournit un fichier de format CSV en entrée, puis on récupère ce même fichier géocodé en sortie avec un certain nombre d'informations et statistiques sur la qualité et la précision du géocodage. Le script est quant à lui basé sur l'API gouvernementale disponible à l'adresse suivante : https://adresse.data.gouv.fr/api/

Il faut savoir que l'API du gouvernement utilise un géocodeur open source qui se nomme Addok. Cependant, le site est limité à une utilisation d'un fichier CSV de 6mo, ce qui ne permet pas d'effectuer un géocodage de masse sur un fichier de plusieurs milliers d'entités. C'est donc pour cette raison que geoloc_csv est né. En effet, cet outil (script) permet de passer au-delà de la limite imposé par le gouvernement. Comment est-ce possible ? Simplement en important la BAN(O) ou la BAN sur un serveur local. De cette manière, les contraintes de limitation imposées par la plupart des solutions web sont contournées. De plus, les requêtes sur les adresses sont locales et non distantes, ce qui permet

en théorie de gagner en performance sur les temps de traitement. L'outil se lance sur un terminal en se plaçant dans le dossier geoloccsv en l'appelant de la façon suivante :

L'option -h permet de lancer le programme avec l'aide. Il s'agit ensuite de lui fournir des paramètres, qui correspondent aux champs utilisés pour le géocodage. Néanmoins, il y a des inconvénients à cette méthode, le principal étant le poids de la BAN à importer sur le serveur local. Un 2em inconvénient d'un ordre plus juridique est l'utilisation que l'on peut faire ou non du produit sortant de geoloc_csv, d'où l'intérêt d'informer son utilisateur quant aux licences d'utilisation en question.

Par conséquent, nous avons (Thomas et moi-même) décidé d'implémenter au code un message à l'intention de l'utilisateur de geoloc_csv mentionnant l'l'utilisation de la BANO et la référence à sa licence d'utilisation (comme précisé sur l'article 4.3 de la licence).

Cet outil a été développé en interne par Mr Valorge Amaury. Son principe de fonctionnement est très semblable à celui de geoloc_csv, c'est aussi un script écrit en python et qui est basé sur le code de l'API du gouvernement. La différence de ce script est qu'il évolue dans l'environnement QGIS, c'est-à-dire qu'il se lance sur une console QGIS, à l'aide d'un plugin se nommant ScriptRunner, celui-ci permet d'exécuter un script externe dans QGIS.

Lors de mon entretient avec Amaury, j'ai appris qu'il n'avait pas pu tester sa solution et qu'elle risquait de ne pas être fonctionnelle. Effectivement lorsque j'ai tenté un test pour la première fois, cela n'a pas fonctionné. Ceci en raison de ma version de QGIS qui était antérieure à celle sur laquelle Amaury avait développé sa solution.

Je ne détaillerai pas plus cette solution étant donné que les mécanismes mis en jeu sont très sensiblement les mêmes que pour la solution précédente, à la différence de l'environnement d'exécution du programme.

Après avoir étudié et tester un certain nombre de solutions, il se trouve que nombre d'entre elles ne soient pas conçues pour le géocodage de masse, mais plus en tant que service ponctuel pour ses utilisateurs via un outil de type web service.

Pour les solutions qui supportent le géocodage de masse, elles sont pour la plupart limitées à un seuil d'utilisation (google maps, osm, API de l'IGN, etc...). Il m'a paru intéressant de me pencher sur une des solutions qui ont été développés au sein de l'entreprise.

D'une part car celle-ci répondrait plus efficacement aux besoins de la dite entreprise car elle a été conçu pour. D'autre part, ces solutions qui sont en réalité des scripts écrits en python permettent une liberté de manoeuvre en ce qui concerne leur customisation (optimisation du processus, ajouts de fonctionnalités...). Enfin, pour une raison plus personnelle, la possibilité d'une amélioration d'une des solutions internes me permettrait de me plonger dans le développement en python et ainsi améliorer mes compétences.

Par ailleurs, les résultats du géocodage obtenus avec ces solutions internes sont similaires à ceux obtenus via l'API du gouvernement, c'est en France ce que l'on peut obtenir de mieux en terme de précision (requête sur la BAN), avec les services de Google et OSM également.

Pour toutes ces raisons, j'ai choisi de me pencher sur une solution interne. Il fallait alors choisir une des deux solutions. J'ai donc opté pour la solution de Thomas, geoloc_csv. Premièrement, cette solution s'exécute sur terminal et ne nécessite aucun logiciel externe pour fonctionner, simplement les dépendances en termes de librairies pythons doivent être satisfaites, mais c'est aussi le cas pour l'autre solution interne. Deuxièmement, geoloc_csv était à quelques détails près fonctionnel avant même mon arrivée (Thomas avait dû développer la solution dans le cadre d'un projet plus large auparavant). Et pour finir, d'un point de vue plus pratique, Thomas était durant la période du début de mon stage plus disponible qu'Amaury, ce qui facilitait les entretiens pour les nombreuses questions que j'avais à propos du script.

Comme je l'ai précisé précédemment, la solution geoloc_csv s'exécute sur un terminal où un quelconque interpréteur python. A supposé que les dépendances envers les librairies soient satisfaites, il suffit de lancer le script avec un certains nombres de paramètres :

- Les champs utilisés pour le géocodage ? Correspondent aux champs Rue, Numéro, Ville et

- Le serveur sur lequel les requêtes vont être effectuées ? Serveur local ou distant

Il faut savoir que l'utilisation de l'outil nécessite un prétraitement des données en entrée afin que les champs utilisés soient conformes (split de l'adresse, utilisation de la casse majuscule, pas de bis, pas de numéro dans le champ ville...) et que le géocodage s'effectue dans les meilleures conditions.

Ceci constitue une première limite à cette solution, le prétraitement des données pouvant coûter à l'utilisateur un temps plus ou moins long selon la qualité des données en entré. Une deuxième limite, inhérente à la plupart des solutions de géocodage, est le fait que les adresses qui n'ont pas été géocodées ne sont pas directement récupérables dans un second fichier CSV qui contiendrait ces adresses. En effet, si tel était le cas, l'utilisateur aurait alors la possibilité de tenter un second géocodage de ces adresses à l'aide d'une nouvelle solution. Etant donné que la plupart des adresses du fichier original auront été géocodé, il est probable que le reste des adresses soit en nombre assez restreint pour passer la limitation imposée par les web services proposant un géocodage performant comme celui de Google.

A la fin du processus, plus ou moins long selon le nombre d'adresses à géocoder, nous récupérons un fichier CSV des adresses qui ont été géocodées avec des informations sur la qualité du géocodage. L'outil créer un champ result avec l'adresse géocodée, ainsi que le niveau de précision du géocodage (street, housenumbers...)

Pour la prochaine étape, mon but était donc d'améliorer le script pour lui ajouter les fonctionnalités qui comblerait ces limites au mieux où diminuerait leur impact au cas échéant.

Après avoir compris le fonctionnement du script, j'ai donc décidé d'apporter quelques changements au script de base, des changements qui permettront d'ajouter des fonctionnalités où bien de simplifier les prés traitements imposés à l'utilisateur.

J'ai premièrement pensé à ajouter au script un module de pré traitement des données afin que le géocodage s'effectue dans les conditions optimales quel que soit la qualité des données en entrée. Voici le tableau qui résume la forme que doit avoir la donnée en entrée avant d'être envoyée au serveur Addok pour que le géocodage s'effectue avec précision :

Figure 3: Tableau résumant la forme que doivent avoir les données en entrée

Or peu de données sont fournies dans ce format en respectant les règles citées sur le tableau. Je me suis donc basé sur ces règles pour créer une fonction qui va permettre au lancement du script d'effectuer automatiquement un « blanchissement » des données afin qu'elles correspondent au format attendu. Voici la fonction que j'ai créée, se nommant corrector :

Avec cette fonction, les données envoyées au serveur possèdent le format requis, à supposer bien sûr que les champs soient respectés (c'est-à-dire ne pas avoir l'adresse complète dans un seul champ par exemple). Pour les abréviations, j'ai utilisé un dictionnaire qui possède en clé les abréviations officielles, et en valeurs leur nom complets, pour effectuer le remplacement au cas où il y aurait une abréviation.

Secondairement, j'ai ajouté quelques lignes au code pour pouvoir récupérer les adresses qui n'ont pas été géocodées dans un fichier CSV. J'ai rendu cette fonctionnalité optionnelle et donc c'est à l'utilisateur d'utiliser le paramètre « shp_out » que j'ai créé pour utiliser cette fonction et récupérer les adresses dans un fichier dont il aura spécifié le nom.

Enfin, j'ai créé une fonction qui va permettre à l'utilisateur, toujours à travers un paramètre lors de l'appel de la fonction, de créer directement une sortie sous format shapefile du fichier CSV des adresses géocodées. Pour cette fonction, j'ai utilisé les modules de Fiona, Shapely et Geopandas pour créer à partir des coordonnées les points qui correspondent et construire le shapefile.

Bien que les améliorations apportées au script lui ajoutent une plus-value, je suis conscient qu'il existe des failles et qu'il demeure en l'état optimisable. Par exemple, la création de la fonction qui permet d'effectuer un pré traitement des données est utile, cependant elle ne permet pas non plus de formater automatiquement l'adresse dans les champs correspondant au cas où celle-ci n'est pas conforme.

Par ailleurs, la fonction de création du shapefile est efficace pour un échantillon d'adresses traitées qui ne dépasse pas les 10 000 adresses. Au-delà, le temps de traitement évolue exponentiellement et donc le traitement peut devenir beaucoup plus important. Hors avec FME, il est possible de vectorisé les points à partir de leurs coordonnées très rapidement même sur des fichiers de grande ampleur. Ma solution de vectorisation est donc adaptée et permet un gain de temps sur des fichiers d'adresses moyennement important (de 1 à 15000 adresses). Cela reste tout de même une option donc ce n'est pas fondamental pour le fonctionnement du script.

Nous pouvons traduire le terme « Snapping » par « Capture » en français. Le Snapping en terme SIG peut être considéré comme une opération où géotraitement qui va permettre d'affecter des informations d'un point A à un point B selon certains paramètres. Il existe une multitude de solutions de Snapping différentes, cependant la plus commune est celle du Snapping au voisin le plus proche. Voici un figuré pour comprendre les processus mis en jeu lors d'une opération de Snapping :

Sur la figure 7, c'est une opération de type géométrique. En effet, le Snapping du point de fin de ligne à une autre peut permettre de résoudre certaines erreurs topologiques, notamment pour les réseaux. L'opération fonctionne de telle sorte que le point final sur la ligne candidate va se snappé sur le point final de la ligne cible le plus proche.

On peut également ne pas modifier les géométries mais se servir des méthodes de Snapping pour attribuer les informations d'un figuré géométrique à un autre, ce qui peut être très pratique dans de nombreux cas.

L'opération de géocodage permet de récupérer des points qui ont des coordonnées et un certain nombre d'informations. Dans le cadre de mon stage, j'ai travaillé avec le répertoire national SIRENE, qui recense l'ensemble des entreprises en activité sur le territoire. Comme dit précédemment, j'ai travaillé sur le data-set « Usage des bâtiments », donc à l'échelle du bâtiment. Concrètement, la nécessité est de rattacher l'information qui est associée à un point qui a été géocodé, au bâtiment qui lui correspond. Et c'est là qu'intervient donc le Snapping, ou plus précisément les différentes techniques de snapping des informations aux bâtiments. Lors de mon arrivée, la seule et unique manière de snappé les informations provenant du fichier SIRENE aux bâtiments pour compléter le data set usage des bâtiments est la technique dite du « Voisin le plus proche ». J'en ai déjà évoqué le principe (cf. figure 6), c'est-à-dire que dans le cas de ForCity, les informations étaient snappés au bâtiment le plus proche. Or dans de nombreuses situations, le snapping au voisin le plus proche n'est pas la solution la plus adaptée.

En effet, selon le secteur d'activité de l'entreprise où de l'établissement d'activités, il se peut que plusieurs bâtiments ne soient pas pris en compte par le snapping, c'est le cas lorsque l'entreprise est diffusée sur plusieurs bâtiments mitoyens, et non comprise dans un seul. Il faut donc considérer la nature du secteur d'activité, et étudier en détail la structure de la donnée en entré pour obtenir un maximum d'informations sur le ou l'ensemble de(s) bâtiment(s) à snappé(s). Il existe aussi d'autres problèmes liés à la donnée d'entré, par exemple pour le cas du Fichier SIRENE certains établissement administratifs ont leurs effectifs regroupés au niveau du siège principal, ce qui provoque une surpopulation salariale au niveau du siège et un désert au niveau des autres établissements (ex : les services de police, gendarmerie, mairie).

Le besoin et ma mission sont ici de faire en sorte d'améliorer les workflows visant à attribuer des usages aux bâtiments. Pour cela, il fallait tout d'abord que je comprenne le processus général de mise en place du data-set sur l'usage des bâtiments. C'est donc avec ma tutrice Emilie que j'ai tout d'abord plongé dans les workflows afin d'en comprendre le fonctionnement général (cf. l'introduction sur l'usage des bâtiments). Mon travail en ce qui concerne le snapping des informations sur le data-set usage des bâtiments concerne particulièrement les catégories d'usages « Commerce », « Industrie ». L'ordre dans lequel sont traités les différents secteurs d'activités est le suivant :

Afin d'améliorer les processus de Snapping sur les workflows, Emilie m'a attribuer une zone de test adaptée aux deux secteurs d'activités. J'ai tout d'abord travaillé sur le 7em arrondissement de Lyon au niveau de Gerland, et sur les docks de Vaulx-en-Velin, ceci pour le secteur industriel.

J'ai travaillé sur la zone sud du quartier de Gerland car c'est un territoire qui abrite sur Lyon un bon nombre d'entreprises dont le secteur d'activité est l'industrie.

J'ai également travaillé sur la commune de Vaulx-en-Velin, là où se concentrent nombre d'activités industrielles et artisanales (cf. figure 8 dans l'annexe).

Pour les activés commerciales, nous avons choisis une zone comportant un grand centre commerciale au niveau de la porte des alpes (cf. figure 9 dans l'annexe).

Ainsi qu'une zone en plein centre-ville composée de divers commerces de proximité au niveau de la place Bellecour (cf. figure 10 dans l'annexe).

Le premier secteur d'activité sur lequel j'ai travaillé est le commerce. Pour cela, nous avons choisis deux zones sur Lyon qui représentent des activités de commerce différentes (proximité et centre commerciaux, cf. la partie Zone d'étude). Je vais dans cette partie montrer un certain nombre de cartes qui sont le résultat d'un Snapping avec différents paramètres. Pour chacune, je préciserai les observations que j'ai pu avoir et les piste possibles qui en résultent pour améliorer les résultats de l'opération de Snapping. Ainsi, je détail la méthodologie mise en place pour arriver à mes résultats.

- ? Il semble que le snapping au bâtiment fonctionne correctement sur les centres commerciaux et commerces possédant une grande surface.

- ? Cependant on remarque au Nord-Ouest que des logements ont été snappés, ceci dû à la présence de petits commerces.

- Implémenter une contrainte d'exclusion des entrepreneurs individuels pour limiter le

Après examen des champs de la donnée SIRENE en entrée, j'ai remarqué l'existence d'un champ nommé NATETAB. C'est la nature de l'activité exercée par l'entrepreneur individuel (artisanale, commerciale, libérale etc). De telle façon, j'ai pensé pouvoir filtrer tous les entrepreneurs individuels en partant du principe que ceux-ci exercent à leur domicile. Se référé à la figure 12 de l'annexe pour visualisé le résultat du snapping.

- ? Il reste néanmoins une importante part de logements qui sont snappés. Piste possible :

- Implémenter une contrainte d'exclusion par rapport à l'effectif des salariés.

La contrainte d'exclusion des entrepreneurs individuels ne suffisant pas à éviter le snapping sur certains logements, j'ai utilisé un autre champ de fichier SIRENE qui contient l'effectif salarial par tranche afin de limiter le snapping sur résidences.

Figure 8: Snapping au bâtiment avec contraintes sur entrepreneurs individuels et effectifs

- ? La contrainte sur l'effectif couplée à celle sur le champ natetab permet de ne pas snapper les bâtiments de logement qui possède des petits commerces du type commerce de proximité

Le bâtiment snappé correspond à un logement, tandis que la zone (défini par le cercle bleu sur l'image)
qui correspond au point SIRENE est un centre commercial inclus dans le bâtiment de logements. Il

semble donc, en ce qui concerne les grands centres commerciaux, que le snapping au bâtiment soit la méthode la plus adaptée.

Sur la zone du centre-ville de Lyon, nous sommes en présence de nombreux logements et commerce de proximités, ce qui est différent de la zone de commerce de la porte des Alpes qui regroupe principalement des grands centres commerciaux. Se référé à la figure 15 de l'annexe pour observer le résultat du snapping au bâtiment au niveau de la place Bellecour.

- ? Sur la zone du centre-ville, il semble que le paramétrage de contrainte sur l'effectif et sur

le champ NATETAB n'est pas suffisant, beaucoup de bâtiments de logement sont snappés.

- Séparation des commerces de grande surface et des commerces de proximité pour les traiter différemment dans la chaîne du workflow.

- ? Sur la zone du centre-ville où le bâti est dense et les activités multiples, le snapping en

différenciant les deux catégories de commerces pose problème car les deux catégories sont présentes dans des bâtiments qui comportent des logements.

- ? Etant donné la présence de la catégorie d'usage « Bâtiments à grande surface commerciale », il semble difficile d'effectuer une catégorisation pré-snapping.

- Snapping au bâtiment pour tous les commerces, et recoupage avec la surface activité de la BD TOPO pour savoir si le bâti peut ou non, recevoir de l'habitat.

Pour conclure sur l'activité commerciale, l'existence des commerces de proximités et boutiques rend le snapping difficile étant donné qu'il ne faut pas snapper d'activité sur des bâtiments résidentiels. La méthode de snapping au bâtiment fonctionne bien sur les grands centres commerciaux mais moins lorsqu'il y a présence de commerce de proximité.

Une des pistes envisagées est d'utiliser les zones d'activité spécifiée par la BD TOPO en tant que filtre. Ainsi, tout bâtiment snappé dans la zone peut être candidat au snapping.

Pour les activités industrielles, j'ai repris la même méthodologie que précédemment pour le commerce, en partant de la méthode de snapping actuelle (utilisée) et en tentant d'en améliorer le résultat au fur et à mesure. Je montrerais les résultats obtenus sur la zone de Vaulx-en-Velin, ceux obtenus sur la zone du Gerland sont disponibles en annexes.

Je vais dans cette partie décrire les grandes étapes de mon raisonnement et les résultats obtenus. Je laisserai volontairement les cartes dans cette partie et non en annexes, pour la raison qu'elles permettent de bien comprendre les étapes du raisonnement, et ainsi la méthodologie employée. Pour commencer, je suis donc parti sur le méthode de snapping simple au bâtiment le plus proche qui était la méthode employée.

-? Des bâtiments qui correspondent à des logements ont été snappé, notamment à l'Ouest au niveau de l'école.

- ? Snapping de surface triangulaire due à la BD TOPO (la géométrie des bâtiments sur la BD TOPO).

Par la suite, j'ai décidé d'inclure une contrainte sur la surface des bâtiments pris en compte pour le snapping. Ceci afin d'éviter de snappé des bâtiments résidentiels avec peu de surface.

Figure 12: Snapping aux bâtiments avec exclusion de surface sur Vaulx-en-Velin

- ? Il semble que la contrainte d'exclusion de surface permet d'éviter de snapper des bâtiments qui ne peuvent être des bâtiments industriels.

- ? Cependant, on remarque que des bâtiments non industriels continuent d'être snappés, c'est toujours le cas de l'école.

La prochaine étape consiste en l'exclusion des entrepreneurs individuels exerçant à domicile via le champ NATETAB, comme je l'avais fait précédemment pour les activités commerciales.

Figure 13: Snapping aux bâtiments avec contrainte sur entrepreneurs individuels et surface sur Vaulx-en-Velin

- ? Exclue les activités avec des entrepreneurs individuels au statut d'artisan.

Le résultat est plus satisfaisant que sans la contrainte sur les entrepreneurs individuels. Cependant, certains bâtiments ont été snappés deux fois pour deux points différents. De plus, certaines entreprises sont contenues dans plus d'un bâtiment, pour celles-ci cette méthode de snapping ne fonctionne pas. J'ai donc changé l'échelle de snapping pour qu'elle corresponde à la parcelle et non au bâtiment, ceci afin de récupérer les informations sur l'ensemble des bâtiments de l'entreprise.

- ? Il semble que des bâtiments industriels sont oubliés lorsque snappés à la parcelle.

J'inclus alors une contrainte sur les entrepreneurs individuels, avec une méthode de snapping à la parcelle.

Si l'on compare les méthodes de snapping sur parcelles et sur bâtiments avec le paramètre d'exclusion NATAB sur les artisans, on peut observer :

- Le snapping sur parcelles inclus plus d'entité que celui sur bâtiments (avec les mêmes

- Cependant, le snapping sur bâtiments inclut certains bâtis industriels que celui sur parcelle
n'incluait pas.

Avec ces observations, ma réflexion fut la suivante. Il semble que chacune des deux méthodes de snapping possède des avantages et des inconvénients. Le snapping au bâtiment est moins complet que celui à la parcelle cependant il inclut certain bâtiments non pris en compte par ce dernier. Le snapping à la parcelle semble plus précis que celui au bâtiment mais n'inclus pas certaines entreprises. J'ai donc pensé à combiner les deux méthodes de snapping pour obtenir un meilleur résultat.

- Si le bâtiment snappé se trouve dans la parcelle, alors on snap tous les bâtiments au niveau de cette parcelle.

- Si le bâtiment snappé se trouve en dehors de la parcelle, alors on snap au bâtiment le plus proche sans garder ceux présents dans la parcelle.

- ? Cette méthode combine les bénéfices du snapping au niveau du bâtiment ainsi que ceux au niveau de la parcelle.

- ? Cette méthode permet de snapper le bon bâtiment même si le point SIRENE n'est pas dans la bonne parcelle.

- ? Il reste cependant un problème, si le bâtiment industriel à snappé est trop petit, cette méthode trouvera un bâtiment plus important en surface (possibilité que ce soit un logement...)

On pourrait alors changer le seuil d'exclusion des bâtis industriels, cependant le gain en précision serait probablement plus faible que la perte en terme de bâtiments non snappés.

Les changements consécutifs que j'ai opéré sur les modules des workflows concernant l'industrie et le commerce, suivant la méthodologie définie dans la partie précédente, a permis d'affiné les résultats que l'on obtenait précédemment (obtenus avec le snapping simple au bâtiment). Dorénavant, l'attribution de l'information au bâtiment prend en compte l'échelle du bâtiment, mais aussi la zone d'activité (en ce qui concerne le commerce) ainsi que la parcelle (échelle administrative). Ces prises en compte des différentes échelles selon un cheminement de conditions de type « SI-SINON » permet d'obtenir un snapping « intelligent » des informations au bâtiment. Ce qui se traduit par la diminution du nombre de bâtiments résidentiels snappés, et cela permet aussi de snappé des ensembles de bâtiments qui correspondent à un seul point SIRENE (au lieu de ne snappé qu'un seul bâtiment). J'ai dû expérimenter plusieurs méthodes et en observer les résultats sur cartes pour suivre des pistes d'améliorations et obtenir un résultat plus précis que celui obtenu initialement.

Comme je l'ai précisé, j'ai principalement travaillé sur les modules industrie et commerce du workflow building_usage. Il faut savoir que chaque module du workflow implique une réflexion en amont quant au snapping de l'information au bâtiment. Par exemple, les bâtiments de santé publique occupent des surfaces importantes et les activités sont réparties au sein de nombreux bâtiments. Ce qui nécessite de réfléchir en amont aux surfaces que l'on va snappé ; bâtiment, parcelle, zone d'activité ... ? D'autres difficultés peuvent provenir de la source de donnée en entrée, comme par exemple le fait que l'effectif salariale pour les administrations soit regroupé au niveau du siège social. Il faut donc pouvoir jouer avec ces différentes échelles et les inexactitudes inhérentes aux données en entrée afin d'obtenir un résultat raisonnablement correct, c'est-à-dire correspondant au besoin de l'entreprise. En effet, les workflows construisant le data-set usage des bâtiments ne vise pas la perfection comme ma tutrice me l'a précisé en me le présentant (hors de portée via les processus usités actuellement), mais vise plutôt à consolider les données sur les usages au niveau du bâtiment afin qu'il soit correctement utilisés à l'étape prochaine par les modèles tels que SPOC.

Après consolidation des workflows sur l'usage, nous nous retrouvons avec une table renseignant de nombreuses informations sur les bâtiments, dont la surface de plancher et la surface d'usage par catégories d'activités. Des problèmes surviennent alors, en cause les techniques de snapping, les données en entrée et l'interprétation par le modèle SPOC. Un des problèmes sur lequel j'ai dû m'attarder étant celui-ci : une surface de plancher du bâtiment inférieure à l'ensemble des surfaces des usages qui le constitue. Pour pallier à ce problème, il y a nécessité de ventiler la surface en trop plein.

En sortie du workflow, plusieurs incohérences sont détectées. Les limites se trouvent à différents niveaux :

La principale donnée utilisée pour définir les usages des bâtiments, et surtout les effectifs et les surfaces utilisées pour ces usages, est le fichier SIRENE. Le calcul des surfaces pour chaque activité repose sur les données d'effectifs renseignées dans le fichier SIRENE. Or ces données sont déclarées à la création de l'entreprise et ne sont pas toujours remise à jour, elles sont donc peu précises.

D'autre part, certains sites d'une entreprise peuvent regrouper les effectifs de plusieurs établissements situés sur d'autres sites. On peut donc trouver des effectifs disproportionnés attachés à certains établissements. C'est le cas de certaines administrations publiques, certains équipements de type scolaire notamment. L'étude rapide de la relations entre les établissements présentant le même numéro SIRET n'a pas permis de mettre en lumière ces cas de figures. Elles nécessitent une étude plus approfondie.

Le calcul des surfaces salariales à partir des moyennes sur le fichier SIRENE engendre une fourchette d'incertitude en plus, ainsi que celui des surface de planchers par bâtiments.

C'est la partie sur laquelle j'ai travaillé, c'est-à-dire les limites induites par le Snapping. En sortie du workflow sur l'usage des bâtiments, qui traite l'ensemble des activités à des échelles de précision différentes (plusieurs niveaux de précision allant de n1 le moins précis à n4 le plus précis), nous obtenons une table avec l'ensemble des bâtiments de la zone étudiée selon une classification propre à ForCity. Ces bâtiments ont un certains nombres d'informations renseignées, parmi celles-ci, la surface salariale octroyée par activités pour chaque bâtiments, ainsi que la surface totale du bâtiment. Par exemple, un bâtiment peut posséder une surface totale de 250m² avec pour usage numéro 1 une activité de type commerciale qui occupe 150m² de surface, et une activité de type bureau qui occupe 50m² de surface. Il reste donc 50m² de surface libre, lorsque l'on envoie ces données à SPOC, celui-ci déterminerait en théorie qu'il pourrait y avoir potentiellement dans ce bâtiment 50m² de surface résidentielle. Hors les traitements peuvent induire des erreurs de type surface d'usage totale plus élevée que la surface du bâtiment pour certains bâtiments. Pour pallier à ce problème, une solution est adoptée au coeur de l'entreprise, nommée ventilation. Cependant, à l'heure actuelle, aucune solution de ventilation n'a été mise en place en ce qui concerne l'usage des bâtiments. Ce qui fausse

les résultats obtenus post SPOC. Ma mission était donc de créer une solution permettant de ventiler ces surfaces salariale en surplus.

Le principe de la ventilation est plutôt simple, il consiste à ventiler la surface d'usage en trop plein aux bâtiments adjacents qui ont de la surface libre. Ce processus permet d'éviter l'obtention de bâtiments en surplus de surface d'usages, et ainsi d'éviter par la même occasion les erreurs retournées par SPOC. Ces erreurs concernent la répartition des ménages sur les bâtiments possédant une surface libre.

Evidemment, on peut d'ores et déjà émettre une critique quant à la pertinence du processus de ventilation. En effet, comme je l'ai dit précédemment ce processus va permettre de ventiler la surface en surplus aux bâtiments adjacents qui possèdent de la surface libre. Par conséquent, on se retrouve alors avec des résultats qui peuvent être faussés par la ventilation. Si l'on prend par exemple un bâtiment possédant 200m² de surface totale, et 300m² de surface d'usage. Après l'opération, 100m² de surface vont être ventilés sur les bâtiments adjacents qui ont de la surface libre. Donc en théorie, certains bâtiments vont se retrouver avec une surface salariale qu'ils ne devraient pas avoir. J'expliquerai dans la partie suivante tous les mécanismes qui doivent être mis en jeu pour effectuer l'opération de ventilation en limitant au maximum le remplissage de bâti non concernés.

J'ai eu avant de me lancer sur cette tâche une discussion avec Emilie, qui m'a informé que la ventilation est un procédé utilisé au sein de l'entreprise comme solution « par défaut », c'est-à-dire qu'elle induit irrémédiablement un certain taux d'erreurs. Cependant, ces erreurs ont une incidence négative moins importante que les erreurs post SPOC retournées sans utilisation de ce procédé. C'est donc une question de limitation et contournement du problème plus qu'une résolution du problème en elle-même. Cette méthode intervient dans la volonté de consolidation du data-set Building_Use.

Après l'affinage des techniques de snapping, il me fallait donc trouver un moyen de ventiler les surfaces salariale en surplus des bâtiments afin d'envoyer à SPOC des données conformes. Il faut savoir qu'au cours de mes avancées, il y a eu quelques complications et autres changements de directions qui ont changé les buts premiers de ma mission. J'expliquerai au mieux le cheminement de ma réflexion propre ainsi que les attentes de ma tutrice au cours de la période sur laquelle j'ai travaillé sur cette mission.

Comme je l'ai dit précédemment, le but de la solution était de ventiler les surfaces d'usages en surplus. Pour cela, je devais respecter un certains nombres d'indications et de contraintes :

Je devais au préalable effectuer une jointure entre la table comportant un certain nombre d'informations par bâtiment mais surtout les surfaces d'usage par bâtiment et leur surface de plancher, avec le shapefile comprenant la base bâti. Ces tables étant des paramètres variables, c'est donc une première contrainte en ce qui concerne le choix technologique de la solution. Au final, j'obtiens une table avec chaque usage par bâtiment. La majorité des bâtiments ne possèdent qu'un usage, cependant certains possèdent plusieurs usages, ce qui fait que la table ne contient pas d'identifiant de bâtiment unique.

Après réflexion et réunion avec ma tutrice, nous nous somme dis qu'il serait judicieux voir indispensable d'implémenter à la solution un paramètre de distance. C'est-à-dire que la ventilation opérerait successivement du bâtiment le plus proche à celui qu'il faut ventiler, au plus lointain. Ce qui évitera de ventiler des surfaces d'usages sur des bâtiments qui ne serait pas voisins.

Il ne faut ventiler la surface salariale en surplus que sur les bâtiments possédant de la surface libre et non sur les autres.

Il faut savoir que l'on travaille sur des zones de grande surfaces (ex : la métropole de lyon, les départements de l'île de France, une commune..), ce qui peut porter le nombre d'entités à analysés à plusieurs milliers. Hors, la solution devant intervenir entre la fin du workflow sur les usages et la passe des données à SPOC, on ne peut se permettre des temps de traitements trop long.

Il m'a été donné comme consigne de développer une solution en python, en raison des multiples possibilités offertes par ce langage, du caractère polymorphique qu'il propose, mais aussi de la disponibilité de l'aide que l'on pourrait m'apporter si je développais la solution avec ce langage.

A ce stade, il me fallait choisir une technologie où un environnement de développement. J'ai alors eu une réunion pré développement avec Amaury, un géomaticien développeur s'occupant entre autre du déploiement des indicateurs dans les plateformes ForCity. Ceci afin de choisir l'environnement de développement le plus adapté vis-à-vis du but de la mission et des contraintes, mais aussi d'établir une stratégie de développement à l'aide d'un diagramme Yed, disponible via un lien annexe. Amaury m'a alors suggérer de développer le script sur un environnement QGIS. Pour raison principale, le fait que QGIS offre via son application pyQGIS de nombreux outils qui permettent d'effectuer des traitements géographiques sur les couches importées directement sur l'interface QGIS. Cela permet de satisfaire la contrainte sur la distance, et d'effectuer divers géotraitements sur les données en entrée si le besoin apparaît. Qgis offre de nombreuses possibilités via pyQGIS pour traiter la donnée géographique. En effet, l'interface graphique du logiciel est limitée dans son utilisation à un certains nombres de possibilités. L'interface de développement sous la console QGIS permet à son utilisateur de créer une chaine de traitements/géotraitements sur la donnée importée selon ses besoins, et offre donc plus de

liberté, ceci à condition de pouvoir prendre en main l'outil de développement, ce qui n'est pas forcément aisé... En effet, le développement sous pyQGIS est une tâche laborieuse, principalement en raison du manque de documentation sur les fonctions qui y sont disponibles. Cependant, Amaury m'a dirigé vers cette solution car il était en capacité de m'aider, ayant déjà développé sur cet environnement. J'ai également utilisé une extension de QGIS nommée Script Runner qui permet d'exécuter un script externe sur l'appli QGIS, ce qui octroie un confort non négligeable pour le scripting étant donné le caractère quelque peu trivial de la console python de QGIS.

Pour une raison que je détaillerai dans la partie suivante qui correspond aux étapes et à la méthodologie, j'ai dû utiliser d'autres outils et sortir de l'environnement QGIS. En le faisant, j'ai dû utiliser des librairies qui permettent le traitement spatial de données sous python. Je me suis dirigé vers la librairie Geopandas, une extension de la librairie pandas qui permet de travailler sur des données géographiques. Cette solution m'a paru la plus adaptée étant donné que j'avais eu l'occasion lors de l'amélioration du script de géocodage de m'entraîner sur la libraire Panda, parente de Geopandas. Cette librairie fonctionne de la même manière que Pandas à la différence que l'on manie des géodataframes à la place de dataframes, et donc permet les traitements géographiques. J'ai également utilisé un outil nommé psycopg2, celui-ci permet de faire la liaison entre une base de données PgSQL et un script python. On se connecte à la base de donnée via le script et on peut alors récupérer les tables qui nous intéressent, les transformer en géodataframes où dataframes pour lancer la série de traitements souhaités.

Dans cette partie, je vais définir les étapes de développement de mon script final que j'ai développé hors de l'environnement QGIS. Lors de mon premier essai sous QGIS, j'ai finalement réussi à atteindre le résultat escompté, cependant le temps de traitement était beaucoup trop important (de l'ordre de 44h pour traiter 250 000 entités). Je vais donc détailler les étapes de mon script python développé avec les librairies pandas et geopandas. Je dois cependant insister sur le fait que mon premier script sous pyqgis m'a permis de consolidé mon raisonnement et de me familiariser avec les outils de géotraitements sous python, ce qui a largement facilité mon 2em essai en « sortant » le script de l'environnement QGIS (se reporter au diagramme disponible en annexe pour visualisé le fonctionnement général du script pour une meilleur compréhension). Voici les étapes principales :

Création de la boucle qui va permettre de parcourir la liste de bâtiments à ventilé.

Une fonction qui va permettre de ventiler la surface du bâtiment analysé sur les bâtiments adjacents en partant du plus proche au plus lointain jusqu'à ce qu'il ne reste plus de surface à ventilé. Techniquement, ce fut l'étape la plus compliquée à mettre en oeuvre.

Lors de ces diverses étapes, j'ai rencontré de nombreuses difficultés de toute sorte. Je vais simplement résumer dans cette partie les principales, et les solutions que j'ai apportées. Une des première grande difficultés à surmonté fut le temps de traitements sur ma première version du script sur l'environnement QGIS. Après discussion avec certains développeurs de l'entreprise, j'ai pris la décision de réadapter le script dans une version plus générique, pour gagner en performance et en versatilité. La réadaptation fut relativement aisé (vraiment relativement...), cependant j'ai eu du mal à transformer la fonction de ventilation de la première version de mon script à la version finale. L'adaptation n'était pas intuitive étant donné que les outils de pyQGIS n'étaient pas superposables, je m'efforçai à traduire ma fonction d'un script à l'autre alors qu'il fallait simplement repenser la fonction pour l'adapter aux nouvelles librairies. Au final, la fonction était plus simple et compréhensible, mais aussi plus efficace en terme de performance. J'ai réussi à atteindre un temps de traitements de 2h pour le même nombre d'entités (au lieu de 44 heures), ce qui est beaucoup mieux mais toujours insuffisant. Pour atteindre un temps raisonnable, j'ai finalement eu recours à la création d'index spatial sur la couche de bâtiments au préalable (avant le passage dans la boucle), ainsi le calcul des distances entre ceux-ci est beaucoup plus rapide étant donné que le script ne prend pas en compte la géométrie pour le calcul mais l'index du bâtiment. Il faut savoir qu'avec une telle méthode, le calcul des distances est approximatif, dans le sens où l'index spatial va créer une bounding box autour du bâtiment. Cependant, je n'avais aucunement besoin d'un grand degré de précision dans le calcul des distances donc ce fut un choix pertinent.

Au cours du développement de ma solution, j'ai dû faire face à quelques difficultés. Cependant, j'ai au final aboutit à un résultat, se matérialisant par un script en python utilisant un certain nombre de librairies. J'ai testé la solution sur un échantillon de la couche bâti du département 93, puis sur l'ensemble du département. Le script est fonctionnel et permet la ventilation de la surface salariale en trop plein sur les bâtiments adjacents. J'ai réussi grâce à cette solution à atteindre un temps de traitements de 30 minutes, écriture des nouvelles valeurs de surfaces dans la table comprise dans le temps (en effet, après toutes ces étapes, il faut écrire les nouvelles valeurs dans la couche, ce qui allonge le temps de traitement).

Bien que je sois arrivé au résultat final escompté, il existe quelques limites à ma solution qui reste en soit quelque peu triviale. En effet, mon script permet de ventiler la surface salariale en surplus des bâtiments, cela en utilisant le champ free_surf que j'ai créé au préalable (cf. partie C). Cependant, lorsque la surface salariale est ventilée aux bâtiments adjacents qui ont de la surface totale libre, mon script ne prend pas en compte la surface d'usage attribuée par type d'activité. C'est-à-dire que la surface qui va être ventilée correspond à un usage spécifique, hors l'information n'apparait pas sur le bâtiment qui aura reçu cette surface. En pratique, il m'aurait fallu ajouter une fonction à mon script qui permette pour chaque usage qui est ventilé sur un bâtiment de créer un nouvel usage sur ce bâtiment comprenant la surface ainsi ventilée, et donc d'ajouter une entité à la table finale, ce qui aurait complexifié ma tâche sur l'aspect technique. La raison pour laquelle je ne suis pas allé jusqu'à ce niveau de détail technique est purement logistique.

En effet, peu avant que j'aboutisse à mon script final, j'ai eu une réunion avec ma tutrice Emilie ainsi que Amaury pour discuter du script de ventilation. Après discussion, nous en sommes arrivés à la conclusion qu'il n'était pas forcément utile de développer le script outre mesure, et y inclure la prise en compte des usages pourrait être le sujet d'une prochaine amélioration. Cependant, en l'état actuel des choses, il n'était pas pertinent selon Emilie de retravailler le script afin qu'il intègre toutes les contraintes induites par le workflow générale. Celui-ci était encore en phase de pleine transformation, et donc susceptible de changer. D'autant plus que l'on ne savait à cette heure encore où intégrer mon script, ni comment. Où, dans le sens suivant : à quel moment du workflows faire tourner mon script ? Une option était de l'intégrer entre chaque module du workflow sur les usages (industrie, transport, etc...) plutôt qu'à la fin du workflow général. Ainsi, nous éviterions de mélanger tous les usages cependant le temps de traitement serait plus conséquent. D'autre part, comme je l'ai précisé en partie d'introduction au data-set sur l'usage des bâtiments, le workflow building_use est construit sur FME. Ce qui implique qu'il faudrait intégrer également mon script à FME afin qu'il puisse être exécuté dans le workflow. Hors intégrer un script python utilisant des librairies externes au sein de FME ne semble pas tâche aisée. Il existe cependant des pistes qui peuvent être suivies, comme l'utilisation du transformer « python caller » sur FME ou l'utilisation des environnements de travail, qui permettent d'exécuter à la chaine des modules différents, et possiblement des modules externe à FME. Je n'ai cependant pas creusé plus en profondeur la question, car j'ai été dépêché sur une autre mission plus urgente pour les besoins de l'entreprise.

Pour finir, il me semble avoir atteint un temps de traitement convenable à l'aide la création de l'index spatial. Cependant il est possible que celui-ci puisse être encore réduit légèrement en revoyant la structure de mon code, et particulièrement la fonction qui permet la ventilation qui pourrait probablement être plus optimisée.

Pour une entreprise qui vise à modélisé la ville de demain, il est nécessaire de prendre en compte de multiples paramètres. En l'occurrence, ces paramètres se matérialisent principalement par la donnée numérique géographique. La donnée brut peut être récupérée de différentes manières, mais nécessite obligatoirement un traitement afin de pouvoir être utilisée. La totalité de mon stage a été dédié au traitement de la donnée, un domaine vaste que l'on peut subdiviser en de multiples catégories, dont certaines ont été l'objet de ma mission.

J'ai travaillé particulièrement sur le géocodage des données provenant de sources telles que le répertoire SIRENE ou encore le RES (Répertoire des Equipements Sportifs), ainsi que sur les différents procédés menant à un snapping intelligents de ces points aux bâtiments. La solution développée par Thomas sur laquelle j'ai apporté mes améliorations permettra à ses utilisateurs (celle-ci est principalement destinée aux membres de l'équipe Geodata) de pouvoir géocodé des adresses en masse plus aisément et d'une façon plus coordonnée au sein de l'équipe. En effet, les besoins en terme de géocodage de l'entreprise sont ponctuels mais néanmoins réguliers, et une solution unique au sein de l'équipe permet d'évité certains problèmes. En ce qui concerne le snapping, nous avons pu améliorer les workflows initiaux sur lesquels j'ai travaillé via une méthodologie qu'il faut adapter à chaque secteur d'activité.

Le script de ventilation que j'ai conçu reste pour le moment au stade de « prototype », car il n'a pas été instancié dans le workflow final sur les usages des bâtiments. Ceci notamment dû au fait que l'ensemble des workflows sont en chantier dû aux nouveaux projets à la charge de ForCity, ainsi qu'à la difficulté d'intégration d'un script externe sous FME. Cependant, celui-ci pose les bases immuables du concept de la ventilation adapté aux besoins de l'entreprise, et pourra donc à terme être amélioré et incorporé au workflow.

Pour conclure, mes différentes réalisations au sein de l'entreprise ont été source de défis intellectuels, particulièrement celles qui concernent le développement informatique. J'ai dû avoir recours à la réflexion, la recherche et parfois une certaine dose d'ingéniosité pour arriver à mes fins et ainsi satisfaire les besoins des missions sur lesquelles j'ai été affecté. A travers cette expérience, j'ai pu découvrir le monde professionnel de l'intérieur, et cela en tant que géomaticien. J'ai également augmenté mes compétences en logiciels SIG (notamment FME que je ne connaissais pas) et en gestion de base de données. Néanmoins, ce sont surtout mes compétences en développement qui ont été largement accrues lors de mon expérience, et qui je l'espère me permettront de commencé ma carrière professionnelle en tant que géomaticien au profil développeur.

Automatisation et optimisation de chaà®nes de traitements visant à consolider l'attribution d'informations géographiques aux bà¢timents

1.3 Le data-set « usage des bâtiments »