Modèle de données LRS

Disponible avec la licence Location Referencing.

Le système de référencement linéaire (LRS) est une collection de classes d’entités et de tables qui permettent de stocker et de mettre à jour des itinéraires calibrés.

Le LRS prend en charge l’utilisation d’une classe d’entités polylignes (appelées axes médians) unique pour stocker la géométrie de plusieurs itinéraires. La géométrie des axes médians, ainsi que les définitions d’itinéraire, sont stockées dans une classe d’entités de réseau.

Une relation plusieurs vers plusieurs existe entre les itinéraires dans le réseau et les axes médians fournissant la géométrie. En d’autres termes, les itinéraires sont généralement composés de plusieurs entités d’axe médian, et les entités d’axe médian peuvent faire partie de plusieurs itinéraires dans plusieurs réseaux.

Modèle de données LRS

En plus d’une géométrie, les itinéraires doivent également posséder des mesures. Les mesures sur les itinéraires sont utilisées par LRS pour afficher les couches d’événements aux emplacements appropriés sur une carte. Elles sont ajoutées aux itinéraires via un processus appelé calibrage. Pour contrôler explicitement le mode de calibrage des itinéraires, le LRS utilise une classe d’entités de point de calibrage.

Les points de calibrage sont des entités ponctuelles qui stockent les valeurs de mesure, les références d’itinéraire et les ID de réseau. La combinaison de ces trois éléments constitue une méthode de référencement linéaire (LRM). Les LRM sont créées en appliquant des points de calibrage à des itinéraires afin de créer un réseau LRS.

Le LRS est constitué des classes d’entités et des tables suivantes :

  • Axes médians : classe d’entités polylignes qui stocke la géométrie des itinéraires.
  • Séquence d’axes médians : table de références croisées qui gère la relation entre les axes médians et les itinéraires.
  • Point de calibrage : classe d’entités ponctuelles qui stocke les valeurs de mesure des itinéraires.
  • Annotation redline : classe d’entités polylignes qui stocke les entités d’annotation pour communiquer les modifications du LRS.
Remarque :

Les classes d’entités et les tables sont créées avec tous les champs requis lors de l’exécution de l’outil Créer un LRS.

Conditions requises pour le jeu de classes d’entités

Pour prendre en charge la mise à jour basée sur les services des données dans Roads and Highways, certaines classes d’entités du modèle de données LRS doivent se trouver dans un jeu de classes d’entités d’une géodatabase. Si les classes d’entités et les tables sont modélisées à l’avance, les classes d’entités suivantes doivent être incluses dans un jeu de classes d’entités :

  • Points de calibrage
  • Axe médian
  • Evénements
  • Intersections
  • Réseaux
  • Annotation Redline

Remarque :
  • Si vous utilisez l’outil Créer un LRS pour créer votre LRS ainsi que le minimum d’éléments de structure, ces classes d’entités obligatoires sont automatiquement placées dans un jeu de classes d’entités.
  • Si le LRS a été créé dans ArcMap ou ArcGIS Pro 2.2 ou une version précédente, vous devez déplacer ces classes d’entités dans un jeu de classes d’entités et exécutez l’outil Modifier le LRS afin de mettre à jour le LRS dans ArcGIS Pro 2.3 ou version ultérieure.

Conditions requises pour la gestion des versions

Les données LRS que vous publiez en tant que service doivent utiliser le versionnement de branche. De plus, la fonctionnalité de gestion des versions doit être activée lors de sa publication en tant que service.

Les champs supplémentaires requis pour la gestion des versions, comme le champ des ID globaux, doivent être ajoutés à toutes les classes d’entités et tables LRS avant la publication.

En savoir plus sur l’inscription d’un jeu de données avec les conditions requises pour le versionnement de branche

En savoir plus sur la publication avec le référencement linéaire et la gestion des versions

jeu de données LRS

Un jeu de données de système de référencement linéaire (LRS) est un jeu de classes de contrôleur dans un jeu de classes dentités dans la géodatabase avec toutes les classes dentités qui participent au LRS.

Remarque :

Vous pouvez visualiser la hiérarchie LRS dans la fenêtre Contents (Contenu) ou Catalog (Catalogue).

