Exigence du jeu de données de fonctionnalités LRS
Un jeu de données de fonctionnalités est une collection de classes d'entités liées qui partagent un système de coordonnées commun. Les jeux de données de fonctionnalités sont utilisés pour faciliter la création de jeux de données contrôleurs (parfois appelés aussi jeux de données d'extension), tels que la topologie, le réseau utilitaire ou le référencement des pipelines. Les classes d'entités devant être incluses dans un jeu de données d'extension sont d'abord organisées dans un jeu de données de fonctionnalités.
Pour prendre en charge l'édition basée sur les services de vos données dans Pipeline Referencing, certaines classes d'entités du modèle de données LRS doivent résider dans un jeu de données de fonctionnalités dans votre 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 contenues dans un jeu de données de fonctionnalités : Centerline, Calibration Points, Redline, Networks, Events, and Intersections.
Référence : Modèle d'information LRS
Référence spatiale
Lorsqu'un jeu de données de fonctionnalités est créé, vous devez définir sa référence spatiale. Cela inclut le système de coordonnées, soit géographique soit une projection spécifique, ainsi que les unités de coordonnées et les tolérances pour les valeurs x-, y-, z- et m-. Toutes les classes d'entités dans un jeu de données de fonctionnalités doivent partager un système de coordonnées commun, et les coordonnées x,y de leurs entités doivent se situer dans une étendue spatiale commune. Lorsque vous créez une classe d'entités dans un jeu de données existant, le système de coordonnées est hérité du jeu de données.
Étant donné que les mesures et leur précision sont essentielles à la précision de toute méthode de référencement linéaire (LRM), les paramètres de référence spatiale, tolérance et résolution pour toutes ces classes d'entités doivent être alignés. Cela garantit que la géométrie et les mesures des routes, événements et intersections sont correctes dans un système de référencement linéaire (LRS) et restent alignées. Si l'une des classes d'entités centerline, calibration point, redline, network, event ou intersection est modélisée avant son enregistrement avec le LRS, assurez-vous que les paramètres de tolérance et résolution correspondent.
Référence : Paramètres de tolérance et résolution
Considérations pour la mise en œuvre
- Si vous utilisez l'outil géotraitement Create LRS pour créer votre LRS et les éléments minimaux du schéma, ces classes d'entités requises sont automatiquement placées dans un jeu de données.
- Si le LRS a été créé avec ArcMap ou ArcGIS Pro 2.5 ou antérieur, vous devez déplacer ces classes d'entités dans un jeu de données et exécuter l'outil géotraitement Modify LRS pour modifier le LRS dans ArcGIS Pro 2.6 ou ultérieur. Des modifications supplémentaires du schéma et/ou une reconfiguration APR peuvent être nécessaires dans le cadre de ce processus de mise à niveau.
- La solution ArcGIS Gas and Pipeline Enterprise Data Management suit les exigences du modèle d'information LRS avec des entités requises dans le jeu de données UtilityNetwork . Gas and Pipeline Enterprise Data Management est une solution unifiée pour les pipelines en réseau et référencés linéairement basée sur ArcGIS Pro 2.6, ArcGIS Enterprise 10.8.1, UPDM 2020 et Utility Network Release 4.
- Le PODS 7.0 est également compatible avec les exigences du modèle d'information LRS avec des entités requises dans le jeu de données Features .
- Les implémentations APR sur des versions d'ArcGIS Pro 2.5 ou antérieures permettaient aux entités d'être en dehors d'un seul jeu de données. Lors de la mise à niveau vers ArcGIS Pro 2.6, l'administrateur SIG sera invité à exécuter l'outil géotraitement pour Modifier le LRS. L'erreur suivante 130159 apparaîtra si le modèle de données n'est pas modifié selon les exigences du jeu de données discutées ci-dessus.
Intersection LRS
A partir d'ArcGIS Pro 2.6, vous pouvez désormais configurer des classes d'entités intersection LRS ainsi que générer et mettre à jour des intersections. L'exemple ci-dessous montre l'intersection d'une route LRS avec une couche ferroviaire.
Les champs requis pour la classe intersection LRS sont listés dans le tableau suivant.
Champ | Type de donnée | Description |
ID Intersection | Guid | Le nom du champ ID intersection. |
Nom Intersection | Texte (1000) | Le nom de l'intersection. |
ID Route | Texte (1000) | L'ID unique de la route. |
ID Entité | Texte (1000) | L'ID unique de l'entité intersectante. |
Nom Classe Entité | Texte (150) | Le nom de la classe d'entité point intersection. |
Date Début |
Date
|
Date à laquelle le réseau est devenu actif.
|
|
Date Fin
|
Date
|
Date à laquelle le réseau a été retiré.
|
|
Mesure
|
Double
|
La mesure sur la route dominante où se trouve l'intersection.
|
Ceci est un exemple table attributaire pour l'intersection d'une route LRS avec une couche ferroviaire.
Redline
A partir d'ArcGIS Pro 2.8, la classe d'entité redline qui est un objet central du modèle d'information APR, doit être activée en z et ne peut pas être activée en m.
