des données 3d pour les architectes, urbanistes et...

Institut National des Sciences Appliquées de Strasbourg

Mémoire de soutenance de Diplôme d’Ingénieur INSA Spécialité TOPOGRAPHIE

Des données 3D pour les architectes, urbanistes et paysagistes

Présenté en Septembre 2011 par Cédric MINERY Réalisé au : Service de la Mensuration Officielle (SEMO)

Quai du Rhône 12 1205 Genève

Directeur de PFE : Correcteurs :

M. Laurent NIGGELER M. Emmanuel ALBY Directeur SEMO M. Mathieu KOEHL

Cédric MINERY Septembre 2011 Des données 3D pour les architectes, urbanistes et paysagistes

REMERCIEMENTS

Je tiens à remercier toutes les personnes sans qui ce projet

n’aurait pas pu avoir lieu :

M. Laurent NIGGELER, mon directeur de PFE, pour m’avoir

fait confiance et m’avoir accueilli au SEMO pour ce projet. J’en

profite pour remercier l’ensemble des personnes du Service pour

leur accueil, et tout particulièrement Henrich DURIAUX pour ses

conseils et sa bonne humeur, Pepito LOPEZ pour son enthousiasme

vis-à-vis de mon travail ainsi que Geoffrey CORNETTE (promotion

INSA topographie 2010) pour son accompagnement tout au long

du projet.

Tous les membres de l’équipe de travail, architectes,

urbanistes, paysagistes et qui m’ont tout d’abord accueilli sur leurs

lieux de travail respectifs, avant de s’impliquer dans le projet et de

participer aux réunions de suivi. Sacha KORTUS, pour sa

motivation et ses tests, M. Christian HALLER et M. Thierry

SANGOUARD pour leurs aides et leurs conseils. M. Gérard-André

KOHLER, Rachel et Guillaume (promotion INSA topographie 2006)

pour leurs investissements et tests de données qu’ils ont réalisé.

Mme Myriam PIGUET pour son intérêt dans mon projet et sa

motivation.

M. Claude VUATTOUX, développeur du logiciel RhinoTerrain

pour sa disponibilité et son enthousiasme pour le projet, ainsi que

pour tous les rendus qu’il a réalisés.

Je remercie également toutes les personnes ayant

participé de près ou de loin à ce projet et que j’aurais oublié.

Et toutes les personnes qui ont cru en moi et m’ont

accompagné tout au long de mon travail.


TABLE DES MATIERES

I. Introduction ..................................................................................................... 1

1.1. Contexte de l’étude ............................................................................................ 1

1.2. Présentation du service ...................................................................................... 2

II. Etat de l’art...................................................................................................... 2

2.1. Genève et le SEMO ............................................................................................. 2

2.1.1. Socle 3D du Canton de Genève ............................................................................................ 2

2.1.2. Utilisations et réalisations .................................................................................................... 4

2.1.3. Projet architectural .............................................................................................................. 6

2.2. Autres exemples de SIG 3D dans le monde .......................................................... 7

2.2.1. France et Europe .................................................................................................................. 7

2.2.2. Le salon IMAGINA ................................................................................................................ 9

2.3. Formats numériques et logiciels ........................................................................ 10

2.3.1. SIG 3D pour le SEMO .......................................................................................................... 10

2.3.2. CAO 3D pour les architectes, urbanistes et paysagistes .................................................... 11

2.3.3. Nouveaux formats et conversions ..................................................................................... 14

III. Définition du problème .................................................................................. 16

3.1. Orientation du projet dans son contexte général ............................................... 16

3.1.1. Analyse bibliographique ..................................................................................................... 16

3.1.2. Données du SEMO. ............................................................................................................. 18

3.2. Etudes des attentes et besoins à Genève ........................................................... 18

3.2.1. Les architectes .................................................................................................................... 18

3.2.2. Les urbanistes et les paysagistes ........................................................................................ 20

3.2.3. Création d’une équipe de travail ........................................................................................ 21

3.3. Synthèse des attentes et solution envisagée ...................................................... 21

3.3.1. Aspect technique................................................................................................................ 21

3.3.2. Aspect administratif ........................................................................................................... 23

IV. Mise en œuvre et réalisations ........................................................................ 24

4.1. Prototype initial ............................................................................................... 24

4.2. Zone région ...................................................................................................... 25

4.2.1. MNT .................................................................................................................................... 25

4.2.2. Bâtiments ........................................................................................................................... 28

4.3. Zone projet ....................................................................................................... 30

4.3.1. Modèle Numérique de Rue (MNR) .................................................................................... 30

4.3.2. Bâtiments ........................................................................................................................... 37

4.4. Géotraitements complémentaires ..................................................................... 38

4.4.1. Edition du Terrain ............................................................................................................... 38

4.4.2. Photos aériennes et images satellites ................................................................................ 39

4.4.3. Habillage ............................................................................................................................. 41


4.5. Echanges et interopérabilité ............................................................................. 42

4.5.1. Paramètres d’échange ....................................................................................................... 42

4.5.2. Logiciels utilisés .................................................................................................................. 43

4.5.3. Poids des données .............................................................................................................. 46

V. Résultats et validation ................................................................................... 47

5.1. Résultats possibles avec le socle urbain 3D ........................................................ 47

5.2. Validation de la solution ................................................................................... 50

5.2.1. Validation avec les différents acteurs ................................................................................ 50

5.2.2. Analyse de précision .......................................................................................................... 51

VI. L’aspect administratif et politique .................................................................. 54

6.1. Les procédures administratives ......................................................................... 54

6.1.1. Les autorisations de construire .......................................................................................... 54

6.1.2. Les concours d’architecture ............................................................................................... 55

6.1.3. Formats de présentation .................................................................................................... 56

6.2. Les enjeux politiques ........................................................................................ 57

6.3. Valorisation de l’utilisation de la 3D .................................................................. 57

6.3.1. La fiche d’information ........................................................................................................ 58

6.3.2. Le dépliant .......................................................................................................................... 58

VII. Conclusions et perspectives......................................................................... 59

Table des illustrations ............................................................................................ 61

Table des tableaux ................................................................................................. 62

Sommaire des annexes ........................................................................................... 62

Bibliographie ......................................................................................................... 63

Liste des abréviations ............................................................................................. 65


1

I. INTRODUCTION

1.1. Contexte de l’étude

Les techniques de modélisation 3D deviennent de plus en plus efficaces et intéressent

toujours plus de monde dans des domaines d’activités extrêmement variés, allant des activités

commerciales comme le cinéma depuis peu ou les jeux vidéo, jusqu’aux activités de

représentations du territoire et de l’environnement nous entourant.

Ainsi, de nombreuses villes, plus ou moins grandes, se munissent de maquettes

numériques plus ou moins détaillées. De telles maquettes représentent tout d’abord des vitrines

technologiques et touristiques pour ces villes, permettant de s’y balader interactivement ou de

repérer certains endroits avant même de s’y rendre. En matière d’urbanisme et d’architecture,

les avantages de telles maquettes peuvent paraitre évidents. La représentation

tridimensionnelle est en effet devenue un réel outil décisionnel pour l’urbanisme et

l’aménagement du territoire. Il s’avère aujourd’hui que la représentation en 2 dimensions, même

accompagnée de coupes, ne suffit plus toujours pour comprendre le paysage urbain existant ou

les projets futurs. Les maquettes 3D permettent donc de visualiser les projets architecturaux,

mais aussi de les insérer dans leurs environnements, facilitant ainsi la compréhension, la

concertation entre pouvoirs publics et donc la prise de décision.

Cette perspective d’urbanisation réfléchie et maitrisée a très vite intéressé le Service de la

Mensuration Officielle (SEMO) de Genève qui fut parmi les précurseurs dans la création d’un

modèle numérique 3D complet d’une telle envergure, soit environ 76 000 bâtiments sur plus de

245 km2. Ce socle 3D est composé du modèle numérique de terrain drapé d’orthophotos, des

bâtiments en 3D, d’une couche végétation avec les principaux arbres et de nombreux ponts et

ouvrages d’arts.

Toutes ces données sont disponibles pour les professionnels de la construction, mais ne