Les outils suivants permettent de créer un jeu de données LRS, à compter d’ArcGIS Pro 2.3 :

  • Créer un LRS - Les classes d’entités d’axe médian, de point de calibrage et d’annotation Redline nouvellement créées sont placées dans un jeu de classes d’entités portant le même nom que le nom LRS fourni.
  • Créer un LRS à partir d’un jeu de données existant - Les classes d’entités d’axe médian, de point de calibrage et d’annotation redline qui ne sont pas encore inscrites auprès d’un LRS doivent se trouver dans un jeu de classes d’entités commun. Le nom du jeu de classes d’entités peut être différent du nom du LRS.
  • Modifier un LRS - Les classes d’entités d’axe médian, de point de calibrage et d’annotation redline qui sont inscrites auprès d’un LRS doivent se trouver dans un jeu de classes d’entités commun. Le nom du jeu de classes d’entités peut être différent du nom du LRS.

Le jeu de données LRS est requis pour exécuter les outils suivants :

Vous pouvez lire certaines informations contenues dans le jeu de données LRS à l’aide d’une fonction arcpy.Describe. Pour lire les métadonnées LRS et les règles de comportement d’événement d’une géodatabase avec un jeu de données de contrôleur LRS, utilisez les fonctions suivantes :

FileGDB :


desc = arcpy.Describe("C:\\Data\\LRData\\LrsSchema.gdb\\Lrs\\Lrs")

lrsXML = desc.lrsMetadata

eventBehaviors = desc.eventBehaviorRules

EnterpriseGDB :


desc = arcpy.Describe("C:\\Data\\LRData\\LrsSchema.sde\\GPRefresh.DBO.LRS\\GPRefresh.DBO.LRS")

lrsXML = desc.lrsMetadata

eventBehaviors = desc.eventBehaviorRules

Écriture dans un fichier :


txtFile = open("C:\\Data\\LRData\\lrsXML.xml", "w")

txtFile.write(lrsXML)

txtFile.close()

Classe d’entités d’axes médians

La classe d’entités d’axe médian fournit une source unique de géométrie pour tous les réseaux LRS que vous avez construits dans un LRS.

Chaque entité dans une classe d’entités d’axe médian représente une unité unique de l’autoroute. Ces entités peuvent être utilisées pour représenter une relation un vers un avec des itinéraires ou être combinées pour former des itinéraires plus longs.

Remarque :

Les paramètres de tolérance et de résolution de la classe d’entités d’axe médian sont propagés aux réseaux, intersections et classe d’entités d’événement inscrits auprès de ArcGIS Roads and Highways. La référence spatiale, la résolution et la tolérance x,y ainsi que la résolution et la tolérance z de la classe d’entités d’axe médian doivent correspondre à celles des itinéraires source qui seront utilisés pour charger des données dans votre LRS.

Remarque :

La classe d’entités d’axe médian doit prendre en charge les valeurs Z.

Le LRS exige que la classe d’entités d’axe médian possède un champ d’ID d’axe médian. Les outils Créer un LRS et Créer un LRS à partir d’un jeu de données existant vous permettent d’apparier un champ d’ID d’axe médian.

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

ID d’axe médian

GUID

Oui

ID unique de la géométrie d’axe médian

Remarque :

Le champ Centerline ID est un champ géré par le système qui est rempli automatiquement par les outils ArcGIS Roads and Highways. Vous ne devez pas le mettre à jour manuellement.

Table de séquences d’axe médian

La relation plusieurs vers plusieurs entre des itinéraires et des axes médians est gérée par le biais d’une table de références croisées appelée table séquentielle d’axes médians. Étant donné que les itinéraires ne sont pas uniques dans le LRS, la table séquentielle d’axes médians contient également une référence au champ d’ID de réseau du réseau LRS. La combinaison de l’ID de réseau et de l’ID d’itinéraire permet d’identifier de façon unique chaque itinéraire dans le LRS. L’utilisation de l’ID de réseau permet de distinguer les LRM, étant donné que les ID d’itinéraire peuvent ne pas être uniques dans les réseaux.

Une entité d’axe médian peut faire partie de plusieurs itinéraires et un itinéraire peut être constitué de plusieurs axes médians. La table séquentielle d’axes médians doit contenir au moins un enregistrement pour chaque combinaison d’axe médian et de réseau.

Les champs minimaux pour la table séquentielle d’axes médians sont les suivants :

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

ID d’axe médian

GUID

Oui

ID unique de la géométrie d’axe médian.

Date de début

Date

8

Oui

Date à laquelle la portion de l’axe médian devient active.

Date de fin

Date

8

Oui

Date à laquelle la portion de l’axe médian sera retirée.

ID d'itinéraire

Chaîne

Valeur 255 suggérée ; égale ou supérieure à la longueur du champ Route ID le plus long dans les réseaux.

Oui

ID unique de l’itinéraire.

ID de réseau

Entier court

5

Oui

