– Import / Export SIGA3D

Cette partie est l’implémentation technique du processus d’import. Le but est ici d’extraire tous les objets décrits dans les sources de données, qu’ils soient décrits explicitement (comme dans les IFC) ou non (comme dans les DWG par exemple), et d’établir des relations entre ceux-ci. On cherche à récupérer ou créer un identifiant pour chaque objet identifié de manière à traiter et importer l’information. Cette couche d’import est fortement liée aux niveaux supérieurs de l’architecture SIGA3D de modélisation et stockage de l’information.

En effet, les types d’objets et relations dont nous avons besoin pour la reconnaissance des objets sont décrits dans ces niveaux. Pour connaître l’information que nous devons importer, et faire la correspondance avec les objets types définis, nous utilisons des fichiers de mappage. Ces fichiers sont également utilisés pour résoudre l’hétérogénéité syntaxique que nous pouvons rencontrer avec les nombreuses sources de données utilisables.

Un exemple de fichier de mappage IFC est donné dans le Script 41. Nous y décrivons les correspondances entre les objets de type BuildingStorey dans Active3D et les objets IfcBuildingStorey des fichiers IFC. Le principe est de décrire dans ce fichier de mappage comment les objets d’un format particulier peuvent être intégrés et utilisés dans l’architecture Active3D. En l’occurrence, nous avons construit notre ontologie avec, entre autres, le concept d’étage (building storey), des relations entre ces étages (hasName), et le concept de nom d’étage. Il nous suffit alors d’instancier ces deux concepts avec les objets que nous trouvons dans le fichier IFC.

Chaque nœud du graphe de l’ontologie est identifié. En faisant de même pour tous les concepts qui nous intéressent, nous pouvons importer automatiquement le niveau factuel de notre ontologie depuis des fichiers IFC. .[Label] .[Name] .[Label] \RelProperties.conteneur-IfcPropertySet.1- (IfcPropertySingleValue{Name=ComputedArea}.[Value] 

Data Model Framework de SIGA3D

Ce niveau de l’architecture contient les outils pour modéliser et construire une ontologie dynamique. Elle est une extension des travaux précédents d’Active3D pour la construction d’un BIM avec C-DMF. Cette couche est détaillée dans la partie de formalisation de l’approche dont l’aperçu ici est rapide. L’information de ce niveau est basée sur des opérateurs qui servent à construire un modèle de données générique (éléments sémantiques, relations et ressources).

L’objectif de cette partie est de pouvoir définir une structure de graphe dans laquelle il est possible d’importer différents modèles provenant de formats de données divers telles que les IFC ou CityGML. Ceux-ci peuvent alors être fusionnés (interopérabilité sémantique pour faire correspondre, par exemple, un IFCWall avec un élément CityGML WallSurface). La consistance des modèles définis à ce niveau est vérifiée dans le niveau supérieur, CMF.

Les données sont traitées en fonction de trois grands axes : informations sémantiques, informations géométriques et les informations spatio-temporelles. Cette dernière catégorie est issue des SIG et des besoins spécifiques que nous avons de gérer ce type d’information. Il est notamment possible de les utiliser pour définir des contextes locaux qui autorisent la définition d’un concept de plusieurs manières, dépendamment du contexte local associé : c’est la base de nos travaux sur la multireprésentation et les niveaux de détail contextuels.

Les concepts définis par le bloc spatio-temporel de l’architecture vont être réutilisés dans la couche supérieure de l’architecture afin de synchroniser les modèles de données. La synchronisation spatiale et temporelle consiste à définir des propriétés de modèles qui ne varient pas en fonction des systèmes de référence utilisés pour la description des données. On peut ainsi définir des relations entre deux modèles telles que l’adjacence, l’inclusion, l’ordre (avant, après)… ce mécanisme est détaillé plus en détail dans la section de formalisation de la couche contextuelle de l’architecture SIGA3D.

Enfin, la couche géométrique est utilisée à deux desseins : organiser l’information spatiale sous forme de graphe de scène, et définir la structure des index spatiaux. Ce dernier point étant primordial pour les Chapitre 5. Architecture de Processus SIGA3D Mémoire de Thèse Page 143 performances de la plateforme SIGA3D, nous allons faire un rapide rappel sur les index spatiaux et voir comment nous pouvons les gérer dans cette partie.

La gestion spatiale des objets urbains

L’objectif de cette section est de comprendre la manière dont sont organisés, au sein de SIGA3D, les objets géographiques. La majorité de ceux-ci sont, à l’origine, indépendants spatialement les uns des autres (c’est-àdire que lorsque l’on importe un objet depuis une source quelconque, un IFC par exemple, celui-ci ne possède pas forcément de relations spatiales avec les autres objets déjà importés).

Le but étant de pouvoir afficher en temps réel des environnements urbains, composés par ces objets géographiques, il faut optimiser les requêtes géographiques afin de répondre aux besoins de requêtes des objets de manière dynamique depuis la base de données et d’affichage des scènes. La scène de l’environnement 3D que l’on souhaite afficher est gérée de manière hiérarchique afin de pouvoir utiliser les mécanismes de simplification de scènes que nous décrivons dans le paragraphe sur les niveaux de détail hiérarchiques.

Cette hiérarchie lie les objets que l’on souhaite afficher par des relations de contenance. Ces relations, qui n’existent pas lorsque l’on acquiert l’objet (créé manuellement ou importé automatiquement comme décrit dans le paragraphe précédent) peuvent être définies de plusieurs manières, par le biais des index spatiaux. Les index spatiaux permettent, au sein d’une base de données spatiale, d’optimiser les temps de réponse des différentes requêtes en autorisant une sélection rapide des données sur lesquelles elles portent.

La plupart des index utilisés aujourd’hui ont été définis pour l’étude de l’espace à deux dimensions, mais peuvent s’adapter à la troisième dimension. Selon (Ramos, 2003), l’optimisation se fait au travers de deux objectifs : La définition d’une structure de données pour avoir un accès plus rapide à l’information, Le regroupement d’information afin que les données qui sont proches dans la réalité le soient également en mémoire.