sont malheureusement que trop peu utilisées { ce jour, malgré tous les avantages qu’elles

pourraient amener. Il s’agit donc de réaliser une analyse détaillée des besoins des professionnels

de l’aménagement du territoire en termes de données 3D, de comprendre pourquoi ces données

ne sont que si peu utilisées et d’y apporter des solutions. Il faudra définir les géotraitements {

appliquer aux données existantes, les compléments éventuels aux données à fournir et réfléchir

{ un prototype de jeu de données prêtes { l’emploi (formats numériques d’échange, contenu,

utilisations…).

Ce rapport présente donc toutes les étapes de ce Projet de Fin d’Etudes (PFE), de l’état de

l’art sur les données tridimensionnelles dans le monde et { Genève, en passant par la définition

du besoin, la réponse au problème et la présentation des différents résultats possibles grâce au

jeu de données qui a été créé. Mais avant toute chose, il paraît important de présenter le Service

au sein duquel ce projet a été réalisé.

1.2. Présentation du service

Je vais tout d’abord présenter le Service de la Mensuration Officielle (SEMO) qui m’a

accueilli pendant 5 mois dans le cadre de ce PFE. Ce service fait partie du Département de

l'Intérieur et de la Mobilité (DIM), et dépend de la Direction Générale de l’Intérieur (DGI) de

l’Etat de Genève, comme vous pouvez le voir sur l’organigramme en annexe 1.


2

Anciennement appelé « cadastre », le Service de la « mensuration officielle est

responsable de l'acquisition, de la gestion et de la diffusion des données de mensuration du

territoire ». Grâce à cette centralisation des données et leur grande cohérence spatiale, « chacun

peut dorénavant bénéficier d'informations tirées à la source du référentiel spatial commun,

comportant les dernières mises { jour […] Dès lors, la modélisation du territoire effectuée

suivant des critères rigoureux de précision, fiabilité et homogénéité offre l'opportunité, à plus de

vingt services publics, d'abandonner la mise à jour d'autant de duplicata du cadastre et de

réaliser des économies conséquentes.» (etatge@[2011]).

C’est en 2005 qu’a commencé la réflexion sur la création d’un socle 3D complet qui

permettrait d’enrichir la représentation du territoire, de faciliter la planification

d’aménagements urbains et d’une manière générale la gestion du territoire. « La troisième

dimension constitue sans conteste une percée majeure en matière d’outils de politiques

publiques » affirme Laurent Niggeler, directeur du SEMO, dans un article du magazine

Géomatique Expert consacré à la 3D à Genève (Niggeler[2009]).

C’est le SOSI1 qui se charge de la centralisation et la mise en ligne de toutes les données du

territoire genevois, pas seulement issues de la mensuration officielle, mais provenant de tous les

services de l’Etat. Chaque service met quotidiennement son serveur à jour et toutes ces données

sont transférées sur le serveur de publication du SOSI une fois par semaine, ce qui assure une

mise à jour régulière et une fiabilité des données mises à disposition des utilisateurs.

La consultation des données est gratuite et libre d’accès, alors que l’extraction des

données nécessite un compte utilisateur. Tous les partenaires du SITG2 possèdent un compte, et

les professionnels n’ayant pas de compte mais étant mandatés pour effectuer un quelconque

travail nécessitant des données peuvent commander un jeu de données auprès du SOSI.

II. ETAT DE L’ART

2.1. Genève et le SEMO

2.1.1. Socle 3D du Canton de Genève

2.1.1.1. Acquisition des données

Nous allons commencer par expliquer comment ont été saisies les données 3D du Canton

de Genève ainsi que les utilisations qui en ont été faites afin de replacer l’étude dans son

contexte.

C’est la société danoise COWI qui a été mandatée pour réaliser la saisie et la modélisation

des bâtiments, par l’intermédiaire de leur partenaire suisse GeoDataNetwork, spécialisée dans

« l'acquisition et le traitement de données à référence spatiale » (Geodatanetwork@[2011]).

COWI est un groupe de conseil international, spécialisé dans l’ingénierie, les sciences de

l’environnement et l’économie, basée { Lyngby, au Danemark (COWI@[2011]).

1 Service de l’Organisation des Systèmes d’Information 2 Système d’Information du Territoire Genevois


3

Le SEMO a fourni { la société COWI l’ensemble des données suivantes nécessaires pour

leurs travaux :

L’ensemble des données vectorielles 2D du SITG, et notamment l’empreinte cadastrale de

tous les bâtiments à saisir. La précision planimétrique de ces données est de 10cm en NT2

et de 20cm en NT31.

Le Modèle Numérique d’Altitude (MNA) ainsi que le Modèle Numérique de Terrain (MNT)

issus de données LiDAR. La densité de ces données LiDAR est de 3 points par m² et chacun

de ces points a une précision planimétrique (erreur moyenne quadratique) de 20cm et

une précision altimétrique allant de 15cm à 50cm en fonction de la nature du sol.

Les photographies aériennes orientées de la zone. Celles-ci datent de 2005 et ont une taille

de 11500x7500 pixels et une résolution au sol de 16cm.

Les points caractéristiques des toitures ainsi que leurs arêtes sont saisis par mesures

stéréographiques sur les photographies aériennes et classifiés selon leurs types. Les bâtiments

sont ensuite modélisés automatiquement { l’aide d’un logiciel développé par COWI en se basant

sur les empreintes cadastrales des bâtiments fournies par le SEMO. La méthodologie est

explicitée plus en détail sur le site Bati3D@[2010].

Une série de tests et d’éditions topologiques sont menés afin de respecter le cahier des

charges, notamment sur l’orthogonalité ou le parallélisme des faces. Les bâtiments modélisés

sont finalement envoyés au SEMO au format ESRI MultiPatch, où ils sont à nouveau contrôlés et

vérifiés avant d’être insérés dans la base de données. Nous reparlerons de ce format numérique

dans la suite de ce rapport.

Les bâtiments remarquables et ouvrages d’art nécessitent un niveau de détail (LOD2) plus

élevé que les bâtiments classiques. Ils ont donc été modélisés par photogrammétrie terrestre

rapprochée. Une quinzaine de bâtiments remarquables ont été modélisés de cette manière à

Genève, ainsi qu’une quinzaine de ponts (cf Figure 1).

Des couples d’images stéréoscopiques sont acquisses sur chaque bâtiment et permettent

une modélisation détaillée des ouvrages, grâce également à des mesures complémentaires de

distances sur les bâtiments et de mesures de points au GPS afin de caler le modèle, d’orienter les

images ou de contrôler le travail réalisé. Des nuages de points sont également obtenus par

lasergrammétrie terrestre. Ces ouvrages d’art sont le plus souvent modélisés par des cabinets de

géomètres privés de Genève.

1 « Niveaux de Tolérance », ces niveaux vont de 1 à 5 et varient en fonction de la zone géographique sur le Canton de Genève.

2 « Level of Details », niveau de détails allant de 0 à 4 (voir §2.3.3.1).

Figure 1| Exemple de bâtiment remarquable: le Grand Théâtre de Genève


4

2.1.1.2. Gestion et mise à disposition

Toutes les données de la mensuration 2D et 3D sont disponibles au téléchargement pour

les partenaires du SITG grâce à un « GeoExtracteur ». Cet accès aux données est très pratique. Par

exemple, si un géomètre a besoin d’un lever de corps de rue pour un de ses travaux, il peut

obtenir ces données à distance et sans délais grâce au GeoExtracteur. On peut également

simplement visualiser la ville de Genève en 3 dimensions sur le guichet GEO3D du site du SITG.

Voici le principe de fonctionnement du GeoExtracteur. On sélectionne une zone

géographique, soit par un rectangle, soit par un polygone, puis on tri les couches d’informations

qui nous intéressent. Il y a 600 couches environ au total, qui sont heureusement également

rangées par thèmes que l’on peut choisir automatiquement, comme les données générales de la

mensuration, l’assainissement ou encore les données en 3 dimensions. Une surface maximale

d’extraction (400 ha) est définie afin d’éviter que quelqu’un ne télécharge tout le canton en une

fois, et l’utilise ensuite comme base pour ses travaux sans se soucier des mises { jours régulières

qui sont effectuées. Les données de cette zone sélectionnée sont ensuite directement

téléchargeables dans un fichier compressé.

Vous trouverez en annexe 2 toutes les

données 3D qui sont téléchargeables sur le

GeoExtracteur. Parmi celles-ci, il est

important de citer ici les bâtiments 3D et de

présenter leurs compositions en 5 couches

(cf Figure 2 ci contre).

2.1.2. Utilisations et réalisations

Nous allons maintenant voir quelques exemples de projets qui ont été réalisés grâce aux

données 3D fournies par le SITG. La volonté du SEMO est de garantir un socle 3D complet avec

tous les attributs nécessaires à des analyses et simulations précises. Ce ne sont pas les aspects

visuels et « touristiques » qui sont les priorités.

2.1.2.1. Simulation d’aménagement du territoire et de trafic routier

Un important projet de réaménagement de la zone de Bernex Est à Genève a été réalisé en

2009, et plusieurs petits films d’animations présentant la situation future ont été réalisés en se

basant sur le socle 3D du canton.

La Figure 3 ci-dessous est un extrait de ces animations très réussies esthétiquement. Elles

ont été réalisées par GVA, une société basée à Paris dont nous reparlerons au §3.1.1. Sur l’extrait

ci dessous, nous voyons les futurs immeubles qui ont été insérés dans le socle 3D et qui

permettent d’avoir un aperçu volumique de leurs emprises. Les polygones 2D verts représentent

toute l’étendue du projet et les projets d’aménagement ponctuels peuvent être expliqués au fur

et à mesure que la camera survole leurs sites. Malgré un très bon aspect visuel, on remarque

néanmoins un petit défaut, { savoir une brusque transition de la résolution de l’orthophoto du

MNT { l’arrière plan.

Figure 2| Composition d'un bâtiment 3D


5

L’exemple suivant montre une simulation de trafic routier qui permet de planifier

l’alternance des feux tricolores { un carrefour (cf Figure 4). Il s’agit du projet d’aménagement du

Parc de stationnement des Suzettes, faisant parti du même projet global. Nous y voyons les

différentes phases du cycle des feux et quelle ligne de voitures peut rouler ou doit s’arrêter {

tout moment. Le plan 2D est également présenté en incrusté mais nous remarquons que la

compréhension du projet est extrêmement facilité par l’animation. Cela permet de présenter le

projet à un public amateur, non familier avec les plans 2D.

2.1.2.2. Aménagement d’une plate forme de transports en commun

Un autre projet important a été celui de la simulation des flux sur un carrefour faisant

intervenir des bus (flux réguliers), des voitures et des piétons (flux aléatoires). En effet, au

printemps 2010, le nouveau plan de réseau des TPG1 a été soumis aux députés qui ont demandé

des compléments d’informations, notamment sur les nœuds de transbordement. Cette

simulation complexe a été réalisée par Olivier Donzé et Yacine Benmansour, professeur et

assistant à la Haute Ecole du Paysage, d’Ingénierie et d’Architecture (HEPIA) de Genève.

Les flux de piétons et de voitures ont été modélisés en se basant sur des statistiques de

parcours obtenues par comptages sur les lieux. Tous ces déplacements sont régulés par des feux

de signalisation. Les flux de bus ont été réalisés grâce aux calendriers des TPG. Les véhicules ne

peuvent que se déplacer suivant des tracés linéaires, tandis que les piétons peuvent circuler

librement sur des espaces délimités. Le tout a été représenté dans un environnement 3D créé à

partir des données 3D du SEMO. Plusieurs variantes d’aménagement ont ainsi été proposées

(positions des passages cloutés, des feux tricolores, des tracés de bus…). La Figure 5 ci-dessous

montre un extrait de cette animation qui simule la vie du carrefour pendant une heure de pointe.

1 Transports Public Genevois

Figure 3 | Extrait d'une animation réalisée grâce aux données 3D du SEMO

Figure 4 | Extrait de l'aménagement d'un carrefour


6

Il faut préciser une chose importante concernant l’imageFigure 5 ci-dessus, c’est que le

terrain sur lequel repose les immeubles n’est pas issu du MNT du SEMO. C’est un plan horizontal

sur lequel ont été plaqués les dessins des routes, trottoirs et marquages routiers. Seuls les

bâtiments sont issus des données du SEMO.

2.1.3. Projet architectural

Grâce aux contacts privilégiés du SEMO, j’ai rapidement pu rencontrer M. Christian Tellols,

architecte de la société IMPLENIA, « premier groupe de construction de Suisse »

(Implenia@[2011]). Il est un des rares acteurs privés a avoir demandé des données 3D au SEMO

afin de mettre en valeur le projet du nouveau bâtiment du Centre Médical Universitaire (CMU)

de Genève. Le quartier du CMU a ensuite servi de zone pilote tout au long du projet.

Les architectes de IMPLENIA ne travaillent pas encore régulièrement sur des maquettes

3D complètes, ils créent plutôt des images de synthèses à base de photographies retouchées,

depuis des points de vues fixes. Une maquette numérique du bâtiment projet est d’abord

élaborée et des photos aériennes de la zone sont prises grâce à un appareil photo fixé sur un

ballon { l’hélium radiocommandé. C’est finalement un travail d’incrustation de la maquette dans

une de ces photos aériennes qui est réalisé afin de vendre le projet. Pour cela, il faut au minimum

3 points connus en coordonnées locales par rapport à son projet et visibles sur la photo afin de

calculer la position et l’orientation de la caméra au moment de la prise de vue (technique du

relèvement spatial). En donnant la géométrie du capteur de la camera et en cliquant ces points

homologues, cette orientation de la photo se fait automatiquement grâce à une application du

logiciel 3DStudioMax. Cette image servira simplement de fond dans Photoshop, logiciel utilisé

pour réaliser ces images de synthèses « publicitaires ». Cette opération de saisie de points

homologues est largement facilitée par l’utilisation des données du SEMO, car tous les coins de

bâtiments sont connus et il suffit de cliquer les points homologues sur la photo et les bâtiments

3D. On peut ainsi cliquer plus de points que nécessaire ce qui permet au logiciel de compenser

ses calculs par la technique des moindres carrés. Sans ces bâtiments 3D, le travail d’un géomètre

serait nécessaire pour lever et fournir les coordonnées des points homologues. La Figure 6

montre l’environnement du logiciel 3DStudioMax avec le bâti 3D, le projet architectural au

centre et les positions des caméras calculées (en rouge).

Figure 5 | Extrait de la simulation des flux de l'HEPIA (Donzé, O. et al. [2010])


7

Voici enfin un exemple de résultat que l’on peut obtenir avec cette méthode (cf Figure 7).

Des masques de premier plan et d’arrière plan par rapport au bâtiment projet sont crées dans la

photo pour y insérer la maquette 3D projet. Puis l’image est retouchée pour ajouter les arbres,

les piétons, et tout l’habillage rendant la scène vendeuse. D’autres textures peuvent également

être appliquées sur le futur immeuble.

2.2. Autres exemples de SIG 3D dans le monde

Nous allons maintenant voir les exemples d’autres villes dans le monde où le

développement de la 3D est important. Les quelques exemples de villes citées ci-dessous ont été

choisis pour leurs intérêts par rapport au sujet de ce projet, c'est-à-dire pour leur intérêt à

faciliter l’utilisation de leurs données par les professionnels privés. Cependant, la liste des villes

se dotant d’une maquette virtuelle en 3 dimensions plus ou moins aboutie devient de plus en

plus longue grâce à la relative popularisation des technologies dans ce domaine.

2.2.1. France et Europe

2.2.1.1. Le Havre

L’exemple de la ville française du Havre est intéressant dans la mesure où la volonté du

service SIGU1 de la ville a également été de créer une passerelle intuitive entre les métiers de

l’aménagement du territoire et le SIG de la Ville. La modélisation de la ville a commencée dès l’an

2000 { l’initiative du SIGU et permet maintenant une communication efficace en matière

d’urbanisme. Le Havre, c’est notamment 65 661 bâtiments modélisés (cf Figure 8), dont 60%

avec leurs textures photographiques, sur 60,3km2 et 23 646 arbres sous formes de points cotés

avec leurs altitudes (Banaszak[2008]).

1 Système d'Information Géographique Urbain

Figure 7 : Insertion de la maquette 3D dans la photographie, avant retouches (à gauche) et après (à droite)

Figure 6| Environnement du logiciel 3DSmax avec les bâtiments 3D du SEMO


8

L’évolution de l’utilisation de la 3D au Havre est très bien retranscrite { la lecture des deux

tomes récapitulatifs du salon Imagina, dans la rubrique « La 3D au service des collectivités »,

dont tous les articles ont été recueillis par Hervé HALBOUT, consultant expert SIG et 3D, lors des

salons Imagina 2009 et 2010. Cette évolution sera décrite plus en détails au § 3.1.1.

2.2.1.2. Berlin

L’exemple de la ville de Berlin est intéressant pour sa consultation facile en ligne grâce à

GoogleEarth. En effet, contrairement au Havre qui diffuse sa maquette par le logiciel LandSIM3D

qui est payant, et donc inaccessible au public amateur, tous les bâtiments de la ville de Berlin

sont modélisés et visible sur le portail libre GoogleEarth. Il existe en plus une version

uniquement consultable sur une borne dans le showroom du Business Location Center, au

centre de la capitale allemande. Cette version, d’une qualité esthétique supérieure, est

essentiellement destinée aux investisseurs, afin qu’ils puissent mieux visualiser les projets dans

lesquels ils mettent de l’argent.

En tout, environ 500 000 bâtiments ont été modélisés sur à peu près 890 km2, de plus,

près de 40 000 bâtiments ont été texturés avec leurs vraies textures photographiques, ce qui a

demandé un travail de lever photographique important. En plus du niveau de réalisme saisissant

sur tous ces bâtiments grâce aux textures, environ 80 bâtiments et attractions ont été modélisés

en LoD3, c'est-à-dire à un niveau de détails architecturaux encore supérieur et cinq d’entres eux

ont même été modélisés de l’intérieur (LoD4), comme le business location center ou la gare

centrale. Sur la Figure 9, présentant des captures d’écran GoogleEarth, nous remarquons la

différence en terme de niveau de détails entre un bâtiment comme le Reichstag en LoD3, où les

colonnes sont bien modélisées avec des cylindres, tandis que sur un bâtiment classique en LoD2,

ici un musée, les colonnes sont représentées très sommairement avec une seule face aplatie.

Sur l’image Figure 10 ci-dessous prise sur le site BusinessLocationCenter@[2011], nous

pouvons voir un exemple d’édifice en LoD4 avec la gare centrale dont tout l’intérieur a été

Figure 8: Extrait de la maquette virtuelle du Havre (LeHavre@[2011])

Figure 9| Aperçus du Reichstag en LoD3 et d’un musée en LoD2


9

modélisé, notamment à cause de la transparence de la baie vitrée. Cette image (à gauche) est

tirée de la version du socle 3D des bornes interactives du Business Center. On voit clairement la

différence de rendu avec la version libre d’accès de GoogleEarth (à droite) sur laquelle l’intérieur

de la baie vitrée n’est pas représenté.

Vous trouverez en annexe 3 un paragraphe sur le projet VirtualEarth de Microsoft, qui

consiste à modéliser en 3D avec un rendu impressionnant les principales villes américaines.

2.2.2. Le salon IMAGINA

2.2.2.1. Présentation

Chaque année, le salon IMAGINA de Monaco se veut être une vitrine européenne des

nouvelles technologies dans les domaines « des effets spéciaux, de l’architecture des médias et

du divertissement » comme le dit son directeur général, Laurent PUONS dans l’article

(Halbout[2009]). Depuis 2008, un nouveau domaine est { l’honneur, il s’agit de la 3D territoriale.

Devant l’évolution des technologies dans ce domaine et la prise de conscience des collectivités, le

salon a installé un « village territorial » composé de stands où les différentes villes peuvent

exposer leurs maquettes numériques tridimensionnelles, les applications, analyses ou

simulations qu’elles permettent et qui sont développées. Les villes présentent sont toutes

francophones, avec les différentes villes de France actives dans la 3D (Le Havre, Lyon,

Montpellier, Cannes…) mais également le Canton de Genève ainsi que la ville de Montréal.

Le développement des utilisations de la 3D par les professionnels de secteurs variés ainsi

que la relative popularisation de cette technologie a également amené { réfléchir { l’éthique de

telles représentations virtuelles.

2.2.2.2. La charte d’éthique de la 3D

Les perspectives offertes par des visualisations immersives dans un environnement

tridimensionnel pourraient permettre de montrer une réalité « plus belle que nature »

(3DOK@[2011]) et ainsi tromper un éventuel client sur la qualité d’un futur projet grâce { des

techniques d’infographie. Olivier BENASZAK de la ville du Havre convenait déj{ en 2008 dans

son article (Benaszak[2008]) qu’ « il faut faire preuve d’une grande déontologie […] afin de ne

pas enjoliver artificiellement la réalité ou les projets mis en scène. » C’est pour empêcher ce

genre de pratique qu’une charte d’éthique de la 3D, { l’initiative du Canton de Genève entre

autres, a été élaborée et signée en février 2010 lors du salon Imagina sous l’égide du Prince

Albert de Monaco. De nombreux organismes (comme l’IGN1, la principauté de Monaco, l’office

1 Institut Géographique National

Figure 10| Différences entre les 2 versions du socle 3D de Berlin. Exemple de la gare centrale.


10

fédéral de topographie Swisstopo, l’ordre des arpenteurs géomètres du Québec ou bien l’AFT1

depuis peu…) et de sociétés ou écoles ont signé cette charte, et la liste continue à s’allonger mois

après mois.

Cette charte décrit les règles { respecter en matière d’utilisation de la 3D et s’appuie sur 3

principes résumés ci dessous:

Principe de crédibilité : les signataires s’engagent { n’utiliser que des scènes

tridimensionnelles de qualité, s’appuyant sur des données fiables, actuelles et de nature

officielles de préférence.

Principe de transparence : les signataires s’engagent { documenter leurs créations avec

notamment les sources des données, et { les accompagner d’une légende adéquate si

besoin.

Principe de développement de réseaux et formation 3D : ce principe sert à faire se

développer les bonnes pratiques dans l’utilisation de la 3D, promouvoir l’échange, la

formation initiale et continue et donc la déontologie générale autour de la 3D.

Cette charte s’adresse aux collectivités publiques, aux unités de recherches,

aux associations professionnelles et aux entreprises privées qui, après avoir signé

la charte, pourront apposer le logo ci-contre (cf Figure 11) certifiant que leurs

créations sont « 3DOK » et dignes de confiance.

2.3. Formats numériques et logiciels

Il apparait immédiatement que le problème d’interopérabilité entre logiciels constituera

un élément récurent lors de ce projet. C’est un point qui revient dès que l’on parle d’échanges de

données, géographiques ou non. Il s’agirait concrètement de créer des passerelles facilitées

entre deux mondes qui ne sont actuellement pas encore entièrement compatible à savoir les

Systèmes d’Information Géographique (SIG) et la Construction Assistée par Ordinateur en 3D

(CAO 3D).

2.3.1. SIG 3D pour le SEMO

2.3.1.1. L’environnement ESRI

L’avantage d’un SIG comme celui du Canton de Genève est que chaque couche d’éléments

est accompagnée d’une table attributaire complète permettant des applications d’analyses

puissantes et efficaces.

Les données du SITG sont gérées dans l’environnement ESRI avec sa suite logicielle ArcGIS

dont le SEMO a reçu la toute nouvelle version 10 peu après le début du projet, ce qui fut

bénéfique dans la mesure où beaucoup de fonctionnalités supplémentaires relatives à la 3D ont

été ajoutées dans le module 3Danalyst et dans ArcSCENE 10, preuve de la prise de conscience des

développeurs de l’intérêt des utilisateurs pour cette technologie.

Les couches de données géographiques sont rangées dans des GéoDatabases , très

spécifiques à ESRI et qui permettent entre autres de bien gérer les systèmes de références et les

1 Association Française de Topographie

Figure 11 | Logo 3DOK


11

coordonnées nationales. Les bâtiments 3D sont, quant à eux, enregistrés au format MultiPatch

également spécifique { ESRI, et qui, au moment de l’acquisition du bâti 3D, semblait être le

meilleur format de stockage pour l’utilisation qu’en avait le SEMO. Il s’avère néanmoins

aujourd’hui, comme le constatait déj{ M. Koehl en 2008 dans son article (Koehl[2008]) que « les

MultiPatchs ne représentent pas des solutions complètes à tous les problèmes liés à la

représentation des propriétés 3D ». Une description plus détaillée du format MultiPatch sera

donnée dans la définition du problème au §3.1.2.

2.3.1.2. L’alternative Autodesk

La société AutoDesk est surtout connue pour ses logiciels de CAO classiques comme

AutoCAD et toutes ses déclinaisons, ainsi que pour son logiciel de création et de rendu

3DStudioMax. Elle propose également plusieurs logiciels spécifiques { l’architecture comme

Revit et AutoCAD Architecture ou au génie civil avec Civil3D (AutoDesk@[2011]). L’initiative de

AutoDesk de se lancer dans les Systèmes d’Information Géographique pourrait donc être

intéressante pour Genève. Cela pourrait permettre d’avoir les créations des architectes et la

gestion de la base de données urbaine par le SEMO dans le même environnement, ce qui pourrait

faciliter cette interopérabilité tant recherchée.

Afin d’étudier cette opportunité, le SEMO a accueilli une équipe de support AutoDesk

début Février, venue nous présenter leurs produits SIG LandXplorer et son successeur Galileo.

Beaucoup de villes germaniques modélisées en 3D sont déjà gérées dans un environnement

AutoDesk comme Fribourg ou Berlin présentée plus haut. La ville du Havre en France, quant à

elle, sert de zone de test pour le projet Galileo. La promesse du projet Galileo est d’offrir un

environnement intuitif d’utilisation permettant, sur la base d’un socle 3D de base :

de gérer des bases de données complètes.

d’intégrer des données 3D provenant de la CAO dans à peu près tous les formats existants,

suivant le modèle OSGeo1, « fondation dont la mission est d'aider et de promouvoir le

développement collaboratif des données et des technologies géospatiales ouvertes »

(OSGeo@[2011]).

de réaliser des analyses et simulations poussées.

de créer des animations, rendus et vidéos de présentations.

Malheureusement, malgré sa prétention à supporter pratiquement tous les formats 3D,

Galileo ne reconnait évidemment pas le MultiPatch, format de son concurrent ESRI. Ainsi, alors

que les bâtiments de tout le Canton « viennent » d’être acquis en MultiPatch, cela paraitrait

inconfortable de changer d’environnement de gestion { l’heure actuelle. De plus, Galileo ne

possède à priori pas encore la même puissance d’analyse spatiale proposée par la suite ArcGIS.

2.3.2. CAO 3D pour les architectes, urbanistes et paysagistes

Il s’agit dans ce paragraphe d’énumérer de façon non exhaustive les principaux logiciels

utilisés par les professionnels genevois. Cette liste a été élaborée tout au long du stage suite aux

rencontres avec les différents intéressés ou aux réponses à un sondage (voir annexe 4).

1 Open Source Geospatial


12

2.3.2.1. AutoCAD

Développé par AutoDesk, c’est le logiciel le plus utilisé par tous les corps de métiers

confondus, c’est un outil de CAO polyvalent et qui bénéficie de beaucoup d’extensions ou

d’applicatifs pour des domaines d’activités spécifiques, comme par exemple COVADIS pour la

topographie. Concernant les formats de données proposés { l’extraction par le SITG, AutoCAD

permet d’ouvrir les fichiers au format *.dxf, format d’échange répandu. Le résultat est filaire

dans les deux cas, comme le montre l’aperçu ci-dessous (cf Figure 12), et ne présente pas de

grandes possibilités de création pour les architectes qui n’utilisent pas vraiment ce logiciel pour

leurs travaux 3D.

2.3.2.2. ArchiCAD

ArchiCAD est développé par GraphiSoft, une société hongroise (GraphiSoft@[2011]). C’est

un logiciel spécifique pour les architectes dont l’extension de fichier principal est *.pln, format

également très spécifique. Heureusement, la liste des formats d’import supportés est assez riche.

Il s’avère que tous les architectes que j’ai rencontrés dans le cadre de mon projet

possèdent au moins une licence ArchiCAD et l’utilisent régulièrement, c’est donc un logiciel dans

lequel il sera important de pouvoir importer nos données et les éditer de manière aisée.

2.3.2.3. Logiciels de graphisme 3D

Egalement développé par AutoDesk, 3DStudioMAx est la référence en matière de logiciel

de création et de rendu 3D de qualité professionnelle, tout comme son format de données natif,

*.3ds, qui est reconnu par globalement tous les logiciels gérant des objets en 3 dimensions. C’est

un format un peu « vieillissant » mais qui répond toujours bien aux attentes des utilisateurs en

termes de 3D. Ce logiciel n’est pas du tout spécifique au domaine de la géomatique ou de

l’architecture, il est énormément utilisé dans l’industrie du cinéma ou des jeux vidéo, secteurs

dans lesquels les budgets de développement sont d’ailleurs les plus importants et qui

représentent un réel moteur et source d’inspiration dans l’ouverture des villes { la création de

maquettes virtuelles. 3DSMax est aussi utilisé par certains architectes afin de créer des images

de synthèses de leurs projets futurs, comme nous l’avons vu au § 2.1.3.

Il existe d’autres logiciels concurrents à 3DSMax possédant globalement les mêmes

fonctionnalités. On peut citer :

Cinéma 4D : logiciel de graphisme 3D développé par Maxon Computer GmbH, une société

allemande, « C4D » est notamment utilisé par Olivier Donzé et Yacine Benmansour,

professeurs à l’HEPIA de Genève et qui réalisent la majorité des images de présentations

Figure 12 | Rendu filaire du format *.dxf dans AutoCAD


13

utilisant le socle 3D du SEMO (cf Figure 13 ci-dessous). C’est également avec ce logiciel

qu’ils ont réalisés les simulations vues au §2.1.2.2.

Rhinocéros : développé par la société McNeel. Il a l’avantage de très bien gérer des

nuages de points denses et de rester fluide en utilisation même avec un grand nombre

d’objets complexes.

Blender : il a la particularité d’être le seul logiciel parmi les 3 cités dans ce paragraphe {

être gratuit et OpenSource. Ses caractéristiques permettent néanmoins d’obtenir des

résultats équivalents à ceux de 3DSMax ou C4D.

2.3.2.4. Les logiciels libres

Il existe une alternative aux logiciels précédemment cités et souvent très chers, à savoir la

solution Google SketchUp. Ses principaux avantages sont :

sa gratuité (il existe néanmoins une version pro payante).

son interface sobre et allégé comparé à un 3Dstudio par exemple où la quantité

impressionnante de paramètres modifiables peut décourager à premier abord.

sa simplicité de prise en main.

L’aspect graphique rappelant un peu un croquis à la main est agréable pour la création

mais parait un peu léger pour ensuite présenter un projet à un client ou à du public par exemple.

Heureusement le format *.skp est très largement supporté par nombres de logiciels de rendu

comme Artlantis, développé par GraphiSoft, et permettant ainsi tout de même de créer des

images de synthèse de qualité professionnelle. L’interopérabilité avancée entre SketchUp et

GoogleEarth est également très utile à certains urbanistes qui peuvent présenter leurs projets

dans cet environnement, souvent familier du public amateur qui peut trouver ca appréciable.

La version 6 de SketchUp offrait également une interopérabilité efficace avec ArcGIS, via

quelques plugins téléchargeables sur le net. Elle permettait aux opérateurs du SEMO d’éditer

eux-mêmes leurs bâtiments MultiPatch afin de mettre à jour la maquette de la ville, ajouter des

bâtiments projets, surélever des toitures, etc… L’utilité de cette interopérabilité pour éditer du

MultiPatch est décrite plus en détail par Mathieu Koehl dans son article Koehl[2008] où cette

technique avait servie { intégrer la maquette de l’abbaye de Niedermunster dans un SIG 3D.

Malheureusement, depuis la version 7 de SketchUp, ces plugins ne fonctionnent plus, au grand

dam de nombres d’utilisateurs comme en témoigne la multitude de forums { ce sujet créés sur le

site support d’ESRI (ESRI@[2011]) entre autres. ESRI préconise désormais d’utiliser le format

Figure 13 | Exemple de maquette virtuelle réalisée par l'HEPIA avec le logiciel Cinema 4D


14

COLLADA afin d’éditer aisément des entités MultiPatch. La description de ce format est

présentée au § 2.3.3.2..

2.3.3. Nouveaux formats et conversions

2.3.3.1. La norme CityGML

Cette norme a été lancée par le groupe allemand GDI-NRW, en coopération avec de

nombreuses entreprises, municipalités et laboratoires de recherche dans le but d’uniformiser le

format d’échange de maquettes virtuelles tridimensionnelles et de faciliter ainsi leurs

interopérabilités. Il est précisé sur le site citygml@[2011] que la norme cityGML « dérive de la

norme GML de l’OGC (OpenGeospatial Consortium) […] permettant déj{ le stockage et l’échange

de modèles virtuels urbains ». Elle définit les classes et relations des objets topographiques

urbains sur le plan géométrique, topologiques, sémantiques et d’apparence visuelle (textures).

Elle permettrait également, outre le coté graphique, de réaliser des simulations et analyses

sophistiquées. De plus, ce format est libre d’accès et ouvert. Les modèles de villes ainsi créés

sont visualisable dans différents logiciels de visualisation, comme notamment LandXplorer de

AutoDesk.

Robert LAURINI, de l’INSA Lyon relève dans son article Laurini[2008] qu’ « en Juillet 2007,

l’OGC a reconnu cityGML comme une excellente proposition » et qu’on pouvait donc s’attendre {

sa démocratisation. C’est également de la norme cityGML qu’est né le concept de « Levels of

Details (LoD) », déjà abordé au § 2.1.1.1. Ces différents niveaux de détails vont de 0 à 4 :

LoD0 : Il s’agit du MNT drapé d’une photo aérienne.

LoD1 : Ce sont les bases des bâtiments extrudées de la hauteur maximale des bâtiments,

pour avoir une idée des volumétries.

Lod2 : Les bâtiments avec les formes principales des toitures et éventuellement les textures

de façades.

LoD3 : Il s’agit de la même chose que le LoD2 seulement avec une finesse architecturale plus

fine (détails des balcons, fenêtres, superstructures…).

LoD4 : Le modèle architectural. On peut entrer dans les bâtiments dont l’intérieur est

modélisé.

La Figure 14 ci-dessous illustre justement ces différents niveaux de détails.

En Janvier 2011, Stephane SEMICHON, spécialiste de l’usage des technologies a écrit un

article intitulé « L’information géographique cherche la bonne formule numérique » dans la

revue Urbanisme (Semichon[2011]). Il y expose les avantages du format GML qui

Figure 14 | Détails des différents LoD de la norme cityGML


15

seraient notamment son ouverture et le fait qu’il soit normalisé (ISO 19136). D’après lui,

beaucoup de sociétés et d’instituts comme le CNIG1 attendent l’arrivée du cityGML comme

standard dans les logiciels, mais sans s’investir dans cette démocratisation, « laissant ce souci à

d’autres ».

Bien qu’il soit voué { un avenir prometteur, le format cityGML n’est toujours pas utilisé {

Genève, du moins pas par les architectes ou urbanistes que j’ai rencontré. C’est pourquoi son

expérimentation ne sera pas développée plus en détail dans ce projet.

2.3.3.2. Le format COLLADA

Comme il a été abordé au § 2.3.2.4, pour remédier au préjudice causé aux utilisateurs par

la fin de l’interopérabilité entre ArcGIS et SketchUp, ESRI préconise désormais l’utilisation du

format COLLADA. Ce format a pour but d’établir un nouveau format d’échange pour les travaux

numériques en 3 dimensions. Les fichiers COLLADA (*.dae) permettent notamment de conserver

le géoréférencement d’un objet. La procédure complète d’édition d’un MultiPatch avec le logiciel

SketchUp grâce au format COLLADA est décrite en détail dans l’article « Creating and Texturing

Multipatch Features » du magazine des utilisateurs ESRI d’hiver 2011 (McCabe, C.[2011]).

2.3.3.3. Les conversions de format

A la lecture de cette section, on comprend que l’interopérabilité entre formats numériques

sera au cœur du projet et qu’il s’agit dès le début de recenser les possibilités de conversion et

d’import/export des différents logiciels. Nous remarquons que les principaux logiciels cités ci-

dessus allongent leurs listes de formats importés et exportés versions après versions, et que les

formats les plus courants sont souvent importables quelque soit le logiciel.

Dans le cas du SEMO, le problème majeur vient du fait qu’aucun logiciel autre que ArcGIS

ne supporte les formats ESRI et notamment le MultiPatch ou les fichiers TIN des MNT. De plus,

certains problèmes peuvent survenir lors d’exports en différents formats, comme par exemple

une inversion des axes lors du passage d’un fichier *.3ds à un fichier *.obj. Ces problèmes sont

heureusement rectifiables grâce au logiciel FME. C’est un logiciel développé par la firme

géographique, d’y appliquer un certain nombre de transformations et enfin de les convertir en

autant de formats d’écriture que de lecture. Il porte bien son surnom de « couteau suisse » des

données géographiques tant il est complet en terme de manipulation de données.

Récapitulatif de la partie II :

Nous avons pu voir dans cette partie que le développement de la 3D est un phénomène

général dans l’aménagement du territoire des différentes grandes villes dans le monde. Genève

fait figure de référence dans ce domaine grâce notamment au SEMO, dont la volonté est de

multiplier les applications et utilisations diverses de ces données. Cela impliquera forcément

un partage des données entre différents domaines d’activité, dans lesquels les professionnels

utilisent de nombreux logiciels et formats numériques différents.

Les premiers problèmes se font ainsi déj{ ressentir, { savoir l’interopérabilité et

l’échange de données, qui sont des problématiques généralement ressenties, pas seulement {

Genève et pas seulement en matière de données géographiques. La prochaine partie traitera de

la définition du besoin plus spécifique au Canton de Genève et aux utilisateurs potentiels, à

savoir les architectes, urbanistes ou paysagistes.

1 Conseil National de l’Information Géographique français


16

III. DEFINITION DU PROBLEME

La première étape du projet a été de réaliser l’étude de besoins en matière de données 3D

des professionnels de la construction.

3.1. Orientation du projet dans son contexte général

Avant de se concentrer principalement sur le cas des utilisateurs potentiels à Genève, il a

été important de se renseigner sur les attentes générales dans les autres pays et de voir si cette

problématique de partage des données géographiques 3D entre métiers est généralement

ressentie.

3.1.1. Analyse bibliographique

Tout d’abord, en 2009 déj{, Thomas Noirot remarquait dans son rapport de PFE

(Noirot[2009]) que « les exemples concrets d’utilisation des données tridimensionnelles comme

aide { l’aménagement du territoire ne sont pas nombreux ». Cette constatation était valable pour

les différentes villes européennes citées comme exemple { l’époque et la cause principale

exprimée était la jeunesse de cette technologie.

Comme il est dit au §2.2.1.1 sur la ville du Havre, la volonté du SIGU est également de

favoriser l’utilisation de leurs données par les professionnels de l’aménagement. En 2009, au

salon IMAGINA, les limites exprimées quant à la maquette virtuelle de la ville portaient sur sa

sous-utilisation et sur le fait qu’elle n’était pas encore accessible au public. Anthony GUEROUT

du SIGU, précise : « Plus la maquette sera utilisée et meilleur sera le retour sur investissement »

(Halbout[2009]). Il parle également de leurs réflexions s’orientant sur « la mise à disposition

gratuite de la maquette auprès des architectes (y compris pour leurs projets privés), avec en

retour des informations intégrables facilement dans celle-ci ».

Un an plus tard, toujours au salon Imagina, la ville du Havre présentait les quelques

projets d’urbanisme ayant mis { contribution leur maquette 3D, comme le projet du nouveau

stade, pour lequel quatre offres ont été faites, « avec des films de présentations, s’appuyant sur

l’intégration du projet dans la maquette et c’est ce qui a servi pour l’analyse des offres. »

(Halbout[2010]). D’autres projets ont suivi sur ce mode comme la construction de logements

étudiants et « la démarche est donc en train de faire école ». D’après le site de la ville du Havre

(LeHavre@[2011]), « 75 projets de réalisation de produits à valeur ajoutée ont été réalisés

depuis 2001 (films, images, panorama,…) » sur la base de la maquette virtuelle. Malgré quelques

applications ludiques et visuelles comme un jeu de nautisme, la priorité du SIGU reste sur

l’authenticité des données géographiques et sur l’interopérabilité de celles-ci. Il leur « semble

important de ne pas rester avec des données dans un seul format propriétaire ». Ce point est

important tant la compatibilité des différents formats de données et logiciels reste un des

problèmes récurrent dans la gestion et l’intégration dans un SIG 3D urbain. En 2008 déj{, dans

un article du magazine XYZ n°114 (Banaszak[2008]), Olivier BANASZAK, chef du service SIGU,

remarquait que « les données sont la plupart du temps étroitement liées aux outils qui les

exploitent, elles en sont mêmes parfois indissociables. Ceci est d’autant plus vérifié dans un

environnement fortement concurrentiel, car en pleine expansion. »

La ville du Havre est seulement un exemple représentatif parmi toutes les villes présentes

au salon. L’analyse globale réalisée par Hervé HALBOUT dans ses deux tomes

(Halbout[2009]&[2010]) permet de dire qu’il existait déj{ en 2009 « un véritable engouement


17

pour les maquettes virtuelles en 3D dans les collectivités territoriales » mais que celui-ci se

heurtait à deux approches différentes. D’un coté, une utilisation de la 3D comme outil de

communication esthétique avec une précision qui reste relative, et d’un autre coté, un outil

centré sur l’aménagement du territoire. « L’intégration de projets dans une représentation du

terrain réel », avec des contraintes de précision semblables aux données 2D fournies

généralement par les géomètres.

Un an plus tard, nous pouvions constater que les maquettes virtuelles tridimensionnelles

présentaient toujours plus d’intérêts pour les collectivités avec des utilisations concrètes qui se

multipliaient : les notions d’aide { la décision, de concertation dans l’aménagement urbain, de

gestion des risques (inondations, bruit…) ou des espaces verts et paysages urbains reviennent

très régulièrement. Nous remarquions tout de même que « l’évolution logicielle demeurait un

peu en retrait par rapport aux demandes et besoins exprimés (ce qui n’était pas le cas pour les

outils SIG2D) », car en effet, tout le monde semblait avoir pris conscience de l’intérêt applicatif

de telles maquettes et non plus du seul apport visuel « touristique ».

La question de l’interopérabilité est récurrente et mentionné chaque année au salon

Imagina notamment : « Nos interlocuteurs ont une attente certaine d’interopérabilité plus

grande entre les logiciels pour travailler sur une maquette 3D. Plusieurs personnes nous ont fait

part de leur intérêt pour une normalisation des données géographiques en 3D »

(Halbout[2010]).

Pour ce qu’il s’agit des exemples de réalisations 3D sur le Canton de Genève présentés aux

§2.1.2.1 et §2.1.2.2, Olivier Donzé et Yacine Benmansour, du groupe de recherche MIP1

expliquent dans l’article de François Gervais (Gervais, F. et al. [2010]) que « le statut de Haute

Ecole Spécialisée (de l’HEPIA) permet de se lancer dans des projets de recherche appliquée et de

défricher des terrains de jeux sur lesquels ne s’aventurent pas (encore) les acteurs privés ».

Comme nous le disions également au §2.1.2.1, les vidéos présentant les futurs

aménagements de la zone de Bernex Est sont très parlantes. De telles vidéos nécessitent

néanmoins un travail d’infographie important en amont et restent donc relativement

anecdotiques. De plus, elles n’ont pas été réalisées par une société locale genevoise mais par Géo

Vision Avenir, une société d’expertise dans l’aménagement urbain spécialisée dans l’infographie

et basée { Paris. Leur technologie d’immersion « permet de vérifier l’impact visuel des projets

par immersion en tout points d’un paysage existant ou futur… » (GVA@[2011]).

Les deux exemples précédents confirment donc que pour le moment, seules des personnes

spécialisées dans les domaines de l’infographie et de la 3D peuvent se permettre d’utiliser les

données 3D du SEMO afin de les mettre en valeur et de leur donner une utilité concrète.

Vous trouverez également en annexe 4 un paragraphe résumant les différentes

présentations en rapport avec le sujet qui ont eu lieu lors d’une veille technologique autour de la

3D qui a été organisée au mois de Mars à Genève, ainsi que les résultats d’un questionnaire

destiné aux spectateurs. Vous y trouverez également le contenu d’un sondage destiné aux

architectes qui a été mis en ligne pour ce projet.

1 Modélisation Informatique du Paysage


18

3.1.2. Données du SEMO.

Avant de se lancer concrètement dans l’analyse des besoins des différents utilisateurs, il

apparait important de se pencher rapidement sur la structure même des bâtiments 3D du SEMO,

qui est { la base du problème d’échange des données. En effet, le SEMO gère un SIG, et a donc fait

saisir les bâtiments 3D au format ESRI Multipatch, qui n’est pas compatible directement avec les

logiciels de CAO.

Voici un bref récapitulatif de l’analyse du format MultiPatch réalisée par Mathieu Koehl

dans son article (Koehl[2008]) :

Le MultiPatch permet de diviser n’importe quel objet complexe en petites entités

triangulaires afin d’en stocker la géométrie tridimensionnelle sous la forme des coordonnées xyz

des sommets des triangles.

Avantages du MultiPatch:

Il permet de représenter des objets géométriques complexes.

Il permet d’appliquer des textures.

Il permet une interaction avec des données 2D.

Inconvénients du MultiPatch :

Il n’est pas reconnu par nombre de logiciels de construction 3D, ce qui limite son

utilisation et l’échange de données dans ce format.

La représentation de surfaces courbes par une multitude de petits triangles.

Son manque de possibilités d’analyse du fait de sa topologie.

Concrètement, le format MultiPatch n’est pris en charge par aucun logiciel utilisé par les

architectes ou urbanistes sur le Canton de Genève { l’heure actuelle. Heureusement, le

GeoExtracteur du SOSI permet également de télécharger les bâtiments aux formats *.3ds entre

autre, qui est déjà plus utilisable pour les personnes ne possédant pas les logiciels ArcGIS.

3.2. Etudes des attentes et besoins à Genève

Le sondage mis en ligne n’ayant pas apporté suffisamment de réponses pour définir une

analyse des besoins objective, il m’a fallu me déplacer et rendre visite aux différents contacts du

SEMO, architectes, urbanistes ou paysagistes afin de confronter leurs remarques et idées pour

identifier les points sur lesquels ils s’accordent et qui nécessiteront donc une réflexion. Tout

d’abord nous allons décrire les attentes des différentes professions séparément.

3.2.1. Les architectes

Pour illustrer les problèmes recensés chez les architectes rencontrés, nous allons

réutiliser le projet de M. Tellols présenté au § 2.1.3 qui résume très bien toute la problématique.

En effet, celui-ci avait déj{ essayé d’utiliser les données 3D pour créer une maquette complète.

Voici comment il s’y prend, et surtout les problèmes qu’il rencontre. A partir des bâtiments dans

le logiciel 3DSmax, il peut découper les façades sur la photo aérienne oblique et les appliquer sur

le bâti 3D en cliquant les coins des façades. Le logiciel redresse automatiquement les photos et le

résultat est satisfaisant. Les deux images de la figure 15 illustrent les différences entre le travail

de retouche photo (cf § 2.1.3) et l’utilisation de la 3D. Les deux photos se ressemblent, elles sont


19

prises du même angle de vue mais n’ont absolument pas été créées de la même façon. Celle de

gauche montre le projet en 3D derrière lequel la photo a été placée en décor, les bâtiments

voisins n’existent pas en tant qu’objets tandis que celle de droite est un aperçu de la maquette

3D du même centre de perspective et dans lequel les façades ont été texturées avec la technique

expliquée ci-dessus. Le premier avantage d’avoir tous les bâtiments environnants en tant

qu’objets en 3 dimensions est la gestion dynamique des ombres portées. En effet, lors de

retouches photographiques sur Photoshop par exemple, l’architecte est obligé bien souvent de

redessiner à la main les ombres projetées des bâtiments les uns sur les autres, tandis que qu’un

logiciel de graphisme 3D comme 3DSmax peut générer la source de lumière selon la position du

soleil et les ombres sont donc calculées automatiquement.

Grâce à cette maquette 3D, il serait possible de faire des animations, de tourner autour du

bâtiment, de présenter le projet dans ses détails et dans son environnement. Ce serait un

avantage certain pour les architectes et une attente de leur part et de la part de leurs clients.

Nous remarquons dans la maquette 3D de la Figure 15 qu’il n’y a pas les rues, les

bâtiments ne reposent sur aucun socle, ce qui nous emmène directement à aborder le premier

problème majeur : le Modèle Numérique de Terrain. Celui-ci est téléchargeable sur le

GeoExtracteur dans différents formats mais ne convient pas aux architectes car il est beaucoup

trop « chaotique ». La plupart des logiciels ne pouvant pas importer de grilles d’élévations ni de

raster, les architectes téléchargent le MNT sous forme de points ASCII qu’ils triangulent ensuite

dans leurs logiciels. En matière d’animations, ce que veulent voir les clients des architectes, ce

sont les points de vue des piétons, ou des voitures circulant autour du futur bâtiment, depuis les

routes et les rues. Pour cela, les architectes auraient besoin d’un MNT beaucoup plus lisse sur

lequel on n’apercevrait plus les triangles le composant. La Figure 16 ci-dessous, capturée sur le

guichet 3D de Genève, illustre bien l’aspect chaotique et brut du MNT qui déplait aux architectes

et qui ne leur convient pas pour leurs créations et vues piétonnes.

Figure 16 | Illustration de l’aspect du MNT qui ne convient pas aux architectes

Figure 15 | Différences entre retouche photo (à gauche) et maquette 3D (à droite)


20

De plus, comme nous le remarquons, les photos sont toujours prises avec une perspective

relativement plongeante (cf Figure 15) pour ne pas montrer l’horizon qui est vide. Il serait

impossible de rajouter tous les bâtiments du canton avec un tel niveau de détails dans le projet

sans saturer la mémoire de l’ordinateur. Il n’y a également pas de MNT et donc pas d’horizon, or

c’est un élément important dans le monde de l’architecture et notamment dans la région

genevoise. En effet, le canton est enclavé dans le bassin lémanique, avec le Jura d’un coté et le

Mont-Salève de l’autre qui sont des repères par rapport auxquels tout le monde se repère et

s’oriente. Pour mieux se représenter l’environnement de la région genevoise, une carte de la

région est donnée en annexe 5. Le fameux jet d’eau de Genève, d’une hauteur de 140 m et visible

de très loin, est également un point de repère connu de tous et qui mériterait sa place dans toute

maquette numérique architecturale sur le canton de Genève.

Un dernier point est mentionné systématiquement par les architectes interrogés, celui du

repère de coordonnées. Les données du SEMO sont fournies dans le système national MN03 (et

maintenant MN95 depuis le changement de cadre de référence en Juin 2011). Les coordonnées

des entités sont donc de l’ordre de centaines de milliers de mètres, ce qui pose souvent des

problèmes aux architectes qui n’ont pas forcement les notions de géoréférencement. Pour eux,

leur projet est le centre d’intérêt de la maquette et est donc placé { l’origine du repère, loin de sa

position réelle par rapport aux bâtiments 3D alentours. Un autre inconvénient provient du fait

que beaucoup de logiciels de CAO 3D ne gèrent les coordonnées qu’en simple précision, avec 7

chiffres significatifs, ce qui implique un arrondi au décimètre pour les coordonnées du bâti 3D.

Cet arrondi provoque une perte de la géométrie et de gros problèmes d’affichage.

3.2.2. Les urbanistes et les paysagistes

Contrairement aux architectes, les urbanistes n’ont pas besoin d’autant de détails au

niveau de la rue et de la route. En effet, ceux-ci travaillent bien souvent sur des projets à plus

grande étendue géographique et jouent donc d’avantage sur les volumétries et l’agencement

général des bâtiments avec un niveau de représentation architecturale inférieur. Leurs projets

sont donc souvent présentés par des survols et vues aériennes dans lesquels un MNT drapé

d’une orthophoto à moyenne résolution suffit.

Un autre point sur lequel les attentes des architectes et des urbanistes diffèrent est celui

du système de coordonnées abordé dans le paragraphe précédent. En effet, les urbanistes, eux,

travaillent sur des projets d’aménagement urbain faisant souvent intervenir beaucoup d’acteurs

de secteurs d’activité différents, et ont donc besoin d’un cadre de référence commun { tous ces

acteurs. Les urbanistes sont également plus susceptibles d’avoir { réutiliser des projets

antérieurs faisant partie d’un projet plus global. On ne peut donc pas juste translater toutes les

données { l’origine de façon aléatoire.

Les attentes des paysagistes coïncident plus avec celles des architectes que des urbanistes.

En effet, tout comme les architectes, ils créent beaucoup d’images et de rendus où le coté visuel

est très important. Cet aspect visuel sera d’ailleurs un point dont il faudra tenir compte tout au

long du projet.

La profondeur de champ que pourrait offrir une maquette 3D est également très

importante dans cette profession pour montrer les ouvertures sur l’horizon, les alignements et

perspectives offertes sur un futur projet.


21

En termes de contenu d’une maquette numérique, les attentes des 3 professions se

recoupent un peu. Ce sont les paysagistes qui ont particulièrement besoin de la végétation pour

leurs travaux. Le mobilier urbain également, qui a fait l’objet d’un PFE en 2010 (Vannes[2010]),

intéresse beaucoup les paysagistes ou architectes afin d’habiller leurs maquettes et leur donner

de la vie. Un projet de création d’une bibliothèque de symboles 3D de tous les éléments urbains

du Canton de Genève est en cours au sein du SEMO.

3.2.3. Création d’une équipe de travail

Une équipe de coordination a été créée avec des représentants de toutes les professions

citées ci-dessus et également de l’AGG1. Cette équipe s’est réunie une fois par mois afin de suivre

l’évolution du projet, d’en fixer les objectifs, de valider les choix effectués et les orientations

suivies. Elle se composait de :

Mme Myriam PIGUET (Urbaniste DCTI2)

M. Hervé FOURNIER (Architecte : cabinet Brodbeck-Roulet)

M. Sacha KORTUS (Architecte : cabinet Brodbeck-Roulet)

M. Darius GOLCHAN (Architecte urbaniste : cabinet Golchan)

M. Franck BODENMANN (Paysagiste : Cabinet Henchoz)

M. Christian HALLER (Géomètre expert : Bureau d’étude Christian Haller)

M. Gérard-André KOHLER (Géomètre expert : Cabinet HKD Géomatique)

M. Laurent NIGGELER (Directeur SEMO)

M. Geoffrey CORNETTE (Adjoint de direction SEMO)

M. Cédric MINERY (Stagiaire SEMO en charge du projet)

D’autres personnes ont également participé { certaines de ces réunions, comme M. Thierry

SANGOUARD, qui a remplacé M. HALLER ponctuellement, ou M. Fréderic PITTALA, remplaçant

de M. GOLCHAN.

L’avantage principal de cette équipe est qu’elle était vraiment pluridisciplinaire et qu’il

était ainsi possible de confronter les attentes de chacun et de ne négliger aucun aspect. Les

résultats obtenus étaient présentés mensuellement et les discussions qui en résultaient étaient

très constructives et permettaient de savoir si le projet avançait bien dans la bonne direction.

3.3. Synthèse des attentes et solution envisagée

3.3.1. Aspect technique

Nous pouvons donc résumer les points importants qui ont été abordés et qui devront être

pris en compte dans la solution proposée :

L’interopérabilité :

C’est véritablement le fil rouge du projet, tant il existe de formats 3D et de logiciels

différents. On ne peut contraindre personne à utiliser tel ou tel logiciel, qui aurait été jugé

subjectivement optimal, il faut que la solution choisie puisse être appliquée quel que soit l’outil

1 Association des Géomètres Genevois 2 Département des Constructions et des Technologies de l’Information


22

de travail de l’utilisateur. Il s’agira donc de recenser les principaux logiciels utilisés sur le Canton

et de proposer les formats de livraison qui permettront de satisfaire un maximum d’utilisateurs.

Le géoréférencement :

Comme nous l’avons mentionné plus haut, livrer des données dans des systèmes de

coordonnées nationaux en centaines de milliers de mètres n’est pas efficient pour les travaux

des utilisateurs, dans la mesure où beaucoup de logiciels ne gèrent les coordonnées qu’en simple

précision.

Afin de satisfaire les besoins des architectes mais également ceux des urbanistes sur ce

point, une transformation unique devra être définie, pour ramener les données proches de

l’origine, mais tout en conservant une trace du géoréférencement et pouvoir ramener aisément

les données dans un système national.

La profondeur de champ :

Il faudra créer une « couronne d’horizon » qui comprendra les principales montagnes

visibles depuis Genève, ainsi que le lac Léman. En insérant une maquette plus réduite dans cette

maquette « région », on pourra voir les panoramas et perspectives offertes depuis tel ou tel

endroit. Cette couronne d’horizon devra être numériquement la plus légère possible, car le poids

limité des données 3D que l’on peut gérer dans les différents logiciels est également un

problème récurrent chez les personnes interrogées.

Le Modèle Numérique de Terrain :

Il s’agit du terrain dans la zone d’intérêt du projet, aux alentours d’un futur bâtiment par

exemple. Comme nous l’avons dit précédemment, une des attentes principales des personnes

interrogées vis-à-vis d’une maquette 3D est de pouvoir réaliser des vues piétonnes, avoir une

perspective humaine depuis la rue. Il faudra pouvoir présenter un projet tel qu’on le verra

effectivement lorsqu’il sera réalisé, avec son impact visuel concret, et pas seulement depuis des

vues aériennes ou des survols. Pour cela, le MNT actuel n’est pas suffisant, il faudrait les routes,

avec les décrochés des trottoirs, les îlots de circulation, ce qui implique de créer un nombre

important de lignes de ruptures (haut et bas de trottoirs, ilots, etc…). Enfin, pour pouvoir

plaquer une orthophoto dessus efficacement, le tout devra avoir un rendu lisse et propre

visuellement.

Pour obtenir une telle surface représentant la rue, avec autant de lignes de ruptures, il

semblerait indispensable d’aller sur le terrain pour faire des levers, ce qui n’est pas le but du

projet. Ainsi, il faudra essayer de traiter les données disponibles au SEMO afin d’obtenir ce que

nous voulons. En effet, tout le domaine routier du Canton de Genève est connu en 2D, avec les

positions des chaussées, trottoirs et îlots notamment. Nous disposons également des nuages de

points Lidar bruts qui pourraient fournir la composante Z manquante. C’est une technique qui a

été abordée rapidement par Adrien Vieira de Melo dans son rapport VieiraDeMelo[2006].

Le contenu de la maquette :

Il est important pour les créateurs de maquettes numériques de pouvoir leur donner de la

vie, de les habiller pour les rendre plus attractives et plus vendeuses. Toutes les données du

Canton de Genève sur le mobilier urbain et la végétation sont connues en 2D avec des attributs

descriptifs.


23

3.3.2. Aspect administratif

Un autre aspect du problème a été rapidement évoqué lors des séances avec l’équipe de

travail, celui de comprendre pourquoi les professionnels de la construction ne ressentaient pas

la nécessité ou le besoin de se former et d’utiliser la technologie 3D. En effet, les difficultés

techniques, inhérentes à toute nouvelle technologie, ne suffisent pas à expliquer que les

architectes et autres professionnels hésitent { s’investir dans cette technique, dont les avantages

semblent souvent évidents (ces avantages sont détaillés sur la fiche d’information en annexe 6,

également rédigée durant ce stage et dont nous parlerons plus en détail au §6.3.1.).

Il est finalement ressorti de ces discussions que les architectes ne bénéficiaient d’aucuns

avantages concrets à réaliser des maquettes numériques actuellement, hormis la valeur ajoutée

visuelle. Aussi, ces avantages concrets pourraient être d’ordre administratif, comme des

simplifications de dossiers ou de procédures, qui pourraient compenser le temps investit à la

création d’une maquette tridimensionnelle complète. On peut penser aux concours

d’architecture où la création d’une maquette numérique n’est pas officiellement récompensée.

Des pistes de réflexions devront être étudiées et des documents de publicité et d’information

devront être rédigés et diffusés afin de valoriser l’utilisation de la 3D, d’en vanter les avantages

et d’en motiver l’utilisation sur le Canton de Genève.

La définition du besoin ayant permis d’extraire les différents points problématiques qu’il

faudra traiter, nous allons maintenant nous pencher sur la façon dont ces différents problèmes

ont été résolus et les solutions qui ont été développées.

Récapitulatif de la partie III :

Cette partie concernait la définition du besoin et a consistée à rencontrer beaucoup de

personnes, représentatives de chaque profession afin de recenser leurs attentes et difficultés et

de définir clairement les objectifs { atteindre en termes de forme et de contenu d’une maquette

numérique tridimensionnelle.

Les points principaux qui ont été retenus et qui devront être traités sont :

L’interopérabilité entre les multiples logiciels éxistants.

Le géoréferencement des données, qui devront être fournies dans un système de

coordonnées moins contraignant pour les différents utilisateurs, mais qu’on devra

pouvoir rebasculer aisément en coordonnées nationales.

Le contenu de la maquette. En plus des traditionnels survols, la maquette numérique doit

permettre de proposer une perspective humaine, avec des vues piétonnes au niveau du

sol notamment, ce qui n’est pas possible avec le MNT actuellement proposé.

La profondeur de champ est souvent réduite, alors que les vues et perspectives sur

l’horizon sont très importantes dans l’élaboration d’un projet. Un problème de quantité

et de poids de données supporté par les différents logiciels entre ainsi en jeu par la

même occasion.

Le mobilier urbain ainsi que la végétation permettraient d’habiller la maquette et de lui

donner de la vie.

En plus de ces différents aspects purement techniques, il est également ressorti qu’une

recherche au niveau des avantages administratifs concrets dont pourraient bénéficier les

futurs utilisateurs serait également propice à un engouement naturel autour de cette

technologie.


24

IV. MISE EN ŒUVRE ET REALISATIONS

4.1. Prototype initial

Pour répondre aux différents problèmes cités ci-dessus, un prototype de maquette à

différents niveaux de détails a été imaginé. Initialement, 3 zones était envisagées comme le

montre le schéma ci-dessous (cf Figure 17):

La zone 1 represente l’environnement direct du projet, le niveau de détail doit donc y être

élevé. Les bâtiments 3D sont au niveau de détail maximum et le terrain est composé du « Modèle

Numérique de Rue (MNR) » drapé d’une orthophoto { haute résolution (voir § 4.3.1). La zone 3,

aussi appelée zone région, est la couronne d’horizon permettant de replacer n’importe quel

projet dans son environnement global. Elle est composée d’un MNT qui a été allégé, c'est-à-dire

que le raster a été filtré et réechantilloné pour être le plus léger possible. L’image satellite

drapée dessus a également subit un réechantillonage afin d’économiser de la mémoire

informatique.

La zone 2 est une couronne entourant la zone 1 et qui permet d’avoir une profondeur de

champ intermédiaire. Elle ne sera jamais affichée au premier plan et n’a donc pas besoin d’être

détaillée. Son utilité est de faire le lien entre les deux zones extrèmes afin de ne pas avoir une

transition trop brusque, comme nous pouvons par exemple le voir sur la Figure 3. Les

superstructures des bâtiments n’apparaissent pas. On pourrait même afficher seulement la

volumétrie des bâtiments en extrudant leurs bases selon l’attribut de hauteur maximale du

bâtiment. Le MNT est grossier et texturé avec une photo à basse résolution. La taille de cette

zone aurait pu être variable, en indiquant une distance de corridor autour de la zone 1, par

exemple 2 ou 3 kilomètres, mais par la suite il a plutôt été décidé d’en faire une zone ville unique

commune à tous les projets comme le montre la Figure 18.

Cette même Figure 18 ci-dessous montre la composition du prototype de maquette

initialement envisagée, avec le MNR (zone 1) venant s’insérer dans la zone ville, qui vient elle-

même s’insérer dans la zone région. L’intérêt est que l’on est pas toujours obligé d’afficher ou

d’utiliser l’ensemble des 3 zones en fonction des utilisations que l’on a de la maquette (vues

aériennes, survols, vues piétonnes…).

Figure 17 | Schéma du prototype en 3 zones


25

Seulement, { l’usage, nous nous sommes rendu compte qu’il était très rare d’avoir besoin

de la zone ville sans la zone région et qu’une division en 2 zones serait suffisante et plus

pratique. Les zones 2 et 3 ont donc été rassemblées en une seule zone région. La zone 1, ou zone

projet, a ensuite été appelée le « socle urbain 3D » dans lequel on peut travailler en détail

indépendamment et que l’on peut ensuite insérer dans la zone région par opération booléenne.

4.2. Zone région

4.2.1. MNT

Comme nous l’avons déj{ vu plus haut, afin de pouvoir proposer une grande profondeur

de champ tout en conservant une fluidité dans la navigation, il faut dégrader le niveau de détail,

de contenu et de définition des objets au fur et { mesure que l’on s’éloigne du centre d’intérêt de

la maquette. C’est une technique qui est couramment utilisée, et notamment dans les jeux vidéo

afin de plonger le joueur dans des environnements de plus en plus détaillés et vastes à la fois.

4.2.1.1. Découpage du MNT

La première tache a été de définir l’étendue de cette zone région. En effet nous disposons

au SEMO du raster de l’IGN de la zone frontalière « étendue » de Genève à une résolution de 1m

(cf Figure 19). En revanche nous ne disposons que d’une image satellite (résolution : 5m) de la

région de Genève et de ses environs français proches, comme nous le voyons également sur la

Figure 19 ci dessous.

Figure 18 | Composition du prototype en 3 zones initial

Figure 19 | MNT raster de la région étendue de Genève et emprise de l’image satellite correspondante


26

Après avoir découpé le raster selon l’emprise de la photo, des analyses de visibilité et

d’orientation de pentes ont été réalisées afin de définir les endroits qui ne seraient jamais

visibles depuis Genève et qui n’auraient donc pas d’utilité { figurer dans la maquette. Le but est

toujours d’économiser de la mémoire en diminuant la surface { représenter. Pour l’analyse de

visibilité dans ArcGIS, un point situé 200 m au dessus de la rade de Genève a été créé pour servir

de point de vue limite. La carte obtenue a bien validé ce qui semblait évident : les terrains

derrière les crêtes du Jura et du Mont Salève ne sont pas visibles et pourraient donc être

découpés du MNT. En revanche, on remarque que le prolongement dans la vallée blanche est

bien visible et que l’on peut même voir le Mont Blanc dans un certain alignement.

L’analyse d’orientation nous a permis de définir précisément ces fameuses crêtes sur les

montagnes environnantes comme nous le montre le résultat ci-dessous (cf Figure 20). Cette

analyse donne l’orientation de chaque pixel en fonction de ses 8 voisins directs. Un changement

global de direction indique donc une crête.

Le MNT a donc été un peu redécoupé en enlevant la zone au Sud du Mont Salève

notamment, mais ces ajustement ne se ressentent que très peu dans le poids des données finales,

par rapport à la découpe principale selon l’emprise de la photo.

4.2.1.2. Filtrage du MNT

Il a ensuite été nécessaire de diminuer le nombre de points de l’échantillon du MNT

conservé afin de le rendre encore plus léger et utilisable, tout en conservant la qualité de

modélisation du terrain. Pour cela, le logiciel Rhino a été utilisé, tout d’abord parce qu’il est

capable de gérer de grandes quantités de données et notamment des nuages de points denses.

Ensuite, son applicatif RhinoTerrain est capable d’importer des données SIG et notamment des

fichiers de points ASCII. Aussi, le MNT raster de la zone étendue a été transformé en nuage de

points en associant à chaque cellule un point de même élévation à son centre. De plus,

RhinoTerrain possède un outil de décimation intelligente de nuage de points qui permet de ne

conserver que les points intéressants d’un échantillon.

Cet outil fonctionne de manière récursive. Pour chaque point, le logiciel calcule le plan

moyen passant par ses voisins directs (identifiés grâce à un diagramme de Voronoï) puis la

distance orthogonale du point à ce plan. Si cette distance est grande, cela veut dire que le point

est intéressant pour la représentation du terrain. En revanche si cette distance tend vers zéro,

c’est que les points voisins seuls suffisent à représenter le terrain et que ce point peut être

supprimé. Une tolérance arbitraire est attribuée à partir de laquelle on conserve ou non les

Figure 20| Analyse de direction du MNT et crêtes ainsi détectées


27

points. Il est possible d’appliquer le processus plusieurs fois sur un même nuage de points pour

le décimer autant que l’on veut en fonction de l’utilité que l’on aura du terrain et du niveau de

représentation que l’on souhaite.

Sur la Figure 21 ci-dessous, nous voyons le résultat obtenu après décimation et maillage

du terrain dans Rhino. Sur cette image, le MNT n’a pas encore été découpé selon l’emprise de la

photo. Il y a la même étendue que sur le raster de la Figure 19, mais le logiciel reste fluide et

permet de travailler de façon efficace. En effet, un autre avantage du logiciel Rhino est que celui-

ci s’adapte à la configuration de la machine sur laquelle il est installé pour toujours optimiser les

ressources et être le plus performant possible. Installé sur une station de travail puissante, il

offre des possibilités impressionnantes en termes d’affichage de grandes quantités de données

et de temps de calculs.

Le terrain peut ensuite être simplement découpé par opérations booléennes ou grâce à

des outils de suppression de triangles. On peut également facilement le draper avec l’image

satellite correspondante en sélectionnant simplement le fichier de géoréférencement de l’image

correspondante. Si le terrain et l’image sont correctement géoréférencés, le logiciel drape

automatiquement l’image au bon endroit. L’image peut avoir été rééchantillonnée avant cette

opération, encore pour économiser de la mémoire. Le §4.4.2 s’intéresse plus en détails aux

différents traitements appliqués sur les photos aériennes et images satellites.

Finalement, voici la zone région finale texturée dans Rhino (cf Figure 22). Une nouvelle

fois, malgré l’étendue du terrain affiché et la bonne résolution de l’image appliquée (taille du

pixel au sol : 5m), la navigation dans le logiciel reste fluide et efficace.

Figure 21 | Aperçu du terrain global après décimation et maillage

Figure 22 | Modèle numérique de Terrain texturé de la zone région finale


28

4.2.2. Bâtiments

La problématique des bâtiments de la zone région repose une nouvelle fois sur le poids et

la quantité de données qu’il est possible d’importer dans les différents logiciels. Le Canton de

Genève comprend 76 000 bâtiments modélisés en 3D. Bien que certains logiciels installés sur

des machines puissantes puissent gérer l’intégralité de ces bâtiments en même temps sur un

terrain texturé, l’utilité d’afficher tout le Canton parait relativement rare. Il a donc s’agit

d’explorer les différentes pistes possibles pour diminuer le poids de ces données.

4.2.2.1. Bâtiments 3D allégés

Tout d’abord, grâce { la structure du bâti 3D, il est possible de créer les bâtiments sans les

superstructures. En effet, le cahier des charges de modélisation des bâtiments précise que les

toitures principales ne doivent pas présenter de trous aux emplacements des superstructures.

On peut donc les utiliser sans tous ces détails architecturaux qui alourdissent les données de

manière conséquente et qui sont imperceptibles lorsqu’on s’éloigne de ces bâtiments. La base

horizontale des bâtiments n’est également pas indispensable dans un seul but de visualisation.

Le script FME ci-dessous (cf Figure 23) montre l’algorithme très simple pour rassembler

seulement les façades et toitures principales en entités uniques dans le format *.3ds par

exemple.

Bien que le §4.5.3 traite exclusivement du poids des données, il semble important

d’illustrer immédiatement le gain réalisé par cette étape. Tous les bâtiments complets du Canton

au format *.3ds ont un poids de 263 Mo. Le fichier *.3ds créé avec l’algorithme FME ci-dessus ne

fait plus que 152 Mo, soit un gain de poids de plus de 40%.

Voici un aperçu de l’import de tous les bâtiments allégés au format *.3ds dans la zone

région dans Rhino (cf Figure 24) .

Figure 23 | Algorithme FME pour rassembler les façades et toitures principales des bâtiments 3D

Figure 24 | Import de l'ensemble des bâtiments allégés dans la zone région


29

Une fois que nous avons cette nouvelle couche de bâtiments allégés, il faudrait

théoriquement n’afficher que les bâtiments qui seront visibles dans les vues qu’utiliserons les

architectes. Ainsi pour une vue bien définie, on pourrait penser à une « extraction

directionnelle » selon un cône de vue défini. Seulement, on ne présente jamais un projet depuis

un seul point de vue, et même avec seulement deux points de vue, ceux-ci seront presque

toujours opposés et nécessiteront donc quand même tout le bâti.

De la même façon, une distance d’extraction autour du centre d’un projet n’a pas pu être

déterminée arbitrairement pour avoir un résultat optimal dans toutes les situations. Il en est

donc ressorti qu’une sélection manuelle des bâtiments { conserver pour habiller l’arrière plan

serait indispensable. On livrerait donc plutôt tout les bâtiments du Canton en version allégée et

ce serait { l’utilisateur ensuite de supprimer les bâtiments qui n’ont aucune utilité ou bien de

créer des calques pour ranger ces bâtis 3D et les masquer/afficher en fonction des besoins. En

effet, grâce au prototype de maquette à deux zones, on peut travailler dans le socle urbain 3D en

détail sans afficher la zone région, choisir les angles de vues et n’afficher qu’ensuite l’horizon,

uniquement lorsqu’on en a besoin.

4.2.2.2. Bâti intégré au MNT

Pour faire de la navigation en temps réel dans l’environnement complet de la région de

Genève, il faudra forcément être équipé d’ordinateurs puissants afin de gérer toutes les données

en même temps. D’autres tests ont tout de même été réalisés pour essayer d’intégrer la

volumétrie des bâtiments directement dans le MNT de la région. Pour cela, un script ArcGIS a été

réalisé, grâce à un « modelbuilder », outil permettant de créer des processus sous la forme

d’enchainements de fonctions de la boîte { outils ArcGIS. Le principe de ce script est

relativement simple et sera illustré sur une petite zone test. Le TIN du terrain sans les bâtiments

est créé de la même manière qu’expliqué dans le §4.2.1 précédent et conservé à part. On créé

ensuite le contour des toitures principales avec l’outil « MultiPatch footprint1 ». On fabrique un

corridor de quelques centimètres autour de ces empreintes des toitures avec l’outil « buffer » en

prenant garde { cocher l’option pour dissoudre tous les corridors qui se chevauchent en un seul

corridor extérieur. On projette ensuite ces corridors sur le MNT initial afin de leurs donner

l’altitude au niveau du sol. Entretemps, il aura fallu utiliser FME pour transformer la couche

MultiPatch des toitures en polygones 3D que l’on peut utiliser pour éditer un TIN dans ArcGIS. Il

ne reste alors plus qu’{ éditer justement le TIN initial du terrain. Les corridors des bâtiments

sont ajoutés en tant que lignes de ruptures rigides tandis que les polygones 3D des toitures sont

insérés en « remplacements rigides ». La Figure 25 ci-dessous montre les polygones 3D des

toitures et le terrain comprenant les bâtiments correspondant réalisé avec la technique

expliquée ci-dessus :

1 Empreinte des MultiPatch

Figure 25 | Insertion de la volumétrie des bâtiments dans la maille du terrain.


30

Cette technique est intéressante

dans la théorie mais elle se confronte

néanmoins à un problème majeur. La

zone région est vouée à être drapée avec

une image satellite à basse résolution (les

pixels feront au mieux 5m au sol), ce qui

donne des résultats inutilisables en

pratique comme l’illustre l’exemple ci-

contre (cf Figure 26). Cette technique ne

sera donc pas utilisée dans ce projet mais

pourrait avoir d’autres utilités comme des

analyses de visibilités en milieu urbain,

les outils ArcGIS ne pouvant pas utiliser

les objets MultiPatch comme masques.

4.2.2.3. Astuce de triangulation des faces verticales

Lors de la création des empreintes des bâtiments vue au §4.2.2.2 ci-dessus, l’intérêt

d’avoir créé un petit corridor pour les lignes de ruptures des bas des façades est de contourner

le problème récurent à tous les logiciels servant { mailler des surfaces, { savoir qu’il n’est pas

possible de trianguler verticalement. En effet, la triangulation de Delaunay, à la base de tous les

TIN, projette tout d’abord l’échantillon de points sur un plan de référence pour définir les

relations de voisinage des points afin de les trianguler. Il est donc impossible d’avoir plusieurs

points ayant des coordonnées planimétriques identiques mais des altimétries différentes, car

l’algorithme ne saurait pas quel point relier en premier. En créant un léger fruit imperceptible

dans les murs ou surfaces supposées verticales, on contourne ce problème. Cette technique sera

réutilisée à plusieurs reprises dans la suite du projet.

4.3. Zone projet

Nous allons maintenant aborder la zone projet, également appelé le socle urbain 3D et qui

est donc la zone d’intérêt d’une maquette, l{ où l’utilisateur créera son projet et qui sera ensuite

insérée dans la zone région par opération booléenne. Contrairement { la zone région, elle n’est

pas commune à tous les projets et devra être créée pour chaque nouveau projet. Aussi, sa

création ne peut pas être complètement manuelle mais doit être facilitée par des scripts et

processus automatisés. Seulement, comme nous le verrons plus tard, des préparations de

données et un contrôle humain avant livraison resteront indispensables. L’étendue de cette zone

est réduite afin de pouvoir y mettre beaucoup de détails (500x500m par exemple), mais sa

forme doit pouvoir être choisie pour certains travaux spécifiques, notamment une forme linéaire

pour des travaux d’infrastructures de transport (aménagement du TRAM dans un boulevard par

exemple).

4.3.1. Modèle Numérique de Rue (MNR)

Afin de répondre aux problèmes relatifs au terrain de la zone projet recensés pendant

l’analyse du besoin, il a été nécessaire de réaliser une surface dérivée du MNT du Canton qui

réponde aux attentes des utilisateurs, à savoir pouvoir se balader au niveau du sol en ayant un

Figure 26 | Exemple de texturisation du MNT comprenant les bâtiments.


31

rendu crédible. A ce niveau, l’exactitude géométrique n’est de loin pas une priorité pour la

plupart des utilisateurs, comparée { l’aspect visuel, qui lui est primordial. Il faudra donc par la

suite vérifier si des images réalisées avec une telle surface peuvent être qualifiées de « 3DOK ».

Cette surface sera par la suite appelée le « Modèle Numérique de Rue (MNR)» et son

fonctionnement est explicité ci dessous.

4.3.1.1. Présentation et utilisation de l’outil MNR_auto

Ce MNR est obtenu grâce à un processus automatisé complexe qui a été développé dans

des « modelbuilder » de ArcGIS, de la même façon que le script au §4.2.2.2. Cet outil permettant

de créer un MNR a été appelé « MNR_auto ». La Figure 27 ci-dessous montre l’arborescence de

cet outil dans le logiciel ArcCatalog.

Pour créer un MNR grâce à cet outil, il faut tout d’abord copier le répertoire brut

« MNR_auto », composé des dossiers qui accueilleront les entrées du programme, les données

intermédiaires, les sorties et la boîte à outils. On copie ensuite les entrées correspondantes à la

zone que l’on veut modéliser dans le bon dossier. Ces entrées sont illustrées sur la Figure 28 ci

dessous:

Le nuage de points Lidar du MNT

Les bases des bâtiments 3D

La couche du domaine routier en 2D

L’avantage de Genève est que toutes les données relatives à la mensuration sont

centralisées au SEMO et que nous pouvons donc avoir accès à ces données directement pour

n’importe quelle zone du Canton.

Dans les différentes étapes de l’outil créées, il a été important de préciser que les chemins

d’accès aux données doivent être stockés en relatif et non en absolu, afin de pouvoir partager

l’outil sur différents ordinateurs et dans différents dossiers. Ainsi, le programme va chercher les

entrées dans le dossier où il est enregistré et aucune erreur n’est possible.

Figure 28 | Entrées du processus

Figure 27 | Arborescence de l’outil MNR_auto dans ArcCatalog


32

Il ne reste plus qu’{ lancer les différents outils 1.MNR, 2.MNR, … dans l’ordre

chronologique. Toutes les données créées sont stockées dans le répertoire « 2.intermédiaires »

sauf les résultats finaux qui sont enregistrés dans le dossier des sorties. Certains points clés du

processus seront explicités plus en détails au §4.3.1.5 sur les limites du MNR. Sur l’image Figure

29 ci-dessous, nous voyons la fenêtre de lancement de la première étape du processus où il est

demandé de sélectionner la couche du domaine routier en entrée.

Le processus de création d’un MNR sur une zone urbaine d’environ 25 ha prend environ

13 minutes ce qui est relativement court compte tenu du nombre important d’outil ArcGIS qui

sont exécutés, à savoir une soixantaine, dont des interpolations ou des calculs sur raster de

bonne résolution (taille d’une cellule : 10x10cm) qui sont des opérations relativement coûteuses

en termes de temps de calcul.

4.3.1.2. Fonctionnement du programme

Nous allons maintenant expliquer brièvement le principe global du programme. Pour cela,

nous allons nous baser sur le découpage initial du processus, qui comprend 13 sous-parties

comme le montre l’arborescence ci-dessous (cf Figure 30: initialement l’outil s’appelait

« MNT_auto »). Chaque partie porte dans son intitulé le nom de l’outil ArcGIS principal qu’il

exécute et cette division permettait de mieux contrôler les résultats étapes par étapes lors du

développement de l’outil. L’outil final en 4 étapes présenté sur la Figure 27 reprend à peu près

les mêmes géotraitements en les regroupant dans la mesure du possible. Les noms des

différentes fonctions ArcGIS utilisées sont majoritairement en anglais car le projet s’est déroulé

sur une version anglaise du logiciel. Vous trouverez en annexe 6 un aperçu global du script

développé dans le modelbuilder.

Modèle 11 : grâce { l’outil « split », on divise le domaine routier en ses éléments individuels

selon le champ « objet » de la table attributaire : chaussée, trottoirs, ilots…

Figure 30 | Division initiale du programme MNT_auto

Figure 29 | Fenêtre de lancement de l’outil 1.MNR


33

Modèle 12 : on interpole les points Lidar par l’inverse des distances pondéréees1 afin

d’obtenir un MNT raster de la zone, auquel on applique une série de filtres passe-bas afin de

le lisser, puis on le convertit en TIN. On stocke une copie de ce TIN dans les sorties

(12_tin_final) que l’on éditera { la fin du processus.

Modèle 13 : l’outil « aggregates » sert à transformer les éléments du domaine routier en

polygones fermés uniques, ce qui facilitera les opérations suivantes (corridors, découpages,

etc…).

Modèle 14 : on crée des MNT raster individuels pour chaque élément du domaine routier

qu’on lisse de la même manière que le MNT de l’étape 12. Pour découper ces MNT individuels,

on utilise l’outil « Extract by Mask » avec comme masques les polygones uniques créés à

l’étape 13.

Modèle 15 : il sert à trouver les intersections entre les contours des différents éléments du

domaine routier (par exemple entre la chaussée et les trottoirs la bordant). Ces lignes

d’intersections serviront plus tard { créer les lignes de ruptures modélisant le terrain.

Modèle 16 : on crée les corridors autour des éléments routiers qui devront présenter des

murs théoriquement verticaux. C’est la même astuce de création de faces verticales dans un

TIN expliquée au § 4.2.2.3.

Modèle 17: il sert { créer l’emprise des bâtiments dans le MNR sous forme de socles. Pour

cela, plusieurs lignes de ruptures sont créées au niveau de la base des bâtiments et de

l’intersection du TIN initial avec les façades des bâtiments. L’intérêt de cette étape sera

détaillé au § 4.3.1.4.

Modèle 18 : on projette les lignes de ruptures sur les MNT individuels afin de leur donner

leurs élévations respectives. Dans la version 9.3 de ArcGIS, il fallait utiliser la fonction

« Features to 3D » de la barre d’outils 3Danalyst, qu’on ne pouvait malheureusement pas

intégrer dans un « modelbuilder » et cette étape n’était donc pas complètement automatisée.

Dans la version 10 que nous avons reçue au cours du projet, le nouvel outil « Interpolate

shape » permet de faire la même opération depuis une boîte à outil et cette étape peut donc

dorénavant être automatisée. De plus, des paramètres supplémentaires ont été ajoutés, on

peut donc notamment choisir la méthode de projection. C’est la méthode dite des « voisins

naturels » qui offre les meilleurs résultats dans la mesure où les lignes, en plus d’être

projetées en 3D, subissent un nouveau lissage qui améliore encore le rendu. En effet, le

problème du lissage 3D des lignes de ruptures a été le point le plus critique, car il est

important de lisser l’altimétrie mais pas la planimétrie des lignes qui est considérée exacte.

Modèle 19 : on transforme les lignes de ruptures fermées des ilots en objets surfaciques

uniques qui serviront également à éditer le TIN final.

Modèle 20 : avec la création des corridors { l’étape 16, on obtient pour chaque trottoir une

ligne de haut et une ligne de bas de trottoir qui sont toutes les deux projetées sur la même

surface { l’étape 18. L’étape 20 sert maintenant { ajuster l’élévation des lignes de hauts de

trottoirs en leur ajoutant la valeur arbitraire de 15 cm, jugée moyenne sur le Canton de

Genève. On réalise la même chose avec les ilots qui sont élevés de 25 cm par rapport à la

route et de 10 cm par rapport aux trottoirs.

Modèle 21 : il permet d’éditer le TIN final stocké dans les sorties avec les lignes de ruptures

rigides et surfaces générées précédemment.

Modèles 22 et 23 : ces deux étapes servent simplement à nettoyer ce TIN final en le

redécoupant selon son emprise initiale et en supprimant les points parasites. Pour cette

1 IDW : « Inverse Distance Weighted » en anglais


34

dernière tache, on utilise les outils ArcGIS qui permettent d’extraire les sommets des triangles

du TIN comme nuage de point et les lignes de ruptures qui le constituent. On peut ensuite

nettoyer ce nuage de points en supprimant premièrement tous les points qui se superposent

avec les lignes de ruptures et également ceux qui sont { l’intérieur des polygones des routes

ou des trottoirs par exemple, le tout grâce à l’outil « erase point ». Cette étape peut paraitre un

peu redondante, mais elle améliore tout de même nettement les résultats et permet de

supprimer quelques problèmes ponctuels avec certains points parasites qui pourraient

passer au travers des différents lissages et filtrages.

4.3.1.3. Résultats

La Figure 31 ci-dessous illustre l’évolution entre le TIN initial (qui est quand même déj{

lissé) et le MNR obtenu après application du processus. Mais c’est en se rapprochant du niveau

du sol comme sur la Figure 32 que l’on se rend réellement compte de l’importance des

changements et de l’amélioration visuelle obtenue. Le MNT de gauche a été obtenu en

triangulant directement le nuage de point Lidar brut utilisé en entrée.

4.3.1.4. Avantages du MNR

Figure 31 | Illustration des différences MNT/MNR

Figure 32 | Différence entre le nuage de points Lidar triangulé (à gauche) et le MNR avec une perspective au niveau du sol (à droite)

Figure 33 | Schéma du socle des bâtiments 3D du MNR

Tout d’abord, le MNR comprend les

emprises des bâtiments sous la forme de

socles, dans lesquels les bâtiments 3D viennent

s’insérer comme l’illustre le schéma ci-

contre (cf Figure 33):


35

L’avantage de ces socles est de régler les problèmes d’intersections entre les façades des

bâtiments et le terrain qui les traversent habituellement. C’est surtout lors de l’export de ces

données vers des logiciels autres que ArcSCENE que l’on remarque ce problème, qui se

manifeste notamment par un désagréable scintillement des triangles concernés lors des

rotations de caméra.

Un autre avantage conséquent de l’outil MNR_auto est qu’il fournit également en sortie les

lignes et points constituants le TIN final. Cette spécificité est importante pour plusieurs raisons.

Tout d’abord, elle facilite l’interopérabilité du MNR avec les autres logiciels car le format TIN

d’ESRI n’est compatible avec aucun autre logiciel qu’ArcGIS. Même FME ne connait pas ce format,

ce qui ne facilite pas du tout son échange. En revanche, des lignes et des points sont exportables

dans n’importe quel format (*.shp, *.dxf, *.dwg, …) et peuvent être triangulés { nouveau

directement dans d’autres logiciels proposant cette opération. Cet aspect fera l’objet du §4.5.2.

De plus, l’objet TIN est difficilement éditable manuellement. Les outils d’édition 3D de

ArcGIS ne permettent pas de changer l’altitude d’un sommet du TIN, d’en supprimer d’autres ou

de redessiner une ligne de rupture par exemple, du moins pas de manière intuitive et rapide. Les

lignes et points sont en revanche des objets beaucoup plus facilement éditables, même

éventuellement dans d’autres logiciels comme AutoCAD étant donné qu’on vient de voir qu’ils

étaient facilement interopérables. Cette problématique d’édition du terrain et de correction

ponctuelle manuelle est importante dans la mesure où le MNR, étant créé { partir d’un processus

automatisé, peut toujours présenter certaines incohérence ou erreurs accidentelles

imprévisibles.

4.3.1.5. Limites du MNR

Tout d’abord, il faut bien noter que le MNR donne une idée de la rue, mais ne remplacera

jamais un levé de géomètre sur le terrain. Comme son nom l’indique, le MNR est un modèle de la

rue, et donc par définition une abstraction de la réalité qui sert à donner une vue très subjective

de cette réalité. Ici, l’aspect qui a voulu être mis en évidence est le réseau routier qui donne une

bonne idée de la circulation et des différents flux actuels et futurs qui sont des aspects

importants lors de la conception d’un projet.

Ainsi, le fait de surélever les trottoirs de manière arbitraire et de ne prendre en compte

que les routes, trottoirs et ilots implique d’obtenir un modèle simplifié de la rue, mais qui

constitue néanmoins une bonne base de départ à éditer et retravailler au cas par cas en fonction

des besoins. C’est pourquoi, le programme a été développé pour donner les lignes et points du

MNR comme expliqué au paragraphe précédent.

Cet aspect de modèle simplifié amène également à aborder la question de la précision

géométrique qui reste une priorité dans un travail de géomètre, même si l’utilisation du MNR est

destinée aux architectes, urbanistes ou paysagistes. Cette précision reste bien entendu relative

et sera abordée de plus près au §5.2.2. L’image ci-dessous (cf Figure 34) illustre l’effet des

différents lissages effectués sur les MNT raster individuels. On y voit la superposition du MNT

raster initial de la chaussée et du MNR. On remarque que la structure réelle de la route en forme

de toits implique que la route réelle est au dessus du MNR au centre et au dessous le long des

trottoirs. La route du MNR représente donc en quelque sorte un plan moyen de la route réelle.


36

Une autre limite du MNR provient du format choisi dans ArcGIS pour réaliser le processus

automatisé, à savoir le Shapefile. En effet, bien que les données de bases soient stockées dans des

Geodatabases, il a initialement été choisi de les exporter en Shapefile, format qui facilitait non

seulement l’écriture du script et l’arborescence des fichiers, mais surtout l’interopérabilité avec

le logiciel Rhino qui peut importer ce format directement grâce à son applicatif RhinoTerrain

(voir §4.5.2.2). Les avantages de ce format sont explicités dans le document ESRI

Shapefile@[1998], on y apprend qu’un format ne possédant pas de structure topologique

comme celui-ci est éditable plus facilement et plus rapidement. De plus, il requiert moins

d’espace disque qu’un format topologique comme le Géodatabase.

Malheureusement, nous nous sommes rendus compte que plus tard que ce format avait le

défaut de ne pouvoir comporter qu’un seul type d’entité géométrique et qu’une courbe stockée

en Géodatabase était exportée en Shapefile sous la forme d’une succession de petits segments, de

manière plutôt irrégulière. Ceci provoque des problèmes de topologies au niveau des

intersections des courbes des routes et des trottoirs par exemple, comme l’illustre la Figure 35

ci-dessous.

Une des étapes critiques du programme est celle où l’on trouve les intersections entre les

routes et les trottoirs, puis qu’on applique un corridor { cette ligne d’intersection. Ainsi, à cause

du problème du format Shapefile vu ci-dessus, ces lignes de routes et trottoirs mitoyens ne se

superposent pas exactement. Heureusement, l’outil d’intersection de ArcGIS permet d’entrer une

tolérance jusqu’{ laquelle deux lignes seront considérées superposées. Nous appellerons cette

tolérance D. Après avoir trouvé cette ligne d’intersection, on décale la ligne du trottoir vers

l’intérieur avec l’outil buffer pour créer une surface quasi-verticale dans le TIN (astuce de

modélisation vue au §4.2.2.3). On appellera cette distance de décalage B.

Si D et B ne sont pas ajustées l’une par rapport { l’autre, nous pouvons obtenir le problème

illustré sur le schéma de la Figure 36 ci-dessous, à savoir une intersection horizontale entre la

ligne du trottoir décalé et la ligne d’intersection, ce qui troublera la triangulation en TIN et

donnera des résultats non souhaités. On doit donc absolument éviter ces intersections et une

règle a été imposée dans l’utilisation de l’outil MNR_auto, celle de toujours utiliser une distance B

strictement supérieure à D (théoriquement, B supérieur à D/2 suffirait).

Figure 34 | Superposition du MNT raster initial de la route et du MNR

Figure 35 | Problème de topologie lors de l’export au format Shapefile


37

Dans l’outil MNR_auto, les paramètres par défaut choisis sont : D = 2 cm et B = 3 cm. Cela

reste très rare, mais il apparait que dans certaines zones où les données exportées en Shapefile

ont des topologies de moindres qualités que sur la moyenne du Canton, la tolérance D n’est pas

suffisante pour créer une intersection propre, et les problèmes s’enchainent au fur et { mesure

du processus. Il faut donc reprendre l’outil MNR_auto initial en 13 étapes pour modifier les

paramètres des différentes fonctions manuellement et vérifier les résultats, ce qui peut

rapidement être assez frustrant. La difficulté d’ajustement de paramètres illustrée ci-dessus

n’est en plus pas unique dans l’outil MNR_auto. Heureusement, ce problème est facilement

réparable en ajustant un peu l’outil MNR_auto. Nous verrons dans les perspectives de ce rapport

(cf §VII) que le processus automatisé peut aisément être amélioré pour travailler sur des

Géodatabase tout au long du processus et n’exporter que les sorties au format Shapefile.

4.3.2. Bâtiments

Pour les bâtiments de la zone projet, il y a beaucoup moins de choses à dire que pour ceux

de la zone région, puisqu’on les fournit simplement avec le niveau de détail maximum. Aussi il

faut bien faire attention à conserver deux bases de données distinctes, celle avec les bâtiments

complets, tels qu’ils ont été modélisés, et celle avec les bâtiments allégés, comme vu au §4.2.2.1.

Cependant, on peut maintenant évoquer un autre problème qui a été évoqué durant une

des séances avec l’équipe de travail : celui des textures. En effet, il est apparu que pour un public

amateur, un environnement géométrique 3D ne suffit pas forcément { s’orienter et { se

reconnaitre dans un lieu pourtant connu. Ces spectateurs ont souvent besoin de reconnaitre

« l’épicerie du coin » ou « les volets » de tel ou tel immeuble, ce qui n’est pas possible dans la

maquette virtuelle de Genève. Contrairement à la ville de Berlin présentée au §2.2.1.2 par

exemple, le SEMO n’a jamais souhaité texturer les bâtiments de son socle 3D, et ceci par choix.

En effet, la volonté du SEMO n’est pas de posséder une maquette qui servirait de vitrine

touristique de la ville, mais plutôt d’avoir un socle d’une grande cohérence géométrique

permettant des analyses ou simulations puissantes. Les textures des bâtiments ne sont donc pas

une priorité et ne pourront pas être fournies par le SEMO à court terme en tout cas. Ce serait

donc pour le moment aux utilisateurs de texturer eux-mêmes certains immeubles au cas par cas

en fonction des besoins. Pour cela, ils pourraient aller eux-mêmes prendre des clichés des

façades, les redresser et les appliquer sur les bâtiments dans leurs logiciels, ou le faire faire par

des sociétés spécialisées ou même des cabinets de géomètres experts.

Figure 36 | Illustration du problème d’intersection des lignes de ruptures et de la triangulation en résultant


38

4.4. Géotraitements complémentaires

4.4.1. Edition du Terrain

La possibilité de pouvoir aisément éditer et corriger manuellement le MNR était

indispensable. Cela a notamment été permis par la création des lignes et points du TIN comme

expliqué au §4.3.1.4. Dans un cas concret, un architecte pourrait passer par un géomètre pour

corriger ou compléter un MNR de base qui ne le satisferait pas complètement. Le géomètre se

rendrait alors sur le terrain avec un GPS ou n’importe quel appareil de mesure afin de lever les

points sur le terrain et compléter le MNR selon les souhaits de l’architecte. Voici quelques

exemples de corrections manuelles indispensables.

Tout d’abord nous voyons que lorsque nous rencontrons une descente de parking

souterrain, le mur extérieur est enregistré en tant qu’ « îlot », ce qui implique un décalage de 25

cm par rapport à la route (voir §4.3.1.2), au lieu des 3m environ en bas de la descente. L’outil

MNR_auto donne donc le résultat ci-dessous (cf Figure 37) sous forme de TIN dans ArcSCENE et

de lignes dans AutoCAD.

On peut alors redessiner la descente de parking manuellement. Ici, aucun lever sur le

terrain n’a été effectué, mais cet exemple sert simplement à montrer la possibilité d’édition. Les

lignes de rupture sont exportées en *.dwg dans AutoCAD, corrigées manuellement, puis

réimporté dans ArcGIS pour recréer un TIN corrigé (cf Figure 38).

Un autre exemple concerne un problème provenant du Lidar. Au moment de l’acquisition

du nuage de points, la rue présentée sur la Figure 39 ci-dessous était ouverte pour des travaux

de canalisations et le résultat du MNR est donc chaotique. On a donc simplement supprimé les

portions de lignes de ruptures en « dents de scie » pour les redessiner correctement et

trianguler le MNR à nouveau. La Figure 40 montre les anciennes lignes de ruptures (en rouges)

et les nouvelles (en bleues).

Figure 37 | Descente de parking avant édition

Figure 38| Descente de parking après édition


39

La photogrammétrie aérienne pourrait être une autre technique intéressante pour

corriger efficacement et rapidement des lignes de ruptures, d’autant plus que toutes les données

utiles sont disponibles au SEMO, à savoir les photos aériennes orientées et une station de

stéréorestitution puissante. Nous avons testé l’extension Erdas Terrain Editor pour ArcGIS. Celle-

ci devait théoriquement permettre d’éditer un TIN en temps réel avec la saisie de lignes de

ruptures { la volée. Malheureusement, le logiciel en version bêta dont nous disposions n’était

pas stable et l’ordinateur devait systématiquement être redémarré avant d’avoir pu saisir un

seul point. Cette technique ne sera donc pas plus développée dans ce rapport.

4.4.2. Photos aériennes et images satellites

4.4.2.1. Traitements

Figure 39 | Ruelle avant (à gauche) et après édition (à droite)

Figure 40 | Edition manuelle des lignes de ruptures

Figure 41 | Propriétés des images du SEMO

Les photos aériennes et images satellites qui

seront fournies aux utilisateurs pour draper soit la

zone région soit le MNR doivent également subir

plusieurs traitements afin de les rendre faciles

d’utilisation. En effet, les images brutes stockées au

SEMO, ne sont la plupart du temps pas utilisables telles

quelles dans les logiciels comme 3DStudioMax ou

ArchiCAD. Ci contre (cf Figure 41), vous pouvez voir un

aperçu des caractéristiques des orthophotos et images

satellites du SEMO dans ArcCatalog. On remarque que

les images sont composées de 4 bandes (PIR/RVB1)

encodées sur 8 bits/bande pour une profondeur de

pixel totale de 32 bits. De plus, les pixels sont codés en

entiers signés et les images sont pyramidées

automatiquement par le logiciel ArcGIS pour optimiser

la navigation dans les images.

1 Proche InfraRouge / Rouge Vert Bleu


40

Malheureusement, les logiciels des utilisateurs ne supportent pas ce paramétrage. Après

de nombreux tests, un paramétrage optimal a été trouvé qui permettait d’importer ces images

dans tous les logiciels testés par l’équipe de travail. Les images doivent être composées de 3

bandes encodées sur 8 bits/bande et en entiers non-signés ce qui donne une profondeur de

pixel de 24 bits. De plus, les images ne doivent pas être pyramidées. Et enfin, l’image satellite de

la zone région est stockée au SEMO avec une résolution de 5m. Cette image fait 470 Mo au

format TIFF, et peut être rééchantillonnée à 25 m par exemple pour économiser de la mémoire

(le résultat visuel sur la couronne d’horizon étant à peine altéré).

Nous allons maintenant voir les outils ArcGIS utilisés pour convertir ces images. Il faut

noter que ce logiciel construit par défaut toujours les pyramides des images dès qu’on leur

applique un traitement (rééchantillonnage, découpage, …). Aussi, pour chaque opération, il faut

bien veiller à cliquer sur le bouton « Environnement » de l’outil pour décocher la case « Build

pyramids » comme illustré ci-dessous (cf Figure 42) :

Il faut tout d’abord utiliser l’outil « Composite Bands » qui permet de recréer une image à

partir des bandes que l’on souhaite. La bande PIR n’est pas visible par l’œil humain sur une

image et ne sert qu’{ réaliser des analyses de télédétection. On ne garde donc que les trois

bandes RVB.

Ensuite, on exporte la nouvelle image depuis ArcCatalog en précisant

le type du pixel que l’on souhaite, { savoir des entiers en 8 bits non-signés

(cf Figure 43 ci contre).

Lors de cette étape, on peut également choisir d’exporter vers un

autre format que le TIFF comme par exemple le JPEG qui est un format

compressé qui allège donc les images. Ce format est en outre reconnu par

presque tous les logiciels de traitement d’images.

4.4.2.2. Géoréférencement

Qu’une photo soit enregistrée en TIFF ou en JPEG, les logiciels des utilisateurs ne gèrent

jamais son géoréférencement (ils ne lisent pas les fichiers *.tfw ou *.jgw). Aussi, afin de pouvoir

placer correctement les images par rapport aux différents MNT qui seront fournis, il a fallu créer

les cadres de ces photos dans le bon système de références (voir §4.5.1.2). Ces cadres, sous

formes de polylignes fermées ou de polygones, peuvent être convertis en n’importe quel format

d’échange (*.dxf, *.dwg…) et importés dans n’importe quel logiciel. Ensuite lorsqu’on importe

l’image, on peut la placer par son coin Sud-ouest et l’étirer jusqu’{ son coin Nord-est (cf Figure

44) avant de la projeter orthogonalement vers une surface, que ce soit le MNT de la zone région

ou le MNR de la zone projet.

Figure 42 | Construction des pyramides par défaut

Figure 43| Type du pixel


41

Il est également possible avec certains logiciels de calculer les coordonnées de textures sur

une surface et de les enregistrer dans l’objet. On pourrait se demander pourquoi on ne procède

pas de cette manière pour faciliter la livraison des terrains déjà texturés. La réponse provient de

la volonté des utilisateurs de pouvoir donner à leurs créations leurs propres touches artistiques

et donc de pouvoir retoucher la colorimétrie ou le contraste des images avant de les appliquer à

un terrain par exemple. On livre donc la photo brute séparément du MNT.

4.4.3. Habillage

L’habillage comprend tout ce qui viendra embellir le socle urbain 3D afin de rendre les

maquettes numériques plus crédibles ou immersives et de leurs donner de la vie. C’est donc

notamment le mobilier urbain et la végétation. On peut aussi penser aux piétons ou véhicules,

mais le SEMO n’est d’aucune utilité pour ces derniers.

Pour le mobilier urbain, toutes leurs positions et orientations sont connues en 2D dans les

couches du SITG et l’élaboration d’une bibliothèque de symboles 3D est en projet. Le projet de

fin d’études de Nathalie Vannes en 2010 portait sur ce sujet (Vannes[2010]). Elle concluait

qu’ « au niveau concept de la bibliothèque, l’étude des besoins de divers utilisateurs a permis de

définir les objets à modéliser en 3D […]. Quant { l’acquisition des modèles 3D, elle passera par le

gestionnaire de mobilier urbain, lui-même pouvant faire appel aux constructeurs ». Cette

bibliothèque pourra être fournie aux utilisateurs pour habiller leurs maquettes numériques avec

les symboles officiels des bancs, des poubelles, lampadaires ou feux tricolores notamment.

Pour la végétation, ca ne se passera pas exactement de la même façon étant donné qu’un

symbole d’arbre, même de la bonne espèce ne représentera jamais parfaitement la réalité. La

forme d’un arbre est une variable aléatoire contrairement au mobilier urbain qui se répète.

Ainsi, il serait plus judicieux de laisser les paysagistes, mais également les architectes et

urbanistes, utiliser leurs propres symboles. On ne leurs fournira donc que les positions 2D de ces

arbres isolés avec leurs tailles et espèces en attributs.

Les symboles d’arbres sont assez complexes, ils peuvent vite être très lourds

individuellement, comme le symbole de gauche sur la Figure 45 ci-dessous, où chaque feuille a

été modélisée. Ce symbole fait 1,6 Mo { lui tout seul, on s’en servira donc pour représenter un

arbre au premier plan, mais pas pour représenter une forêt par exemple. Le symbole de droite

vient de la bibliothèque d’arbres 3D ArcGIS. On remarque qu’il est composé de deux images

planes qui se croisent à 90°. Ce genre de symboles est très léger (seulement quelques Ko) et peut

servir { représenter un nombre important d’arbres réunis { l’arrière plan mais ne sera jamais

situé au premier plan d’une image de synthèse.

Figure 44 | Géoréférencement grâce au cadre de la photo

Cadre de l’image


42

Il existe une autre technique efficace pour représenter un nombre important d’arbres, et

qui est utilisée par les professeurs de l’HEPIA notamment. Elle a par exemple été utilisée pour

réaliser la maquette de la Figure 13. Il s’agit d’utiliser des « panneaux » (« billboards » en anglais)

sur lesquels sont plaqués des photos d’arbres et qui s’orientent toujours perpendiculairement à

la caméra, afin de toujours être observés de face.

Nous avons vus les différents géotraitements à appliquer aux données ainsi que les

compléments de données à fournir. Il nous reste à aborder le problème de l’interopérabilité, car

en effet, toutes ces données doivent pouvoir être exportées vers d’autres formats numériques et

logiciels afin d’être utilisées par les professionnels visés.

4.5. Echanges et interopérabilité

4.5.1. Paramètres d’échange

4.5.1.1. Formats numériques

Les formats principaux de livraison des données retenus par l’équipe de travail sont le

format Autodesk *.3ds, le WavefrontObject *.obj et le format Rhino *.3dm. Ces trois formats

permettent de fournir les données dans globalement tous les logiciels testés lors de ce projet, à

savoir ArchiCAD, 3DStudioMax, Rhino ou Blender…

D’autres formats ont été abordés lors des réunions, comme le Collada (*.dae) ou bien le

CityGML, mais ceux-ci n’ont finalement pas été retenus { l’usage. Ils pourront cependant toujours

être ajoutés aux formats de livraisons par la suite si le besoin s’en fait sentir. Le Collada permet

notamment d’exporter facilement vers le logiciel SketchUp, mais ce logiciel, malgré tous ses

avantages, montre tout de même rapidement ses limites en termes de quantités de données qu’il

peut gérer en même temps et de création de maquettes urbaines sophistiquées.

4.5.1.2. Changement de systèmes de référence

Le système de référence sur Genève était le système MN03 durant le projet. Il a été

abandonné juste à la fin du stage au profit du nouveau système national suisse, le MN95. Un

autre système arbitraire a été défini afin de livrer les données du Canton avec des coordonnées

moins élevées, le système MNGE, « GE » signifiant « Genève ». Dans ce rapport, les paramètres

permettant de passer au système MNGE sont donnés par rapport au système MN03. Le système

MNGE sera redéfini aisément après le passage au système MN95, la transformation MN03/MN95

se résumant à une translation de 1 million de mètres en X et de 2 millions en Y.

Figure 45 | Différences entre deux niveaux de représentation d’un arbre


43

Avant d’expliciter les paramètres de la transformation, nous allons d’abord illustrer les

problèmes provoqués par des coordonnées trop longues sur l’îlot d’un MNR dans le logiciel

SketchUp ( cf Figure 46). Nous avons choisi ce logiciel pour cet exemple car les changements y

sont flagrants. Les autres logiciels subissent les mêmes problèmes mais de manière moins

importante.

Le problème vient du nombre de chiffres significatifs supporté par les différents logiciels.

Si celui-ci est trop faible, des simplifications géométriques peuvent avoir lieu sur les petits objets

et donc notamment les petits triangles représentant des courbes.

L’origine du repère MNGE a été placée en France, au Sud-ouest du Canton de Genève, afin

que les coordonnées soient toujours positives. En effet, des coordonnées négatives peuvent

également perturber certains utilisateurs plus ou moins amateurs. Le Canton de Genève ne

faisant pas plus de 30 km que ce soit sur sa hauteur ou sur sa largeur, aucune coordonnée ne

dépassera les dizaines de kilomètres, ce qui représente déjà une grosse différence comparé aux

centaines de kilomètres en MN03. Finalement, le système décrivant la transformation du MN03

au MNGE s’écrit :

(1)

4.5.2. Logiciels utilisés

Cette partie va maintenant expliquer comment sont concrètement transformées les

données de base afin de pouvoir être livrées aux utilisateurs avec tous les paramètres vus dans

les différents paragraphes précédents. Nous rappelons que ces données doivent tout d’abord

être créées, puis translatées en MNGE avant d’être converties dans les différents formats. Deux

méthodes ont été élaborées, la première { l’aide de scripts FME automatiques et la deuxième {

partir du logiciel Rhino et de son applicatif RhinoTerrain.

4.5.2.1. Scripts FME

Le logiciel FME Workbench est tout à fait intuitif dans son utilisation. Pour simplifier, on

peut dire qu’il suffit de créer des « Readers1 » afin de lire nos données d’entrées sur le disque dur

et des « Writers1 » afin de créer de nouvelles données dans d’autres formats numériques. On

peut également appliquer des traitements à nos données grâce à une liste impressionnante de

« Transformers1 ».

1 Termes anglais tirés de la version anglaise du logiciel utilisée

Figure 46 | Différences MNGE / MN03 dans SketchUp

Xmnge = Xmn03 – 480 000 m

Ymnge = Ymn03 – 109 000 m

Zmnge = Zmn03


44

Sur la Figure 47 ci contre, nous voyons quelques

« Writers » dont nous aurons besoin pour convertir les données

aux formats *.3ds ou *.obj. Il faut créer des « Writers » différents

pour chaque nouvel objet avec des chemins d’écriture sur

disque différents.

Ensuite nous aurons besoin des « Transformers » suivants :

TINGenerator : Cet outil est très intéressant, car, comme nous le

voyons sur la Figure 48 ci contre, il peut recréer un TIN à partir

de points et de lignes de ruptures en entrées. C’est en ce sens que

l’outil MNR_auto a été bien pensé en fournissant les lignes de

ruptures et les points constituant le MNR dans ArcGIS.

3DAffiner : Il permet d’appliquer un système d’équations affines aux données d’entrées de la

forme :

X’ = A.X + B.Y + C.Z + D

Y’ = E.X + F.Y + G.Z + H (2)

Z’ = I.X + J.Y + K.Z + L

Ainsi, en modifiant les coefficients A = F = K = 1 ; D = -480 000 ;

H = -109 000 et en conservant les autres à zéro, on translate les

données du système MN03 au système MNGE.

Ce « Transformer » permet aussi de régler le problème

d’inversion des axes du format WavefrontObject en jouant avec

les coefficients pour que l’axe Yobj corresponde { l’axe Z et que

l’axe Zobj corresponde à l’opposé de l’axe Y. Nous voyons cet outil

spécifique au format *.obj ainsi que le détail de ses coefficients

sur la Figure 49 ci contre.

Finalement, il ne reste plus qu’{ relier les bons « Readers », « Transformers » et « Writers »

afin de générer les différentes données dans les bons formats et dans le bon système de

coordonnées, bâtiments 3D allégés pour la zone région, bâtiments 3D complets et MNR pour la

zone projet.

Figure 47 | « Writers » FME utiles

Figure 48 | « Transformer » TINGenerator

Figure 49 | « Transformer » 3DAffiner spécifique au format OBJ


45

Par exemple pour créer le MNR d’une zone quelconque au format *.obj dans le système

MNGE, il faudra lancer le script FME suivant (cf Figure 50) après avoir lancé l’outil MNR_auto sur

les données de cette même zone afin d’obtenir les données lignes et points constituant le MNR

en entrées de ce script:

4.5.2.2. Rhino

Une autre technique consiste à utiliser le logiciel Rhino. Le choix de ce logiciel n’a pas été

arbitraire par rapport aux autres testés, mais a surtout été motivé par les avantages de son

applicatif RhinoTerrain. Cet applicatif a été développé par Claude Vuattoux, géomètre de

formation et qui avait la volonté de créer un logiciel permettant de travailler efficacement sur

des données géographiques et particulièrement sur les terrains et MNT. Son avantage majeur est

tout d’abord qu’il est le seul logiciel de conception 3D { pouvoir importer directement des

données Shapefile provenant de l’environnement ESRI sans passer par un logiciel de conversion

tiers (cf Figure 51).

Son deuxième avantage est sa puissance et sa rapidité de calculs, même sur des quantités

de données importantes. Il permet également de mailler un nuage de points et de gérer les lignes

de ruptures dans cette opération, ce qui est extrêmement pratique pour recréer un MNR à partir

des sorties lignes et points du programme MNR_auto comme l’illustre la Figure 52 ci-dessous.

Figure 50 | Script FME pour convertir un MNR au format OBJ

Figure 51 | Import Shapefile de RhinoTerrain

Figure 52 | Maillage du MNR à partir des lignes et points avec RhinoTerrain


46

On peut ensuite tout simplement translater les objets afin de les ramener dans le système

MNGE. Pour cela, on créé un point ayant les coordonnées (480 000, 109 000, 0), on sélectionne

tous les objets que l’on veut déplacer (bâtiments et MNR) et on utilise la fonction « Move » avec

comme point de base le point que l’on vient de créer et comme point d’arrivé l’origine du repère.

On peut ensuite simplement exporter les objets sélectionnés dans les différents formats

que propose Rhino (la liste est très complète). On remarque dans les options d’export du format

*.obj qu’il est possible de régler directement le problème d’inversion des axes en cochant

simplement la case .

Un autre gros avantage d’utiliser Rhino comme logiciel d’échange des données

géométrique est que l’on peut éditer et corriger le MNR dans le même logiciel. On n’a donc plus {

exporter les lignes dans un format d’échange, { les éditer dans un logiciel tiers avant de les

retransformer pour recréer le TIN dans ArcGIS par exemple. Dorénavant, toutes ces opérations

sont réalisables dans un seul et même logiciel. Les fonctions d’édition du terrain sont

nombreuses, on peut notamment ajouter ou supprimer des sommets ou des lignes de ruptures,

les changer de types (rigides ou souples) ou supprimer le bruit dans un terrain issu d’un lever

Lidar…

On peut également plaquer des orthophotos ou images satellites en sélectionnant

simplement leurs fichiers *.tfw ou *.jgw (fichiers de géoréférencement des formats TIFF et JPEG

respectivement) correspondants. En effet, RhinoTerrain est également le seul logiciel testé à

prendre en compte le géoréférencement des images.

Enfin, un dernier avantage concret de l’utilisation de Rhino est sa décomposition du

terrain selon les lignes de ruptures. En effet, si les lignes de ruptures sont bien créées et fermées,

le logiciel peut décomposer la maile globale en plusieurs mailles séparées. Cela peut s’avérer très

utile pour appliquer des matériaux indépendants aux différents éléments du domaine routier.

On peut aussi faire ressortir les routes et accès à un projet ce qui est souvent important. Une

illustration de cet avantage est donnée au §5.1, Figure 55.

4.5.3. Poids des données

Voici maintenant un tableau récapitulatif du poids numériques de toutes les données que

le SEMO peut dorénavant fournir aux différents utilisateurs potentiels afin de créer leurs

maquettes numériques 3D :

On remarque que la différence de poids entre le format TIFF et le JPEG (format compressé)

est énorme. Une image au format JPEG pèse entre 10 et 20 % de son poids en TIFF. Aussi son

utilisation semblerait évidente. C’est le cas pour la zone région où aucune différence ne se fait

Tableau 1 | Poids des données


47

sentir de si loin. Sur la zone projet au contraire, le but étant de pouvoir se rapprocher très près

du sol, la différence se fait clairement ressentir et l’utilisation du format TIFF sera préférée si

possible.

Maintenant que nous avons vu toutes les opérations à effectuer pour obtenir les données

prêtes { l’emploi, nous allons voir quels sont les résultats qui sont possibles grâce au socle

urbain 3D et la couronne d’horizon.

V. RESULTATS ET VALIDATION

L’aspect visuel ainsi que la diversité des rendus possibles, chers aux architectes et

paysagistes, seront tout d’abord illustrés, puis nous aborderons les questions de la précision et

de l’exactitude géométrique, sujets plus propres aux métiers de géomètres et topographes.

5.1. Résultats possibles avec le socle urbain 3D

Une des volontés des utilisateurs du socle urbain

3D était de ne pas être contrains de travailler dans un

environnement figé et sur lequel ils ne pourraient pas

avoir de liberté de création. Pour cela, il a été décidé

de livrer les données du MNR sous forme de

« maquette blanche » brute, qui rappelle les maquettes

physiques utilisées par les architectes en concours

notamment. Ci-contre (cf Figure 53), une de ces

maquettes avec certains bâtiments qui ont été enlevés

pour illustrer la technique des socles dans lesquels ils

Figure 53 | Maquette blanche

Récapitulatif de la partie IV :

Nous avons pu voir l’évolution de la solution envisagée jusqu’{ sa mise en œuvre

effective. Le principe général est simple : pour répondre à tous les problèmes évoqués dans la

partie précédente, un prototype de maquette à plusieurs zones a été mis au point.

La zone région, composée d’un MNT texturé et d’une couche de bâtiments allégés,

permet de donner une profondeur de champ à une maquette sans saturer la mémoire

informatique d’un ordinateur standard.

L’outil MNR_auto qui a été développé sous ArcGIS permet de générer automatiquement

un « Modèle Numérique de Rue » sur la zone d’intérêt de la maquette, et dont les

caractéristiques correspondent aux attentes des utilisateurs concernés, à savoir un rendu

visuel propre et acceptable au niveau du sol. Nous avons vus les différents avantages et

inconvénients de cette surface, dont il est nécessaire de préciser qu’elle n’est qu’une

représentation simplifiée de la rue et dont l’utilisation doit se résumer { de la visualisation.

En ajoutant les bâtiments complets sur ce MNR, nous obtenons le « socle urbain 3D»,

espace de travail brut pour les utilisateurs, translaté dans un système local genevois (MNGE) et

dont l’export en différents formats a été permis grâce aux logiciels FME ou Rhino.

En annexe 8, vous trouverez un schéma qui récapitule le parcours des données entre le

SEMO et les utilisateurs futurs, avec tous les géotraitements qu’elles subissent.


48

viennent s’emboiter (cf §4.3.1.4).

Le MNR du socle urbain 3D peut ensuite être texturé avec l’orthophoto de la zone. Une des

difficultés après avoir drapé la photo est que l’on peut vite obtenir un résultat très hétérogène

entre le photoréalisme du terrain et l’aspect objet des bâtiments, ceux-ci n’étant pas texturés. La

Figure 24 de ce rapport (page 28) illustre bien cette hétérogénéité. Il faut donc jouer avec les

paramètres de rendu afin de chercher plus d’homogénéité. Cet aspect se rapproche beaucoup

d’un travail d’infographie qu’il m’a été agréable de découvrir. Voici quelques résultats que l’on

peut obtenir :

La maquette « technique » : en ajustant les couleurs et transparences des objets, on

obtient les rendus ci-dessous (cf Figure 54) assez homogènes. De plus, en appuyant un

peu les contours des arêtes des bâtiments, on peut obtenir l’aspect « esquissé » (image b)

très apprécié des personnes interrogées.

A partir de cette maquette technique, on peut également faire ressortir les voix de

communication et accès au projet, ce qui est souvent très important dans l’élaboration d’un

projet. Sur la Figure 55 ci-dessous, nous voyons à gauche un croquis de Philippe Thébaud,

urbaniste paysagiste et directeur de la société GVA dont nous avons parlé au §2.1.2.1, tiré de son

livre Thébaud[2003]. Ce croquis illustre la façon dont les voix de circulation autour d’un projet

peuvent être réfléchies et mises en évidence par rapport aux bâtiments esquissés. C’est le même

effet qui a été recherché sur la maquette numérique à coté, en appliquant aux routes une couleur

transparente bleue en plus de l’orthophoto. Cette opération est très facile grâce à la

décomposition du terrain de Rhino vue au §4.5.2.2.

Figure 54 | Maquettes techniques


49

La maquette photoréaliste : il est également possible de texturer les toits des bâtiments

avec la même orthophoto, ce qui donne un rendu photoréaliste aux survols, malgré

l’absence des textures des façades (cf Figure 56).

Il est ensuite possible d’insérer le

socle urbain 3D ainsi créé dans la zone

région par opération booléenne. On peut

ainsi voir l’impact du projet dans son

environnement global ainsi que les vues et

ouvertures qui seront offertes. Sur la

Figure 57 ci-contre, on voit clairement les

différentes zones de la maquette, le MNR

et les bâtiments 3D complets au premier

plan, les bâtiments 3D allégés et les

montagnes texturées avec une image

satellite { 5m { l’arrière plan.

Enfin, on peut habiller la zone projet de

la maquette avec du mobilier urbain ou des

arbres afin de rendre la scène plus vivante et

plus vendeuse (cf Figure 58). Des exemples de

vues piétonnes plus détaillées seront

présentés au §0. Dans toutes les images de ce

rapport, les symboles de mobilier urbain

utilisés ne sont pas officiels et ne ressemblent

Figure 56 | Maquette photoréaliste

Figure 57 | Couronne d’horizon { l’arrière plan

Figure 58 | Vue piétonne habillée

Figure 55 | Mise en évidence des routes : croquis et maquette numérique


50

donc pas forcément aux vrais objets, ils servent surtout { illustrer la possibilité d’habillage de la

maquette numérique.

5.2. Validation de la solution

Toutes les images présentées au paragraphe précédent ont été réalisées dans le logiciel

Rhino, utilisé pour réaliser l’interopérabilité des données créées pendant ce projet (cf §4.5.2.2).

Aussi il a fallu vérifier que l’export dans les différents formats permette bien aux utilisateurs de

travailler dans leurs logiciels respectifs et que les données 3D fournies correspondent bien à

leurs attentes.

5.2.1. Validation avec les différents acteurs

5.2.1.1. Compte rendu de la dernière séance avec l’équipe de travail

Lors de la dernière séance avec l’équipe de travail, les réalisations des différents acteurs

ont été présentées. Malheureusement, la plupart des participants avaient des emplois du temps

très chargés durant cette période et n’ont pas eu le temps de peaufiner leurs rendus. Le retour

général exprimé quant aux résultats possibles à la fin du projet a néanmoins été très positif et

des tests continueront à être menés par la suite en collaboration avec le SEMO.

Vous trouverez tout de même en annexe 9 quelques images plus ou moins abouties,

réalisées par les membres de l’équipe avec différents logiciels, ce qui prouvent l’interopérabilité

qui a été obtenue.

5.2.1.2. Application à un projet concret d’architecture

Le projet du CMU de M. Tellols, dont le quartier a servi de zone test tout au long du projet,

a été naturellement choisi pour servir d’exemple concret de l’utilité du socle urbain 3D.

Malheureusement, tout comme la plupart des personnes de l’équipe de travail, M. Tellols n’a eu

que très peu de temps à offrir pendant les dernières semaines du projet, au moment où toutes

les données étaient prêtes. J’ai donc utilisé moi-même les données, afin d’illustrer les réalisations

qui sont possibles.

J’ai tout d’abord utilisé le socle urbain 3D pour construire des prototypes de bâtiments

hypothétiques { l’emplacement du futur vrai bâtiment (cf Figure 59). Je ne suis pas architecte,

mais de manière objective, il est évident que le projet de l’image « c » s’intègre mieux dans

l’architecture de l’existant que le projet « b ». On peut également aisément comparer les deux

constructions en les rangeant dans deux calques différents qu’on peut activer/désactiver { tout

moment.

Figure 59 | Socle urbain 3D (a) et deux projets de construction hypothétiques (b et c)


51

Par la suite, M. Tellols nous a fourni la maquette officielle du projet au format *.3ds. J’ai

donc pu l’insérer dans le socle urbain 3D dans Rhino toujours. Toutes les étapes de cette

insertion sont décrites plus en détails en annexe 10. Un gros travail d’habillage avec du mobilier

urbain, les arbres ainsi que des voitures a été réalisé afin de rendre cette scène plus vivante. La

position du soleil a également été optimisée afin d’éclairer la scène de façon réaliste. Les images

suivantes (cf Figure 60) sont prises avec une perspective humaine, au niveau de la rue comme le

désirait les personnes interrogées lors de l’analyse du besoin. L’image « c » est sortie telle quelle

du processus de rendu de Rhino, tandis que les 3 autres ont été rapidement retouchées dans

Photoshop, simplement pour ajouter le ciel nuageux.

5.2.2. Analyse de précision

Maintenant que nous avons vu qu’il était effectivement possible de travailler et d’insérer

des projets aisément dans un socle urbain 3D, il nous reste à définir la précision du Modèle

Numérique de Rue et de quantifier les différences avec la réalité afin de définir si cette surface

répond aux exigences de la charte d’éthique de la 3D. Pour définir la qualité du Modèle

Numérique de Rue, nous avons pris le nuage de points Lidar comme référence. Nous

comparerons donc le MNR au Lidar, dont la précision altimétrique a elle-même été évaluée à

15cm en zone urbaine macadamisée. Pour cela, nous avons procédé de deux façons différentes.

La première façon a consisté à utiliser le logiciel CloudCompare qui, à défaut de livrer une

analyse détaillée, nous a permis d’identifier des points aberrants. La deuxième méthode a

consistée à passer par ArcGIS et Excel.

5.2.2.1. Identification des points aberrants

Les points Lidar bruts ont d’abord été convertis en fichiers de points ASCII et importés

dans le logiciel CloudCompare tout comme le MNR de la même zone au format *.obj. La fonction

du logiciel Compute cloud/mesh distance permet de calculer les distances verticales entre un

nuage de points et une surface maillée. Malheureusement, à part un histogramme très basique

(qui illustre tout de même une bonne répartition gaussienne des écarts), la fonction ne donne

pas d’analyse statistique très détaillée. Elle nous a néanmoins permi d’identifier quelques

portions de nuages de points aberrants. En effet, comme le montre l’histogramme ci-dessous (cf

Figure 60 | Différents rendus avant/après insertion du projet


52

Figure 61a), nous remarquons qu’une partie des points présente des écarts avec le MNR de plus

de 3m, ce qui est alarmant à première vue. Heureusement, un des avantages du logiciel est qu’il

permet de colorer les points en fonction de leurs répartitions (cf Figure 61b), nous avons donc

pu identifier les points présentant de tels écarts et remarquer que ce sont des points situés sur

des toitures et qui n’ont pas été nettoyés du nuage de points bruts. Les nuages Lidar ont en effet

été nettoyés grâce { l’emprise cadastrale des bâtiments au moment de son acquisition en 2005.

Les éventuelles extensions de bâtiments (figurants dans le bâti 3D dont l’acquisition est plus

récente) n’ont donc pas été prises en compte dans le nettoyage des nuages de points. La Figure

61 ci-dessous illustre le repérage de ces points aberrants ainsi que leurs positions dans la

maquette numérique (cf Figure 61c).

5.2.2.2. Etude de précision et statistiques

Afin d’obtenir une analyse statistique plus détaillée, une autre technique a été utilisée. On

enregistre tout d’abord une copie du nuage de points bruts que l’on a projeté verticalement sur

le MNR dans ArcGIS afin d’en avoir l’altitude correspondante en chaque points. On calcule

ensuite les valeurs altimétriques de tous ces points avec l’outil « Calculate Geometry ». On relie

ensuite les tables attributaires du nuage de points bruts et du nuage de points projetés sur le

MNR avec le champ d’identifiants des points. On peut maintenant ajouter un nouveau champ

« diff_ascii_mnr » dans lequel on calcule la différence entre les champs altimétriques des deux

nuages de points (ZLidar - ZMNR). ArcGIS pourrait ensuite donner une analyse statistique sur un

champ d’une table attributaire, mais celle-ci n’est pas beaucoup plus détaillée que celle de

CloudCompare. On exporte donc ce champ vers le logiciel Excel dans lequel on aura

préalablement téléchargé l’utilitaire d’analyse. On supprime tout d’abord les valeurs supérieures

à 2m correspondant aux points aberrants vus au §5.2.2.1 puis on peut lancer l’analyse. On a

réalisé cette analyse sur le nuage de points global, mais également sur des portions de nuages

extraites selon les éléments du domaine routier, à savoir les points des routes individuellement

ou ceux des trottoirs et des ilots. Le tableau ci-dessous résume les résultats obtenus et

l’histogramme suivant (cf Figure 62) représente la répartition des écarts sur tout le MNR.

Figure 61 | Repérage des points aberrants (en rouge)

Tableau 2 | Résultats de l’analyse statistiques des écarts MNR/Lidar


53

Analyse des résultats :

Tout d’abord, on remarque que l’on obtient une répartition gaussienne centrée à peu près

sur zéro pour les écarts sur tout le MNR. On peut expliquer que la moyenne soit un peu décalée

vers -4 cm par le fait que tous les trottoirs et ilots ont été arbitrairement surélevés d’une valeur

constante.

C’est cette même surélévation qui explique que les moyennes des écarts des trottoirs et

des ilots soient supérieures à celle des routes en valeurs absolues. La moyenne des ilots est

d’ailleurs légèrement supérieure { celle des trottoirs étant donné que ces derniers ont été

surélevés de 25 cm contre seulement 15 cm pour les trottoirs.

L’écart-type des ilots est d’ailleurs aussi supérieur aux écarts-types de toutes les autres

portions de nuages, ce qui s’explique aisément. En effet, les ilots peuvent représenter beaucoup

plus d’objets différents qu’un trottoir par exemple sur le domaine routier. Il peut s’agir des ilots

de circulation centraux, mais également du terre plein d’un rond point ou du mur d’une descente

de parking souterrain entre autres. Ainsi, en ayant surélevé ces objets uniformément de 25 cm, il

est normal que les écarts divergent plus rapidement que ceux des trottoirs par exemple.

Toutes ces analyses de précision permettent de dire que la précision obtenue avec l’outil

MNR_auto est tout { fait satisfaisante pour l’utilité qu’en auront les principaux intéressés, à

savoir les architectes, urbanistes et paysagistes pour faire du rendu visuel et non pas des

analyses ou études. Pour pouvoir apposer le logo « 3DOK » sur des images réalisées à partir du

MNR, il faudra tout de même bien penser { préciser l’origine des données et le fait qu’elles ont

été obtenues par un processus automatisé, afin de bien respecter le principe de transparence de

la charte d’éthique (cf §2.2.2.2).

Maintenant que nous avons vu ce qui a été réalisé sur le plan technique pour satisfaire les

futurs utilisateurs, nous allons voir les pistes qui ont été abordées sur le plan administratif et

politique.

Figure 62 | Répartition des écarts MNR/Lidar sur tout le MNR

Ecarts (m)


54

VI. L’ASPECT ADMINISTRATIF ET POLITIQUE

Comme nous le disions au §3.3.2, il apparait que les architectes et autres professionnels de

l’aménagement du territoire ne bénéficient actuellement pas d’avantages concrets { s’investir

dans la 3D, et cet aspect n’est pas étranger au fait que sa démocratisation prenne un certain

temps. Il s’agit dans cette partie d’évoquer les différentes idées et options qui pourraient être

mises en place. Evidemment, ce sont des procédures administratives longues à mettre en place

et qui nécessiteront des exemples concrets.

6.1. Les procédures administratives

6.1.1. Les autorisations de construire

Le premier point à être abordé concerne les obtentions de permis de construire. Ce sont

des procédures longues et fastidieuses, avec de nombreux documents et justificatifs à fournir.

Ici, on ne pourrait pas demander une maquette numérique supplémentaire sans alléger la liste

des documents traditionnels à fournir. Nous pouvons trouver sur le site Construction@[2011] la

liste des documents à fournir au DCTI pour obtenir un permis de construire. Parmi ces

documents figurent entre autres :

« 5 exemplaires de plans, coupes et façades nécessaires à la compréhension du projet

teintés aux couleurs conventionnelles […] »

« 5 exemplaires de plans situant les arbres à abattre et à conserver […] »

« 5 exemplaires du relevé des niveaux du terrain naturel existant établi par un géomètre

officiel. »

« 5 exemplaires de plans des canalisations d’évacuation des eaux polluées et non polluées

du (des) bâtiment(s) existant(s) et { construire […] »

Récapitulatif de la partie V :

Dans cette partie, nous avons tout d’abord vus les différents résultats possibles grâce au

socle urbain 3D et { la couronne d’horizon. On remarque qu’avec quelques fonctions

d’infographie simples, on peut obtenir une multitude de résultats (maquette blanches,

techniques ou photoréalistes…). Cet aspect est important car les utilisateurs ont manifesté leur

souhait de pouvoir appliquer leurs propres touches artistiques, et de ne pas être contraints de

travailler dans un environnement figé visuellement.

L’exemple concret sur le nouveau bâtiment du CMU a ensuite bien illustré la relative

simplicité d’utilisation du socle 3D urbain et qu’il est possible, même pour quelqu’un qui n’est

pas architecte de formation de mettre en valeur et d’habiller une maquette avec de la

végétation et des arbres afin de faire du rendu piéton au niveau du sol, ce qui était une des

attentes principales évoquées lors de la définition du besoin.

La comparaison altimétrique entre le MNR et le nuage de points Lidar a enfin permis

d’évaluer la qualité du MNR créé et donc de valider l’utilisation de l’outil MNR_auto. Les

résultats et images créés à partir de cette technique pourront donc bien être qualifiés de

« 3DOK », { condition de respecter le principe de transparence de la charte d’éthique en

indiquant la provenance des données.


55

On pourrait imaginer que ces nombreux documents papiers à fournir pourraient un jour

être remplacés par une seule maquette numérique, correctement légendée et avec des calques

normalisés dans lesquels on pourrait aisément accéder ou isoler telle ou telle information de la

maquette. Le DCTI est en train de développer la mise en ligne de toutes ces procédures. Bientôt,

les constructeurs devront déposer leurs demandes d’autorisation sur internet et tout le monde

pourra y accéder librement. Les riverains d’un futur projet pourront notamment savoir ce qui

est envisagé proche de chez eux et pourront réagir si besoin. Cet élan technologique pourrait par

la suite être propice { l’adoption de maquettes numériques, idéales pour une meilleure

compréhension d’un projet pour un public amateur.

6.1.2. Les concours d’architecture

Un autre processus où l’utilisation d’une maquette numérique pourrait être efficace est

celui du choix d’un projet par rapport { d’autres lors d’un concours d’architecture. En effet, une

maquette interactive dans laquelle on pourrait activer ou désactiver les calques de différents

projets permettrait de mieux comparer les différentes options et de se faire une idée objective

de l’impact de tel ou tel bâtiment dans son environnement.

Il existe déjà dans le monde des exemples de concours d’architecture se basant sur des

données 3D. L’article de Gerald FORKET (Forket[2008]) parle des concours d’architecture de la

ville de Gugging près de Vienne en Autriche. Il y précise que tous les participants à un concours

reçoivent une maquette numérique de l’existant dans différents formats numériques et peuvent

ainsi y insérer leurs constructions. L’auteur précise que les « architectes peuvent mieux tenir

compte de la structure architecturale à conserver, ce qui a généralement pour effet d’augmenter

la qualité des résultats fournis » et que « l’adjudicateur a en outre la possibilité d’évaluer les

projets soumis dans un cadre homogène […] »

Afin de voir dans quel contexte et dans quel cadre on pourrait proposer la même

procédure à Genève, je me suis fait fournir la description de la norme SIA 142 qui détaille le

règlement des concours d’architecture et d’Ingénierie en Suisse. Nous pouvons lire dans le

préambule de celle-ci que « pour le maître de l’ouvrage, le concours représente un moyen

d’obtenir un projet de haute qualité et de trouver le partenaire pour la réalisation de ce projet

[…] Pour le participant, le concours offre la garantie d’un jugement objectif de son travail

créateur… » Cette introduction recoupe ce que disait Gerald FORKET dans son article et pourrait

laisser envisager des concours basés sur la 3D. De plus, la norme SIA 142 précise dans son article

13.3 que le maître de l’ouvrage formule le programme du concours qui contient notamment « la

liste des documents demandés et leur mode de présentation ». Ce mode de présentation pourrait

donc être une maquette numérique 3D selon le souhait du maître d’ouvrage. Ainsi, il faudrait

trouver des constructeurs volontaires pour proposer des concours d’architecture de ce type en

leurs vantant tous les avantages dont ils pourront bénéficier. Pour ce faire, plusieurs documents

récapitulatifs ont été rédigés (voir §6.3).

6.1.3. Formats de présentation

6.1.3.1. PDF 3D

Il a aussi été abordé la forme de présentation des projets à un jury ou même à un public

amateur, car en effet, bien souvent les constructions en 3D sont indissociables de l’outil avec

lequel elles ont été créées. Ainsi, vu qu’on ne peut pas imposer de logiciel unique { aucun


56

participant, il faudrait demander le rendu dans un format neutre et indépendant de l’outil de

construction. En se penchant sur le sujet, le format PDF 3D nous a semblé très intéressant car il

permet de visualiser des scènes 3D très facilement et ne nécessite que de posséder le logiciel

AdobeViewer, gratuit et accessible à tous. Ce format avait déjà été abordé par Thomas Noirot

dans son rapport Noirot[2009]. Les résultats visuels sont relativement surprenants. Le socle

urbain 3D du quartier du CMU a été converti en PDF 3D grâce à FME, et le fichier ne pèse que 43

Mo, avec un rendu relativement agréable comme l’illustre la Figure 63 ci-dessous. On remarque

que même la texture photographique du sol a été conservée dans le PDF. En plus de cela, ce

format permet de conserver l’arborescence des calques et donc de pouvoir enregistrer

éventuellement plusieurs projets différents { l’intérieur d’un même fichier PDF 3D pour mieux

pouvoir les comparer.

6.1.3.2. La 3D immersive

La plateforme pilote du projet PRAM1 préfigure une nouvelle utilisation de la 3D. C’est une

plateforme collaborative développée par la société DEPTH SA en collaboration avec la société

Spatial SA. Ne nécessitant ni installation de logiciel, ni formation, cette plateforme permet à

n’importe quel utilisateur « d’accrocher » des informations multimédias sur un décor immersif.

Dans un tel décor, { vision humaine, l’internaute se déplace intuitivement, libre de ses

mouvements, trouve ou dépose instinctivement (s’il dispose des droits d’écriture) l’information

appropriée. Un tel système entièrement dédié au visuel pourrait s’imposer comme base

participative dans de nombreux domaines.

Le projet PRAM a consisté à modéliser numériquement la maquette (physique) de Genève

avant la démolition des remparts. Cette maquette a été réalisée de 1878 { 1896 par l’architecte

Auguste Magnin et on peut aujourd’hui, grâce { cette plateforme immersive se promener

virtuellement dans cette Genève historique et être redirigé vers diverses métadonnées, qui

peuvent être des photographies, manuscrits, images d’archives ou commentaires

d’historiens…(cf Figure 64). Plus d’informations sur ce projet sont données sur le site

Spatial@[2011]. C’est une application très culturelle de cette plateforme mais son utilisation

dans les domaines de l’architecture, de la communication technique autour d’un futur projet ou

de la présentation à un public amateur est aisément imaginable.

1 Projet Relief Auguste Magnin

Figure 63 | Aperçu du PDF 3D du quartier du CMU


57

6.2. Les enjeux politiques

Comme nous l’avons vu au §1.2, la 3D est devenue un outil incontournable de politique

publique, d’aide { la décision, de concertation et de communication. La 3D fait maintenant partie

de notre quotidien et s’immisce de plus en plus dans les métiers et comme support de décisions

administratives et politiques. En plus d’être une vitrine, technique et culturelle, d’une ville ou

d’une agglomération, une maquette numérique 3D peut servir à favoriser une urbanisation

sereine et maîtrisée.

En effet, comme nous l’avons vu dans l’exemple du §2.1.2.2, le nouveau plan de réseau des

TPG avait initialement été repoussé par les députés qui demandaient plus d’informations. La

maquette numérique présentant efficacement les flux aux différents nœuds de transbordement

et surtout les différentes variantes proposées a permis de mieux expliquer l’important

changement que cela allait représenter et de rassurer les élus sur la pertinence des choix

d’aménagement effectués. Le projet a finalement été modifié puis accepté et les travaux seront

activés en Janvier 2012.

Une maquette permet également de « dépassionner les débats » autour de nouveaux

projets. En effet, tout le monde peut avoir une vision objective du sujet de discussion et en parler

en connaissance de cause. Aucun participant au débat ne peut se sentir manipulé ou trompé par

des plans 2D techniques qu’il ne comprendrait pas totalement. Beaucoup de mauvaises surprises

en cours de chantiers pourraient également être évitées lorsque le public découvre des

immeubles ne correspondant pas du tout { ce qu’ils se sont imaginé grâce à des plans 2D pas

assez explicites.

Ainsi, l’adoption de la maquette numérique comme support de réflexion et de concertation

ne peut apporter que des avantages pour une urbanisation contrôlée et efficace. Bien entendu, sa

mise en place impliquera également quelques problèmes liés aux changements organisationnels

que cela amènera, mais ne pourra qu’être bénéfique sur le long terme. Des exemples devront

être réalisés afin de valoriser les avantages de la 3D et de donner envie aux utilisateurs

potentiels de s’investir dans cette technologie.

6.3. Valorisation de l’utilisation de la 3D

Afin de valoriser l’utilisation de la 3D et de motiver des professionnels { servir d’exemples,

il faut déjà que les gens prennent conscience de la disponibilité de ces données au SEMO et des

avantages qu’elles pourraient apporter.

Figure 64 | Interface de la plateforme 3D immersive


58

Evidemment, de tels changements dans l’administration et dans les pratiques

professionnelles en place prendront du temps et ne peuvent pas être réalisés { l’échelle de ce

Projet de Fin d’Etudes, mais une préparation du terrain est possible et une publicité vantant les

bénéfices de telles maquettes numériques peut être entamée. Dans ce but, deux documents ont

été rédigés afin d’être diffusés sur le Canton, une fiche d’information ainsi qu’un dépliant.

6.3.1. La fiche d’information

Cette fiche (disponible en annexe 6) récapitule tous les avantages de la 3D dans

l’aménagement du territoire mais également ses limites, ses difficultés et les solutions qui sont

trouvées. Elle est destinée { être diffusée aux directions des différents services de l’Etat en

charge de l’aménagement du territoire ou aux organisateurs potentiels de concours

d’architecture (publics ou privés) afin qu’ils puissent avoir l’idée de demander des offres sous

forme de maquettes numériques.

Nous pouvons résumer les avantages énoncés dans cette fiche en disant que la 3D est un

outil efficace à plusieurs égards :

Un outil de conception

Un outil de visualisation et de concertation

Un outil d’analyse et de simulation

Les limites de la 3D exprimées dans cette fiche portent sur les domaines suivants :

La technique

La formation et la technologie

Les changements au niveau des métiers

Il est également expliqué en conclusion de ce document que beaucoup de ces limites et

problèmes, inhérents { toute nouvelle technologie, commencent aujourd’hui { être résolus, ce

qui permet dorénavant de se pencher sur les utilisations et applications de telles maquettes 3D.

6.3.2. Le dépliant

Un dépliant a également été rédigé et peut être trouvé en annexe 11. Sa forme est plus

conviviale que la fiche ci-dessus et sa diffusion sur des stands ou autre manifestation plus

naturelle. Son contenu est un peu différent également, il résume brièvement les avantages vus ci-

dessus mais se concentre ensuite surtout sur ce qui a été réalisé durant mon stage (MNR, zone

région, …) et sur les résultats qui sont possibles (cf §5.1), afin de montrer visuellement les

avantages dont pourrons bénéficier les futurs utilisateurs.

Le dépliant précise que la volonté du SEMO est de mettre toutes ces données à disposition

gratuitement et que n’importe qui peut entrer en contact avec le service pour obtenir des jeux de

données pour réaliser des tests et voir ce qu’il est désormais possible de faire. Les résultats

obtenus en très peu de temps sont prometteurs. Plusieurs directions de départements comme le

DCTI ont déjà fait part de leur intérêt pour ce projet et ont déjà demandé des jeux de données de

certaines zones, preuve que la démarche fait école et qu’elle pourrait se développer dans les

prochains mois ou prochaines années.


59

VII. CONCLUSIONS ET PERSPECTIVES

Pour conclure, je peux commencer par dire que ce projet a été réellement passionnant à

réaliser à plusieurs points de vue. Tout d’abord, comme nous avons pu le voir dans l’état de l’art

de ce rapport, les problématiques de la 3D dans la gestion du territoire sont généralement

ressenties et il est valorisant de travailler sur un sujet aussi concret dans un domaine

relativement jeune et en pleine explosion. Il faut préciser que c’est également un domaine

extrêmement riche et vaste, il a donc fallu faire un important travail de cadrage et de définition

des objectifs précis pour ne pas m’égarer dans certaines des nombreuses problématiques

annexes. Ensuite, ce travail a été très pluridisciplinaire, { l’image de l’équipe de travail qui a été

formée pour coordonner le projet. Il a été très intéressant d’être confronté { des métiers comme

l’architecture ou le paysagisme et de devoir prendre en compte des contraintes autres que celles

du métier de géomètre. Cela a constitué une très bonne ouverture d’esprit et les nombreuses

rencontres avec des personnes d’horizons variés ont été très enrichissantes, tant sur le point

professionnel que personnel.

Lors de la réalisation de cette étude, les différents problèmes et besoins recensés au début

du projet ont été pris en compte de manière continue afin de ne négliger aucun aspect. Les

résultats obtenus grâce au socle urbain 3D et à la zone région répondent efficacement aux

différentes attentes des personnes consultées en début de stage. L’outil MNR_auto permet

effectivement de réaliser des vues piétonnes et d’avoir un rendu de la rue largement acceptable

pour les utilisations qu’on en aura. La précision du MNR a été évaluée par rapport aux points

Lidar bruts et permet de dire que de telles maquettes peuvent bien être qualifiées de « 3DOK ».

La zone région qui a été créée permet ensuite d’insérer n’importe quelle maquette dans son

environnement global et de ne pas avoir d’arrière plan vide. L’interopérabilité obtenue grâce

notamment { l’export des lignes et points constituant le TIN du MNR permet d’exporter les

données vers la plupart des logiciels testés, ce qui répond bien à un des objectifs principaux du

projet. Globalement, les retours positifs des membres de l’équipe de travail et des personnes

suivants le projet de plus ou moins loin permettent d’affirmer que les objectifs de ce travail ont

bien été atteints.

Récapitulatif de la partie VI :

Cette ultime partie sert à ouvrir les perspectives possibles sur une démocratisation

générale de la 3D comme outil de politique publique. En effet, il a été vu qu’une des raisons de

la sous utilisation actuelle des données 3D était probablement le manque d’avantages concrets

pour les utilisateurs potentiels. Pour obtenir ces avantages, qui pourraient être de nature

administrative, comme des simplifications de procédures d’obtention de permis de construire

par exemple. Mais pour cela, c’est toute une pensée générale qui devrait évoluer, à tous les

étages. Des maîtres d’ouvrages pourraient également demander des offres sous forme de

maquettes numériques lors de concours d’architecture également, mais déj{ faudrait il qu’ils

soient au courant de la disponibilité et des avantages de telles représentations. Ainsi, bien que

de telles adaptations dans les pratiques professionnelles prendront forcément du temps, il est

nécessaire de valoriser dès maintenant l’utilisation de la 3D et d’en faire la publicité sur le

Canton de Genève, ce qui a été initié par la rédaction des deux documents que sont la fiche

descriptive et le dépliant.


60

En ce qui concerne les perspectives à court terme, nous pouvons mentionner le fait que

l’outil MNR_auto devra et surtout pourra être facilement améliorable par le SEMO. La procédure

de traduction du script au format Geodatabase a déjà été détaillée, afin que les problèmes dus

aux géotraitements sur des Shapefile explicités au §4.3.1.5 ne soient plus ressentis. Un MNR

nécessite actuellement toujours une manipulation et un contrôle humain avant d’être livré { un

architecte ou autre professionnel, ce qui n’est pas contraignant pour le moment, car le nombre

de demandes restera encore relativement faible dans un premier temps. Sur le long terme, afin

de pouvoir inclure une surface MNR dans le GeoExtracteur du SOSI, il faudra encore améliorer le

processus et certainement le traduire en script FME afin que l’extraction de données soit

complètement automatisable selon le principe de fonctionnement du GeoExtracteur, qui ne

nécessite aucune intervention humaine.

Les problèmes techniques initiaux de la 3D, inhérents à toutes nouvelles technologies,

commencent à trouver des solutions variées dans tous les domaines, et nous pourrons bientôt

parler de technologie mature. D’ici l{, des formats numériques normalisés auront peut-être été

adoptés comme référence, comme le CityGML par exemple ou le BIM1 également. Pour l’heure,

ce qui est important, c’est de trouver des applications concrètes qui serviront d’exemples. Les

pistes évoquées dans ce rapport, notamment sur les concours d’architecture { base de

maquettes 3D pourront être de bons déclencheurs. Pour cela, la publicité autour des avantages

concrets de telles maquettes devra être poursuivie afin que des projets concrets d’envergure

soient créés { partir de cette technologie et qu’un engouement général puisse avoir lieu.

Finalement, la démocratisation de la 3D dans l’aménagement urbain nécessitera des

exemples et prendra nécessairement un certain temps. Des changements seront à prévoir dans

les pratiques professionnelles et dans l’administration en général, ce qui impliquera bien sur des

problèmes organisationnels dans un premier temps. Ces changements représentent une

véritable révolution culturelle tout en sachant que la 3D est souvent injustement perçue comme

un saut dans l’inconnu technique avec un temps d’appropriation conséquent. Sur le long terme,

on peut affirmer que l’adoption de la 3D comme véritable outil décisionnel et de politique

publique ne pourra apporter que des avantages { l’ensemble des personnes concernées, et

permettra d’avoir une urbanisation réfléchie et maitrisé, avec une plus grande implication du

citoyen dans l’aménagement de son paysage. Nous pouvons donc nous demander si nous

n’allons pas assister dans les prochains temps à un véritable bouleversement des pratiques

professionnelles liées { l’aménagement du territoire, sous l’impulsion de projets qui serviront

d’exemples et d’une législation qui pourrait également être adaptée pour valoriser et motiver

l’utilisation de la 3D.

1 Building Information Modeling


61

TABLE DES ILLUSTRATIONS

Figure 1| Exemple de bâtiment remarquable: le Grand Théâtre de Genève ............................................. 3

Figure 2| Composition d'un bâtiment 3D ................................................................................................................. 4

Figure 3 | Extrait d'une animation réalisée grâce aux données 3D du SEMO ........................................... 5

Figure 4 | Extrait de l'aménagement d'un carrefour ........................................................................................... 5

Figure 5 | Extrait de la simulation des flux de l'HEPIA (Gervais, F. et al. [2010]) ................................... 6

Figure 6| Environnement du logiciel 3DSmax avec les bâtiments 3D du SEMO ...................................... 7

Figure 7 : Insertion de la maquette 3D dans la photographie, avant retouches (à gauche) et après

(à droite) ................................................................................................................................................................................ 7

Figure 8: Extrait de la maquette virtuelle du Havre (LeHavre@[2011]) .................................................... 8

Figure 9| Aperçus du Reichstag en LoD3 et d’un musée en LoD2 ................................................................. 8

Figure 10| Différences entre les 2 versions du socle 3D de Berlin. Exemple de la gare centrale. .... 9

Figure 11 | Logo 3DOK .................................................................................................................................................. 10

Figure 12 | Rendu filaire du format *.dxf dans AutoCAD ................................................................................ 12

Figure 13 | Exemple de maquette virtuelle réalisée par l'HEPIA avec le logiciel Cinema 4D ......... 13

Figure 14 | Détails des différents LoD de la norme cityGML ......................................................................... 14

Figure 15 | Différences entre retouche photo (à gauche) et maquette 3D (à droite) ......................... 19

Figure 16 | Illustration de l’aspect du MNT qui ne convient pas aux architectes ................................. 19

Figure 17 | Schéma du prototype en 3 zones ...................................................................................................... 24

Figure 18 | Composition du prototype en 3 zones initial ............................................................................... 25

Figure 19 | MNT raster de la région étendue de Genève et emprise de l’image satellite

correspondante ................................................................................................................................................................ 25

Figure 20| Analyse de direction du MNT et crêtes ainsi détectées ............................................................ 26

Figure 21 | Aperçu du terrain global après décimation et maillage ........................................................... 27

Figure 22 | Modèle numérique de Terrain texturé de la zone région finale ........................................... 27

Figure 23 | Algorithme FME pour rassembler les façades et toitures principales des bâtiments 3D

................................................................................................................................................................................................ 28

Figure 24 | Import de l'ensemble des bâtiments allégés dans la zone région ....................................... 28

Figure 25 | Insertion de la volumétrie des bâtiments dans la maille du terrain................................... 29

Figure 26 | Exemple de texturisation du MNT comprenant les bâtiments. ............................................ 30

Figure 27 | Arborescence de l’outil MNR_auto dans ArcCatalog ................................................................. 31

Figure 28 | Entrées du processus ............................................................................................................................ 31

Figure 29 | Fenêtre de lancement de l’outil 1.MNR .......................................................................................... 32

Figure 30 | Division initiale du programme MNT_auto ................................................................................... 32

Figure 31 | Illustration des différences MNT/MNR .......................................................................................... 34

Figure 32 | Différence entre le nuage de points Lidar triangulé (à gauche) et le MNR avec une

perspective au niveau du sol (à droite) ................................................................................................................. 34

Figure 33 | Schéma du socle des bâtiments 3D du MNR ................................................................................. 34

Figure 34 | Superposition du MNT raster initial de la route et du MNR .................................................. 36

Figure 35 | Problème de topologie lors de l’export au format Shapefile .................................................. 36

Figure 36 | Illustration du problème d’intersection des lignes de ruptures et de la triangulation

en résultant ........................................................................................................................................................................ 37

Figure 37 | Descente de parking avant édition ................................................................................................... 38

Figure 38| Descente de parking après édition .................................................................................................... 38

Figure 39 | Ruelle avant (à gauche) et après édition (à droite) ................................................................... 39

Figure 40 | Edition manuelle des lignes de ruptures ....................................................................................... 39

Figure 41 | Propriétés des images du SEMO ........................................................................................................ 39


62

Figure 42 | Construction des pyramides par défaut ......................................................................................... 40

Figure 43| Type du pixel .............................................................................................................................................. 40

Figure 44 | Géoréférencement grâce au cadre de la photo ........................................................................... 41

Figure 45 | Différences entre deux niveaux de représentation d’un arbre ............................................. 42

Figure 46 | Différences MNGE / MN03 dans SketchUp .................................................................................... 43

Figure 47 | « Writers » FME utiles ........................................................................................................................... 44

Figure 48 | « Transformer » TINGenerator ............................................................................................................ 44

Figure 49 | « Transformer » 3DAffiner spécifique au format OBJ ................................................................ 44

Figure 50 | Script FME pour convertir un MNR au format OBJ .................................................................... 45

Figure 51 | Import Shapefile de RhinoTerrain .................................................................................................... 45

Figure 52 | Maillage du MNR à partir des lignes et points avec RhinoTerrain ....................................... 45

Figure 53 | Maquette blanche .................................................................................................................................... 47

Figure 54 | Maquettes techniques ............................................................................................................................ 48

Figure 55 | Mise en évidence des routes : croquis et maquette numérique ........................................... 49

Figure 56 | Maquette photoréaliste ......................................................................................................................... 49

Figure 57 | Couronne d’horizon { l’arrière plan ................................................................................................. 49

Figure 58 | Vue piétonne habillée ............................................................................................................................ 49

Figure 59 | Socle urbain 3D (a) et deux projets de construction hypothétiques (b et c) .................. 50

Figure 60 | Différents rendus avant/après insertion du projet ................................................................... 51

Figure 61 | Repérage des points aberrants (en rouge) .................................................................................. 52

Figure 62 | Répartition des écarts MNR/Lidar sur tout le MNR .................................................................. 53

Figure 63 | Aperçu du PDF 3D du quartier du CMU .......................................................................................... 56

Figure 64 | Interface de la plateforme 3D immersive ...................................................................................... 57

TABLE DES TABLEAUX

Tableau 1 | Poids des données…………………………………………………………………………………………….. 46

Tableau 2 | Résultats de l’analyse statistiques des écarts MNR/Lidar………………………………….… 52

SOMMAIRE DES ANNEXES

Annexe 1 : Organigramme du Département de l'Intérieur et de la Mobilité (DIM)…..…... A2

Annexe 2 : Données 3D du GeoExtracteur……………………………………………………………………… A3

Annexe 3 : Le projet VirtualEarth aux Etats Unis…………………………………………………………… A4

Annexe 4 : Veille technologique et sondage…………………………………………………………………… A5

Annexe 5 : Carte de situation de la région genevoise…………………………………………………… A10

Annexe 6 : Fiche d’information……………………………………………………………………….…………… A11

Annexe 7 : Script global de l’outil MNR_auto………………………………………………………………… A13

Annexe 8 : Schéma récapitulatif………………………………………..………………………………….……… A14

Annexe 9 : Réalisations dans différents logiciels…………………………………………………………. A16

Annexe 10 : Insertion d’une maquette dans un socle urbain 3D………………………………….. A18

Annexe 11 : Dépliant……………………………………………………………………………………….…………… A22


63

BIBLIOGRAPHIE

Articles, revues et ouvrages :

Banaszak[2008] : Banaszak, O et Koehl, M. [2008], SIG et 3D au service des collectivités

territoriales : l’expérience de la ville du Havre. Revue XYZ n°114. Edition AFT. p. 50-58/80.

Forket[2008], Création, administration et utilisation d’un modèle urbain numérique en 3D.

Revue XYZ n°114. Edition AFT. p. 43-49/80.

Donzé, O. et al. [2010] : Donzé, O., Benmansour, Y. et Gervais, F.[2010], Activités 3D présentes et

futures de l’hepia et de la HEIG-VD. Revue Géomatique suisse du 09/2010.

Halbout[2009] : Halbout, H. [2009], Aménagement du territoire. Tome 1. Imagina, la 3D au

service des collectivités. 72p.

Halbout[2010] : Halbout, H. [2010], Aménagement du territoire. Tome 2. Imagina, la 3D au

service des collectivités. 88p.

Koehl[2008] : Koehl, M. et Lott, C. [2008], De la maquette 3D au SIG 3D pour la gestion du

patrimoine archéologique. . Revue Geomatique expert n°64. Edition CiMax p. 26-35/80.

Laurini[2008] : Laurini, R et Servigne, S. [2008], Panorama des potentialités SIG en 3

dimensions. Revue XYZ n°114. Edition AFT. p. 24-28/80.

McCabe, C.[2011], Creating and Texturing Multipatch Features. ArcUser Magazine. Editions esri,

p.8-13/70.

Niggeler[2009] : Niggeler, L., Donzé, O., Benmansour, Y. et Tranchellini, M. [2009], Genève entre

dans l’ère de la 3D. Revue Geomatique Expert n°70. Edition CiMax. P38-42/ 80.

Noirot, T. [2009], Etude sur l’utilisation et l’impact des données tridimensionnelles en matière

d’aménagement du territoire sur le canton de Genève. Mémoire d’ingénieur de l’INSA de

Strasbourg, spécialité Topographie, 60p.

Semichon[2011] : Semichon, S. [2011], L’information géographique cherche la bonne formule

numérique. Revue Urbanisme n°376. Edition Thierry Paquot. p. 55-57/98.

Thébaud[2003] : Thébaud, P. [2003], Carnet de voyages: paysage partagé. Editions de Kerlan.

190 p.

Vannes[2010] : Vannes, N. [2010], Gestion du mobilier urbain 3D en relation avec le SIG

cantonal. Mémoire d'ingénieur de l'INSA de Strasbourg, spécialité Topographie, 60 p.

VieiraDeMelo[2006] : VieiraDeMelo, A. [2006], Projet 3D-MO : Projet de levé de la troisième

dimension dans la mensuration officielle. Rapport final. 119 p.


64

Sites internet :

etatge@[2011] http://www.geneve.ch/welcome.html Geodatanetwork@[2011] http://www.geodatanetwork.ch/ COWI@[2011] http://www.cowi.com/menu/home/Pages/cowi-group.aspx Implenia@[2011]

http://www.implenia.ch/fr-ch/

LeHavre[2011] http://sigu3d.ville-lehavre.fr/ businesslocationcenter@[2011] http://www.businesslocationcenter.de/de 3DOK@[2011]

http://www.3dok.org AutoDesk@[2011] http://www.autodesk.fr/adsk/servlet/pc/index?siteID=458335&id=16806726&src=OMSE OSGeo@[2011]

http://www.opengeospatial.org/standards/citygml GraphiSoft@[2011]

http://www.graphisoft.com/ ESRI@[2011]

http://www.esrifrance.fr/ citygml@[2011]

http://www.citygml.org/ GVA@[2011]

http://www.geo-vision-avenir.com/ Construction@[2011]

http://www.ge.ch/construction/demarches-prealables/autorisations-construire.asp Spatial@[2011]

http://www.spatial.ch/details.php?id=93 Shapefile@[1998]

http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf

http://www.geneve.ch/welcome.html

http://www.geodatanetwork.ch/

http://www.cowi.com/menu/home/Pages/cowi-group.aspx

http://www.implenia.ch/fr-ch/

http://sigu3d.ville-lehavre.fr/

http://www.businesslocationcenter.de/de

http://www.3dok.or/

http://www.autodesk.fr/adsk/servlet/pc/index?siteID=458335&id=16806726&src=OMSE

http://www.opengeospatial.org/standards/citygml

http://www.graphisoft.com/

http://www.esrifrance.fr/

http://www.citygml.org/

http://www.geo-vision-avenir.com/

http://www.ge.ch/construction/demarches-prealables/autorisations-construire.asp

http://www.spatial.ch/details.php?id=93

http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf


65

LISTE DES ABREVIATIONS

2D : 2 dimensions

3D : 3 dimensions

AFT : Association Française de Topographie

AGG : Association des Géomètres Genevois

BIM : Building Information Modeling

CMU.: Centre Médical Universitaire

DCTI : Département des Constructions et des Technologies de l’Information

DGI : Direction Générale de l’Intérieur

DIM : Département de l’Intérieur et de la Mobilité

FME : Feature Manipulation Engine

GVA : Geo Vision Avenir

HEPIA : Haute Ecole du Paysage, d’Ingénierie et d’Architecture

IGN : Institut Géographique National

LoD : Level of Details

MIP : Modélisation Informatique du Paysage

MNR : Modèle Numérique de Rue

MNT : Modèle Numérique de Terrain

OSGeo : Open Soucre Geospatial

PFE : Projet de Fin d’Etudes

PRAM : Projet Relief Auguste Magnin

SEMO : Service de la Mensuration Officielle

SIGU : Système d’Information Géographique Urbain

SITG : Service d’Information du Territoire Genevois

SOSI : Service de l’Organisation des Systèmes d’Information

TIN : Triangular Irregular Network (RTI en francais : Réseau de Triangles Irréguliers)

TPG : Transports Publics Genevois

des données 3d pour les architectes, urbanistes et...

Documents