Weisen Sie Punkt-Features eine eindeutige ID zu

Der MassGIS-Paketstandard (http://www.mass.gov/mgis/ParstndrdVer1_5_1.pdf) verwendet eine Verkettung des ganzzahligen Teils der x- und y-Koordinaten, um eine eindeutige ID (LOC_ID) für Features zu erstellen. Ich denke darüber nach, dasselbe für eine Punkt-Feature-Class zu tun. Ich mag die konsistente Methodik, aber vielleicht übersehen ich etwas. Gibt es einen Standard oder eine bewährte Methode zum Erstellen eindeutiger IDs für Punkt-Features?

Wenn Sie diese ID für einen Fremdschlüssel in Bezug auf eine andere Tabelle verwenden, gerät Ihre gesamte Datenbank in große Schwierigkeiten, wenn Sie aus irgendeinem Grund einen Punkt verschieben müssen. Wahrscheinlich müssen Sie dann die ID behalten, auch wenn sie die xy-Koordinaten nicht mehr beschreibt.

Als eindeutiger Schlüssel ist es oft am besten, etwas zu haben, das nichts über die Daten aussagt, da sich die meisten Daten möglicherweise ändern.

/ Nicklas

Hinzufügen von Nicklas Antwort und meinem Kommentar.

Ich würde sagen, dass die am häufigsten verwendete und am meisten empfohlene Konvention darin besteht, nur eine automatisch inkrementierende ID zu verwenden, z. B. bei 1 zu beginnen und einfach weiterzumachen. Keine Logik und einfach.

Wenn Sie ein verteiltes System haben oder keine automatisch inkrementierenden Zahlen mögen, können Sie eine GUID verwenden. Die meisten Datenbanken übernehmen die Erstellung dieser Art von ID für Sie. Es ist jedoch ein Problem für einen Benutzer, manuell einzugeben, zu suchen usw. Denken Sie also daran.

Die andere Möglichkeit besteht darin, eine Art Hash der Daten zu verwenden, aber ich würde dies nicht empfehlen. Es würde bedeuten, dass Sie einen Algorithmus schreiben müssten, um dies für Sie zu tun. Sie können nicht immer die Eindeutigkeit sicherstellen. Sie sind auch ein Problem bei der Suche.

Dies sind nur meine Meinungen, aber aus persönlicher Erfahrung, vertrauen Sie mir, verwenden Sie niemals Geschäftsdaten in IDs.

Folgefrage: Ist es am besten, die eindeutige ID im DBMS (SQL Server) oder in der GIS-Software (ArcGIS) zu erstellen und zu verwalten?

Ich würde dringend empfehlen, die Eindeutigkeit im DBMS zu überprüfen. Das ist eine der vielen Stärken von DBMS. Außerdem können Sie mit einer anderen GIS-Software auf Ihre Daten zugreifen, die die eindeutigen Einschränkungen wahrscheinlich nicht kennt.

Unser Identifikationsschema wurde von mir nicht ausgewählt, lautet jedoch wie folgt: 2,3,4-Zeichen-Code, der die Klasse des Assets darstellt, und eine 6-stellige fortlaufende Nummer (Sie würden wählen, welche Ziffernanzahl für Sie funktioniert). Eine gespeicherte Prozedur erstellt diese IDs und stützt sich auf einige Nicht-Geodatabase-Tabellen in derselben SQL Server-Datenbank.

Ich behalte eine separate, sequentielle Auto-Inkrement-ID. Ich behalte auch ein 13- stelliges Geohash- Feld (für Punktmerkmale ), aber ich würde das niemals als Schlüssel verwenden. Das Feld wird automatisch ausgefüllt (durch eine benutzerdefinierte Editorerweiterung), wenn das Feature verschoben wird.

Wenn Ihre GIS-Daten mit einem beliebigen Asset-Management-System verwendet werden sollen, möchten Sie, dass Ihre IDs in Ihrer Geodatabase (und möglicherweise in allen Geodatabases in Ihrem Unternehmen) global eindeutig sind. Dies wird es auch in Zukunft ein wenig einfacher machen, Geodatabase-Refactoring durchzuführen.

Perrsonally habe ich in der Vergangenheit CRC-Berechnungen verwendet, um ähnliche Werte zu erstellen. Nicht zu schwierig zu erstellen und Bibliotheken / Algorithmen sind online verfügbar.

Der Vorteil besteht darin, dass Sie Features ausführen können, die größer als Punkte sind, während eine Verkettung eigentlich nur Punkt-Features sein muss (es sei denn, Sie möchten einen wirklich massiven Schlüssel).

Und ich denke, es ist unwahrscheinlich, dass ein Endbenutzer nach dieser ID sucht, daher sehe ich das nicht als Problem.

Trotzdem sehe ich nicht viele explizite Vorteile einer solchen ID-Zuweisung. Ich könnte die Methode zur Änderungserkennung verwenden (weil es viel effizienter ist, zwei CRC-Werte als zwei Geometriesätze zu vergleichen), aber selbst dann - warum sollte sie als primäre ID verwendet werden?

"GUIDs können natürlich mit VB Script generiert werden. Angesichts der allmählichen Deemphasis von VB Script durch ESRI werden wir die GUID-Generierung in ArcMap mit dem neunten Weltwunder, Python, durchführen. Für diejenigen unter Ihnen, die noch nicht in der Wissen Sie, Python ist Gottes Geschenk, um GIS-Hacker einzudringen. Mein Rat: Lernen Sie es! Leben Sie es! Lieben Sie es! "

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

Die Arc Hydro Tools von ESRI verfügen über eine Symbolleiste, in der auch ein eindeutiger ID-Manager installiert ist, der im Hintergrund ausgeführt wird. In der Symbolleiste können Sie eindeutige IDs pro Feature-Class oder Geodatabase zuweisen. Der ID-Manager verarbeitet standardmäßig nur eindeutige ID-Attribute, z. B. HydroID, die Teil des Arc Hydro-Datenmodells sind. Es kann jedoch auch für andere Attribute eingerichtet werden. Die Tools werden mit einer Vielzahl von Dokumentationen geliefert, sodass die Konfiguration des ID-Managers gemäß Ihren Anforderungen kein Problem darstellen sollte.

Die eindeutige ID ist meines Wissens immer eine ganze Zahl. Nach dem Zuweisen eindeutiger IDs kümmert sich der Manager um die Zuweisung neuer eindeutiger IDs für jedes neu erstellte Feature, das zur Konfiguration passt.

Der eindeutige ID-Manager kann für Datenbank-Backends nützlich sein, die (AFAIK) keine automatisch inkrementierenden Zahlen wie die persönliche Geodatabase unterstützen.