ID unique du réseau LRS dont fait partie chaque itinéraire.

Remarque :

Vous ne devez pas mettre à jour manuellement les enregistrements dans la table séquentielle d’axes médians.

Remarque :

Le champ Network ID est inscrit dans le domaine de valeurs précodées dLRSNetworks lorsque le LRS est créé.

Classe d’entités de point de calibrage

Les mesures d’itinéraire sont affectées à des itinéraires dans le réseau à l’aide de la classe d’entités de point de calibrage. Les routes sont calibrées en calculant une distance interpolée entre deux points de calibrage quelconques sur l’itinéraire. Les points de calibrage sont propres à un réseau LRS et comprennent le composant de mesure de la LRM. Les règles relatives aux points de calibrage sont les suivantes :

  • Il n’existe qu’une seule classe d’entités de point de calibrage pour tous les réseaux LRS inscrits auprès du LRS.
  • Au moins deux points de calibrage sont requis pour chaque itinéraire.
  • Les points de calibrage doivent être monotoniques, ce qui signifie que leur mesure doit augmenter ou diminuer strictement le long d’un itinéraire. Les itinéraires non monotoniques sont calibrés mais peuvent générer des emplacements d’événement et des comportements d'’événement indéfinis.
  • Ajoutez un point de calibrage à un emplacement particulier pour gérer une valeur de mesure spécifique.
Remarque :

La classe d’entités de point de calibrage doit posséder les mêmes référence spatiale et tolérance et résolution XY et Z que la classe d’entités d’axe médian.

La classe d’entités de point de calibrage doit prendre en charge les valeurs Z et ne peut pas prendre en charge les valeurs M.

Les champs minimaux pour la classe d’entités de point de calibrage sont les suivants :

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

Mesure

Double

8

Oui

Valeur de mesure stockée pour des itinéraires dans un réseau LRS.

Date de début

Date

8

Oui

Date à laquelle le point de calibrage devient actif.

Date de fin

Date

8

Oui

Date à laquelle le point de calibrage sera retiré.

ID d'itinéraire

Chaîne

Même longueur que le champ Route ID dans la table séquentielle d’axes médians.

Non

ID unique de l’itinéraire.

ID de réseau

Entier court

5

Oui

ID unique du réseau LRS.

Remarque :

Le champ Network ID est inscrit dans le domaine de valeurs précodées dLRSNetworks lorsque le LRS est créé.

Utilisez l’outil Générer des points de calibrage pour générer des points de calibrage.

Classe d’entités d’annotation redline

La classe d’entités d’annotation redline contient les informations de base nécessaires pour effectuer de nombreuses fonctions de mise à jour d’itinéraire disponibles dans Roads and Highways. L’entité d’annotation redline peut être considérée comme un espace réservé pour une opération de mise à jour d’itinéraire ultérieure. Elle est utilisée comme entité d’annotation pour que vous n’ayez pas à gérer le LRS. Elle peut interrompre votre processus afin de rechercher les différences entre le LRS et le monde réel. Au lieu d’arrêter de travailler et d’attendre que le LRS soit mis à jour, vous pouvez entrer une entité d’annotation redline dans la géodatabase pour indiquer l’endroit auquel doit se trouver l’itinéraire, notifier l’équipe SIG et continuer d’utiliser les données d’événement.

Remarque :

La classe d’entités d’annotation redline doit posséder les mêmes référence spatiale et tolérance et résolution XY que la classe d’entités d’axe médian.

La classe d’entités d’annotation redline doit prendre en charge les valeurs Z et ne peut pas prendre en charge les valeurs M.

Les champs minimaux pour la classe d’entités d’annotation redline sont les suivants :

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

Mesure de départ

Double

8

Oui

Mesure de départ du changement d’alignement.

Mesure d’arrivée

Double

8

Oui

Mesure d’arrivée du changement d’alignement.

ID d'itinéraire

Chaîne

Même longueur que le champ Route ID dans la table séquentielle d’axes médians.

Non

ID unique de l’itinéraire cible.

Nom de l\'itinéraire

Chaîne

12

Oui

Nom de l’itinéraire.

Date d’effet

Date

8

Oui

Date d’effet du changement d’itinéraire. La date sera appliquée aux événements affectés par le changement.

Type d’activité

Entier court

5

Oui

Opération de mise à jour à effectuer, comme prolonger un itinéraire.

ID de réseau

Entier court

5

Oui

ID unique du réseau LRS.

Remarque :

Le champ Network ID est inscrit dans le domaine de valeurs précodées dLRSNetworks et le champ Activity Type est inscrit dans le domaine de valeurs précodées dActivityType lorsque le LRS est créé.

