attribuer un identifiant unique aux entités ponctuelles

La norme de parcelle MassGIS (http://www.mass.gov/mgis/ParstndrdVer1_5_1.pdf) utilise une concaténation du nombre entier de coordonnées x et y pour créer un identifiant unique (LOC_ID) pour les entités. J'envisage de faire de même pour une classe d'entités ponctuelles. J'aime la méthodologie cohérente, mais j'oublie peut-être quelque chose. Existe-t-il une norme ou une meilleure pratique pour créer des identifiants uniques pour les entités ponctuelles?

Si vous utilisez cet identifiant pour quelque chose comme une clé étrangère par rapport à une autre table, toute votre base de données aura de gros problèmes si vous devez déplacer un point pour une raison quelconque. Vous devrez alors probablement conserver l'identifiant même s'il ne décrit plus les coordonnées xy.

En tant que clé unique, il est souvent préférable d'avoir quelque chose qui ne dit rien sur les données, car la plupart des données peuvent changer.

/ Nicklas

Ajout de la réponse de Nicklas et de mon commentaire.

Je dirais que la convention la plus utilisée et la plus recommandée consiste simplement à utiliser un ID d'auto-incrémentation, par exemple commencer à 1 et continuer. Pas de logique et simple.

Si vous avez un système distribué ou que vous n'aimez pas les numéros à incrémentation automatique, vous pouvez utiliser un GUID. La plupart des bases de données gèrent la création de ce type d'ID pour vous. Cependant, il est difficile pour un utilisateur d'entrer manuellement, pour la recherche, etc., alors gardez cela à l'esprit.

L'autre option consiste à utiliser une sorte de hachage des données, mais je ne le recommanderais pas. Cela signifierait que vous auriez besoin d'écrire un algorithme pour le faire pour vous, vous ne pouvez pas toujours garantir l'unicité, ils ont également tendance à être difficiles à saisir pour la recherche.

Ce ne sont que mes opinions, mais d'après mon expérience personnelle, croyez-moi, n'utilisez jamais de données commerciales dans les identifiants.

Question de suivi: est-il préférable de créer et de maintenir l'ID unique dans le SGBD (SQL Server) ou dans le logiciel SIG (ArcGIS)?

Je suggère fortement de vérifier l'unicité à l'intérieur du SGBD. C'est l'une des nombreuses forces des SGBD. Il vous permet également d'accéder à vos données avec différents logiciels SIG qui ne seraient probablement pas conscients des contraintes uniques.

Notre schéma d'identification n'a pas été choisi par moi mais est le suivant: code de 2,3,4 caractères qui est la classe de l'actif et un numéro séquentiel à 6 chiffres (vous choisiriez le nombre de chiffres qui vous convient). Une procédure stockée crée ces ID et s'appuie sur quelques tables non géodatabase dans la même base de données SQL Server.

Je garde un identifiant d'incrémentation automatique séquentiel distinct. Je garde également un champ geohash de 13 caractères (pour les entités ponctuelles), mais je ne l'utiliserais jamais comme clé. Le champ est rempli automatiquement (par une extension d'éditeur personnalisée) chaque fois que la fonction est déplacée.

Si vos données SIG doivent être utilisées avec n'importe quel type de système de gestion des actifs, vous souhaiterez que vos ID soient globalement uniques dans votre géodatabase (et peut-être uniques dans toutes les géodatabases de votre organisation). Cela facilitera également la refactorisation de la géodatabase à l'avenir.

Perrsonally, j'ai utilisé des calculs CRC dans le passé pour créer des valeurs similaires. Pas trop difficile à créer et des bibliothèques / algorithmes sont disponibles en ligne.

L'avantage est que vous pouvez faire des entités supérieures aux points, alors qu'une concaténation devrait vraiment être uniquement des entités ponctuelles (sauf si vous voulez une clé vraiment massive).

Et je pense qu'il est peu probable qu'un utilisateur final recherche de toute façon avec cet ID, donc je ne vois pas cela comme un problème.

Cela dit, je ne vois pas beaucoup d'avantages explicites d'attribuer une telle identification. Je pourrais utiliser la méthode pour la détection de changement (parce que c'est beaucoup plus efficace pour comparer deux valeurs CRC que deux ensembles de géométrie) mais même alors - pourquoi l'utiliser comme ID principal?

"Les GUID peuvent, bien sûr, être générés à l'aide de VB Script. Mais étant donné la désaccentuation progressive de VB Script par ESRI, nous effectuerons la génération de GUID dans ArcMap en utilisant la neuvième merveille du monde, Python. Pour ceux d'entre vous qui ne sont pas déjà dans le sais, Python est le cadeau de Dieu pour invétérer les pirates SIG. Mon conseil: apprends-le! vis-le! aime-le! "

http://eaglemap.com/blog/bid/45555/How-to-Generate-GUIDs-in-ArcMap

Arc Hydro Tools d' ESRI est livré avec une barre d'outils qui installe également un gestionnaire d'identification unique qui s'exécute en arrière-plan. La barre d'outils vous permet d'attribuer des ID uniques par classe d'entités ou par géodatabase. Le gestionnaire d'ID par défaut ne gère que les attributs d'ID uniques appelés par exemple HydroID, qui fait partie du modèle de données Arc Hydro. Mais il peut également être configuré pour gérer d'autres attributs. Les outils sont livrés avec beaucoup de documentation, donc la configuration du gestionnaire d'ID à vos besoins ne devrait pas être un problème.

L'ID unique est, à ma connaissance, toujours un entier. Après avoir attribué des ID uniques une fois que le gestionnaire a pris soin d'attribuer de nouveaux ID uniques pour chaque fonctionnalité nouvellement créée qui correspond à la configuration.

Le gestionnaire d'ID unique pourrait être utile pour les backends de base de données qui (AFAIK) ne prennent pas en charge les nombres à incrémentation automatique comme la géodatabase personnelle.