Créer un jeu de données à l’aide d’un package GeoJson (préversion)
Remarque
Mise hors service d’Azure Maps Creator
Le service de cartographie intérieure Azure Maps Creator est désormais déconseillé et sera mis hors service le 30/09/25. Pour plus d’informations, consultez l’Annonce de la fin de vie d’Azure Maps Creator.
Azure Maps Creator permet aux utilisateurs d’importer leurs données de carte d’intérieur au format GeoJSON avec Facility Ontology 2.0, qui peuvent ensuite être utilisées pour créer un jeu de données.
Prérequis
- Compte Azure Maps
- Une Clé d’abonnement
- Ressource Azure Maps Creator
- Un compte de stockage Azure
- Notions de base de Creator pour les cartes d’intérieur
- Notions de base de Facility Ontology 2.0
- Package zip contenant tous les fichiers GeoJSON requis. Si vous n’avez pas de fichiers GeoJSON, vous pouvez télécharger l’exemple de bâtiment Contoso
Important
- Cet article utilise l’URL géographique
us.atlas.microsoft.com
. Si votre service Creator n’a pas été créé aux États-Unis, vous devez utiliser une autre URL géographique. Pour plus d’informations, consultez Accès aux services Creator. - Dans les exemples d’URL de cet article, vous devez remplacer
{Your-Azure-Maps-Subscription-key}
par votre clé d’abonnement Azure Maps.
Créer un jeu de données à l’aide du package GeoJSON
Pour plus d’informations sur le package GeoJSON, consultez la section Exigences relatives au package zip Geojson.
Charger le package GeoJSON
Suivez les étapes décrites dans l’article Procédure de création d’un registre de données pour charger le package GeoJSON dans votre compte de stockage Azure, puis enregistrez-le dans votre compte Azure Maps.
Important
Assurez-vous de noter la valeur de l'identifiant unique (udid
), vous en aurez besoin. Le udid
est le moyen de référencer le paquet GeoJSON chargé dans votre compte de stockage Azure à partir de votre code source et de vos requêtes HTTP.
Créer un jeu de données
Un jeu de données est une collection de caractéristiques cartographiques, telles que des bâtiments, des niveaux et des salles. Pour créer un jeu de données à partir de votre GeoJSON, utilisez la nouvelle API de création de jeu de données. L’API de création de jeu de données prend le udid
que vous avez obtenu dans la section précédente, et retourne le datasetId
du nouveau jeu de données.
Important
Cette version diffère de la version précédente de l’API Création de jeu de données, car cela ne nécessite pas de conversionId
d’un package de dessin converti.
Pour créer un jeu de données :
- Entrez l’URL suivante vers le service de jeu de données. La requête doit ressembler à l’URL suivante (remplacez {udid} par le
udid
obtenu dans la section Télécharger le package GeoJSON) :
https://us.atlas.microsoft.com/datasets?api-version=2023-03-01-preview&udid={udid}&subscription-key={Your-Azure-Maps-Subscription-key}
- Copiez la valeur de la clé
Operation-Location
dans l’en-tête de réponse. La cléOperation-Location
est également appeléestatus URL
, et elle est nécessaire pour vérifier l’état du processus de création du jeu de données et pour obtenir ledatasetId
, qui est requis pour créer un tileset.
Vérifier l’état de la création du jeu de données
Pour vérifier l’état du processus de création du jeu de données et récupérer le datasetId
:
Entrez l’URL d’état que vous avez copiée dans Créer un jeu de données. La requête doit ressembler à l’URL suivante :
https://us.atlas.microsoft.com/datasets/operations/{operationId}?api-version=2023-03-01-preview&subscription-key={Your-Azure-Maps-Subscription-key}
Dans l’en-tête de la réponse HTTP, copiez la valeur de l’identificateur unique contenu dans la clé
Resource-Location
.https://us.atlas.microsoft.com/datasets/**c9c15957-646c-13f2-611a-1ea7adc75174**?api-version=2023-03-01-preview
Ajouter des données à un jeu de données existant
Vous pouvez ajouter des données à un jeu de données existant en fournissant le paramètre datasetId
à l’API de création de jeu de données ainsi que l’identificateur unique des données que vous souhaitez ajouter. L’identificateur unique peut être un udid
ou conversionId
. Cela crée un jeu de données composé des données (installations) provenant du jeu de données existant et des nouvelles données importées. Une fois le nouveau jeu de données créé avec succès, l’ancien jeu de données peut être supprimé.
L’un des éléments à prendre en compte lors de l’ajout à un jeu de données existant est la façon dont les ID de caractéristiques sont créés. Si un jeu de données est créé à partir d’un package de dessin converti, les ID de caractéristiques sont générés automatiquement. Lorsqu’un jeu de données est créé à partir d’un package GeoJSON, les ID de caractéristiques doivent être fournis dans le fichier GeoJSON. Lors de l’ajout à un jeu de données existant, le jeu de données d’origine détermine comment les ID de caractéristiques sont créés. Si le jeu de données d’origine a été créé à l’aide d’un udid
, il utilise les ID du GeoJSON, et continuera à le faire avec tous les packages GeoJSON ajoutés à ce jeu de données à l’avenir. Si le jeu de données a été créé à l’aide d’un conversionId
, les ID seront générés en interne et continueront à être générés en interne avec tous les packages GeoJSON ajoutés à ce jeu de données à l’avenir.
Ajouter au jeu de données créé à partir d’une source GeoJSON
Si votre jeu de données d’origine a été créé à partir d’une source GoeJSON et que vous souhaitez ajouter une autre installation créée à partir d’un package de dessin, vous pouvez l’ajouter à votre jeu de données existant en référençant son conversionId
, comme l’illustre cette requête HTTP POST :
https://us.atlas.microsoft.com/datasets?api-version=2023-03-01-preview&conversionId={conversionId}&outputOntology=facility-2.0&datasetId={datasetId}
Identificateur | Description |
---|---|
conversionId | ID retourné lors de la conversion de votre package de dessin. |
datasetId | ID de jeu de données retourné lors de la création du jeu de données d’origine à partir d’un package GeoJSON. |
Exigences relatives au package zip Geojson
Le package zip GeoJSON se compose d’un ou plusieurs fichiers GeoJSON conformes à la norme RFC 7946, un pour chaque classe de caractéristiques, tous dans le répertoire racine (les sous-répertoires ne sont pas pris en charge), compressés avec la compression Zip standard et nommés à l’aide de l’extension .ZIP
.
Chaque fichier de classe de caractéristiques doit correspondre à sa définition dans Facility Ontology 2.0, et chaque caractéristique doit avoir un identificateur global unique.
Les ID de caractéristique peuvent uniquement contenir des caractères alphanumériques (a-z, A-Z, 0-9), des traits d’union (-), des points (.) et des traits de soulignement (_).
Conseil
Si vous voulez être certain que vous disposez d’un identificateur global unique (GUID), créez-le en exécutant un outil de génération de GUID tel que le programme en ligne de commande Guidgen.exe (disponible avec Visual Studio). Guidgen.exe ne génère jamais deux fois le même numéro, quel que soit le nombre de fois qu’il est exécuté ou le nombre de machines différentes sur lesquelles il s’exécute.
Validations de l’ontologie des installations 2.0 dans le jeu de données
Facility Ontology 2.0 définit comment Azure Maps Creator stocke en interne les données d’installation, réparties en classes de caractéristiques, dans un jeu de données Creator. Lors de l’importation d’un package GeoJSON, chaque fois qu’une caractéristique est ajoutée ou modifiée, une série de validations s’exécute. Cela comprend des vérifications d’intégrité référentielle et des validations de géométrie et d’attribut. Ces validations sont décrites plus en détail dans la liste suivante.
- Le nombre maximal de caractéristiques pouvant être importées simultanément dans un jeu de données est de 150 000.
- La superficie des installations peut être comprise entre 4 et 4 000 km².
- L’élément de niveau supérieur est facility, qui définit chaque bâtiment dans le fichier facility.geojson.
- Chaque installation a un ou plusieurs niveaux, qui sont définis dans le fichier levels.goejson.
- Chaque niveau doit se trouver à l’intérieur de l’installation.
- Chaque niveau contient des unités, des structures, des verticalPenetrations et des ouvertures. Tous les éléments définis dans le niveau doivent être entièrement contenus au sein de la géométrie de niveau.
- Une
unit
peut se composer d’un tableau d’éléments tels que des couloirs, des bureaux et des cours, qui sont définis par des éléments area, line ou point. Les unités sont définies dans le fichier unit.goejson.- Tous les éléments
unit
doivent être entièrement contenus dans leur niveau et se croiser avec leurs enfants.
- Tous les éléments
structure
définit des zones physiques qui ne se chevauchent pas et qui ne peuvent pas être traversées, comme un mur. Les structures sont définies dans le fichier structure.goejson.verticalPenetration
représente une méthode de navigation verticale entre les niveaux, tels que des escaliers et des ascenseurs. Les verticalPenetrations sont définies dans le fichier verticalPenetration.geojson.- Les verticalPenetrations ne peuvent pas croiser d’autres verticalPenetrations sur le même niveau.
- Les
openings
définissent des limites traversables entre deux unités, ou uneunit
et uneverticalPenetration
; elles sont définies dans le fichier opening.geojson.- Les openings ne peuvent pas se croiser avec d’autres openings du même niveau.
- Chaque
opening
doit être associée à au moins uneverticalPenetration
ouunit
.
- Une