Vous pouvez entrer des annotations redline spécifiques ou générales. Il est prévu qu’un analyste SIG vérifie l’entité d’annotation redline et s’assure qu’une géométrie exacte est entrée dans la base de données. Une annotation redline esquissée approximativement indique qu’un changement du LRS est requis et fournit son emplacement général.

Classe d’entités de réseau

La classe d’entités de réseau contient les entités d’itinéraire utilisées dans le LRS. Ces itinéraires possèdent des attributs, une géométrie issue de la classe d’entités d’axe médian et un calibrage issu de la classe d’entités de point de calibrage.

Ensemble, ces éléments constituent un itinéraire dans la LRM, qui peut être utilisée pour localiser des événements sur cet itinéraire. Chaque itinéraire doit posséder un identifiant d’itinéraire unique appelé ID d’itinéraire.

Les données du champ d’ID d’itinéraire doivent être cohérentes dans l’ensemble des réseaux, événements et classes d’entités de point de calibrage et dans la table séquentielle d’axes médians.

Le type de données du champ Route ID doit être cohérent dans l’ensemble des réseaux, événements, annotations redline et classes d’entités de point de calibrage et dans la table séquentielle d’axes médians.

Remarque :

Si la classe d’entités de réseau est modélisée avant la création du LRS, assurez-vous que les tolérances et résolutions XY et Z correspondent à celles de la classe d’entités d’axe médian. La tolérance et la résolution M pour le réseau reposent sur les unités de mesure de la référence spatiale pour la classe d’entités de réseau et les unités de mesure pour le LRM utilisé. Si les unités de mesure sont identiques, la tolérance et la résolution M sont les mêmes que la tolérance et la résolution XY. Si les unités de mesure sont différentes, vous devez convertir la tolérance et la résolution XY en tolérance et résolution M correspondantes.

Par exemple, votre classe d’entités de réseau possède une référence spatiale exprimée en mètres, avec une tolérance YX de 0,001 mètres et une résolution XY de 0,0001 mètres. Si les unités de mesure du LRM sont le mètre, la tolérance M est alors de 0,001 et la résolution M de 0,0001. Toutefois, si les unités de mesure du LRM sont le kilomètre, les valeurs de tolérance et de résolution XY doivent être converties de mètres en kilomètres pour la tolérance et la résolution M. Dans cet exemple, la tolérance m serait égale à 0,000001 et la résolution à 0,0000001.

En savoir plus sur la configuration de la tolérance et de la résolution pour le réseau LRS

Les champs minimaux pour la classe d’entités de réseau sont les suivants :

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

Date de début

Date

8

Oui

Data à laquelle la portion de l’axe médian devient une partie active de l’itinéraire.

Date de fin

Date

8

Oui

Date à laquelle la portion de l’axe médian devient une partie retirée de l’itinéraire.

ID d'itinéraire

Chaîne

Même longueur que le champ Route ID dans la table séquentielle d’axes médians.

Non

ID unique de l’itinéraire.

Remarque :

Vous ne devez pas mettre à jour directement les champs de la classe d’entités de réseau. Ceux-ci sont gérés par Location Referencing.

Les champs suivants doivent être configurés si vous utilisez un ID d’itinéraire multichamp composé de plusieurs autres champs dans la classe d’entités de réseau :

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

Champs comprenant le champ Route ID.

Chaîne, entier court et entier long

Inférieure ou égale à la longueur du champ Route ID

Oui

Champs comprenant l’ID d’itinéraire concaténé pour le réseau. Chaque champ doit être modélisé séparément dans la classe d’entités de réseau.

Les champs suivants doivent être configurés pour un réseau linéaire avec un ID d’itinéraire à plusieurs champs :

Remarque :

Il est recommandé de configurer un ordre de ligne avec des incréments de 100. Dans une configuration de ce type, le premier itinéraire est associé à l’ordre de ligne 100. L’ordre de ligne augmente par incrément de 100 pour chaque itinéraire se trouvant sur la même ligne (100, 200, 300, etc.).

TerrainType de donnéesLongueurAccepte les valeurs nullesDescription

Identifiant de ligne

Chaîne ou GUID

Même type et même longueur que le champ d’ID d’itinéraire dans la table séquentielle d’axes médians

Oui

ID unique de la ligne

Ordre de ligne

Long

Oui

Ordre de l’itinéraire sur la ligne

Evénements

En savoir plus sur le modèle de données relatif aux événements

En savoir plus sur la création d’une classe d’intersection LRS