Warum benötigen die meisten GIS-Pakete eine numerische ID?

Dies ist eine einfache, aber möglicherweise kontroverse Frage: Warum erfordern die meisten (wenn nicht alle) GIS-Pakete, dass eine bestimmte Ebene eine eindeutige, nicht nullbare numerische Kennung hat?

Warum wird ein solcher Ersatzschlüssel anstelle eines natürlichen benötigt?

Beispiele:

• ArcGIS erzwingt OBJECTID (oder eine GlobalID)

• QGIS lädt keine Layer, wenn sie keine numerische ID haben.

Weil sie ein optimiertes indizierbares Feld haben müssen. Das wiederholte Indizieren eines Zeichenfolgenfelds würde mehr Overhead erfordern und ist am Ende einfach nicht so effizient.

ESRI unterstützt in der SDE-Welt tatsächlich die 'GLOBALID', die ein GUID-Feld ist. Dies ist also ein 32-Zeichen-Feld, das jedoch weiterhin indiziert ist, um die Leistung zu steigern.

Wenn Sie anfangen, Datensätze zu einer Ebene hinzuzufügen, können Sie sich darauf verlassen, dass ein Benutzer einen eindeutigen alphanumerischen Code für jede neue Funktion eingibt, bevor er sie auf die Festplatte schreibt.

..oder Sie könnten ein einfaches automatisch inkrementierendes Ganzzahlfeld implementieren.

Wie viele Leute vorgeschlagen haben, ist es eine Frage der Bequemlichkeit; aber vielleicht tiefer ist es Konvention.

Als Programmierer wäre mein erster Instinkt, einen numerischen Schlüssel für eine Ebenen-ID zu verwenden, da dies immer so war. In der Tat kann es mir zumindest bewusst nicht einmal einfallen, dass ich es anders machen sollte. Wenn es einen technischen Grund gibt, keine ganzen Zahlen zu verwenden, sagen Sie natürlich, ob die Möglichkeit besteht, dass mehr Ebenen vorhanden sind, als in 32-Bit gespeichert werden können (ein sehr unwahrscheinlicher Vorschlag!), Oder ob es einen geschäftlichen Grund dafür gibt. dann würden Alternativen in Betracht gezogen.

Es gibt auch algorithmische Überlegungen mit Zifferntasten. Das Sortieren und Durchsuchen einer Liste sortierter Werte führt letztendlich zu einem Vergleich zwischen zwei Zahlen, selbst wenn es sich um eine Liste von Zeichenfolgen oder komplexen Objekten handelt. Sie werden lediglich mit einer Hashing-Funktion in Zahlen umgewandelt . Auf modernen Computern ist das Durchsuchen einer Liste mit beispielsweise 100 oder sogar 1000 Elementen mit einem Brute-Force-Ansatz normalerweise genauso schnell wie mit einem hochoptimierten Algorithmus. Im Fall von Ebenen in einem GIS kann ich nicht einmal die komplexesten Karten mit mehr als 1000 Karten sehen, und selbst wenn dies der Fall wäre, würden die anderen zugehörigen Berechnungen Größenordnungen länger dauern als jeder kleine Gewinn aus einer optimierten Karte Suche nach einer kurzen Liste.

Ganzzahlige Tasten sind für einen Programmierer "nur sinnvoll", und wie Brad sagt, ist die Verwendung nicht numerischer Tasten aufwändiger. Vielleicht nicht mehr Code, sondern mehr geistige Anstrengung, und wir sind faule Gewohnheitstiere. Außerdem wird der Schlüssel, der so etwas wie eine Ebene in einem GIS eindeutig identifiziert, als "verborgen" für den Benutzer betrachtet, um sicherzustellen, dass er nicht damit herumspielt und Code bricht, der auf seiner Eindeutigkeit beruht (ungeachtet der DB UNIQUE-Schlüsselwörter). Denn wenn Sie einem Benutzer genug Seil geben, wird sich früher oder später jemand daran aufhängen. Erzwingen Sie auf jeden Fall die Eindeutigkeit eines vom Benutzer bearbeitbaren Felds, aber das zugrunde liegende System muss davon ausgehen, dass sein Schlüssel eindeutig und nicht manipuliert ist.

Diese Frage war für Leute (wie mich) verwirrend, die die Geodatabase-Seite der Dinge entwickeln.

Dies ist keine Einschränkung des Datenbankspeichers, da PostgreSQL Tabellen mit zusammengesetzten PRIMARY KEYS verschiedener Datentypen definieren kann. Diese Tabellen können jedoch nicht in Programme wie QGIS geladen werden. In einem verwandten historischen Hinweis benötigte PostgreSQL früher eine OID- Spalte als internen Schlüssel, der ebenfalls eine 32-Bit-Ganzzahl war. Dies war bis Version 7.2 erforderlich .

Die 32-Bit-Ganzzahl-ID-Anforderung ist wirklich eine Programmierbeschränkung. Es ist viel einfacher, einen Index für eine Reihe von Datensätzen als festen Datentyp (32-Bit-Ganzzahl) zu haben, und es ist zweckmäßig, dass dies auch der primäre Schlüssel für diesen Datensatz ist. Es ist schwieriger, ein Programm so zu gestalten, dass es einen zusammengesetzten Primärschlüssel zulässt, und einen eindeutigen Datensatz abzurufen, der auf mehreren und / oder unterschiedlichen Datentypen basiert. Wie bei der OID von PostgreSQL kann diese Einschränkung jedoch mit der Entwicklungszeit überwunden werden. Für QGIS könnte der [jetzt] 5 Jahre alte Fehler eines Tages behoben sein (hier ist eine aktuelle Diskussion zu diesem Thema).

In ESRI und anderer GIS-Software ist es üblich, einen Ordner oder eine Reihe von Dateien zu haben, die für Feature-Classes oder Datasets erstellt werden.
zB Arcinfo-Abdeckung, Shapefile, Datei-Geodatabase.
Diese "Sätze" von Dateien müssen von der Software "zusammengefügt" werden, um viele GIS-Funktionen zu ermöglichen.
Attrubute-Tabellen, Netzwerk, topologische Kontrollen.
Dies ist der Zweck der OID und auch der Grund dafür, dass sie nicht nullbar, versteckt und softwaregesteuert ist.