ArcSDE - native Geometrietypen für die spätere Migration von SDE verwenden?

Hintergrund: Wir haben eine nicht räumliche Berichts-Webanwendung mit einem SQL Server-Backend. Wir möchten dieser Anwendung eine räumliche Komponente hinzufügen: einige Grundkarten bereitstellen, Punkte und Polygone zum Anzeigen und Bearbeiten bereitstellen, Berichte für ausgewählte Polygone erstellen.

Zu diesem Zweck ist geplant, ArcSDE mit SQL Server zu verwenden und ArcServer zum Bereitstellen von Basisebenen und Vektorgeometrien zu verwenden. (so etwas wie WMS / WFS-T)

Problem: Möglicherweise entscheiden wir uns irgendwann, von teurer proprietärer Software abzuweichen und eine FOSS-Alternative zu verwenden (z. B. GeoServer oder TinyOWS, wenn SQL Server unterstützt wird). Wenn möglich, möchte ich vermeiden, dass die Anwendung unwiderruflich auf der ESRI-Technologie basiert.

Mein Verständnis von SDE ist, dass es entweder ESRI-spezifische Raumformate oder Raumformate verwenden kann, die für das Datenbanksystem, auf dem es installiert ist, nativ sind. (Ich gehe davon aus, dass die Verwendung der nativen Formate einige Leistungseinbußen mit sich bringt.)

Meine Frage (n): Wenn wir SDE in dieser SQL Server-Datenbank mit nativen SQL Server-Raumformaten einrichten würden, könnten wir beispielsweise GeoServer einrichten, um die von SDE verwalteten Tabellen auszuführen? Was würde es brauchen, um SDE herauszureißen und etwas anderes zu verwenden? (Auch eine Meta-Frage: Ist dies eine vernünftige Frage? Gibt es etwas Wichtiges, das mir fehlt?)

Eine teilweise Antwort: Ich bin kein Geoserver-Benutzer, habe jedoch eine räumlich gesteuerte Nicht-Esri-Webanwendung (ASP.NET) unter Verwendung der nativen Geometrie erstellt, die in einer tatsächlichen SDE-Feature-Class (SQL Server 2008) gespeichert ist. Solange es nicht versioniert ist (oder es versioniert ist und Sie akzeptieren, dass eine Verzögerung besteht, damit Ihre Änderungen in die Basis verschoben werden), sollte dies kein Problem sein. Meine App war räumlich gesteuert, enthielt keine Karte, aber die räumlichen Funktionen wurden in den SELECT-Anweisungen und gespeicherten Prozeduren stark genutzt.

Ich habe festgestellt, dass ArcGIS mit nativen und / oder Esri ST_GEOMETRY-Implementierungen fehlerhaft sein kann und häufig dazu führt, dass der Hersteller mit dem Finger zeigt. Siehe diese Frage: Wie kann ich mehr Polylinienscheitelpunkte für eine ST_GEOMETRY in Oracle / SDE zulassen? (Kurzversion: Oracle: "So ist es. Esri muss damit umgehen." Esri: "Das ist ein Fehler - warten Sie, bis Oracle ihn behebt.")

Es ist kein Grund, keine native Geometrie zu verwenden, sondern etwas, das Sie beachten sollten, falls Sie der erste sind, der auf einen Fehler stößt (ich empfehle außerdem, SDE_BINARY-Versionen Ihrer Datensätze in einer Test- / Entwicklungsumgebung zu haben, damit Sie dies bestätigen oder regeln können seltsames Verhalten in beiden Speicherdatentypen).

Sie erwähnen die Bearbeitung dieser geplanten räumlichen Datenbank. Hier geben Sie nicht genügend Daten für eine vollständige Antwort an.
Wenn die bearbeiteten Tabellen Besonderheiten (Datentypen) aufweisen, planen Sie eine raue See.
Es wird eine Herausforderung genug sein, die räumlichen Tabellen (von Drittanbietern) einzurichten, Benutzerberechtigungen, Viewer-Berechtigungen, Sperren zu umgehen, keine Versionsverwaltung zu unterstützen und nicht versionierte Daten in Arcgis zu bearbeiten. Es gibt viele andere Brücken, Hürden und sogar Abgründe, um darüber hinwegzukommen.
Je einfacher das Modell, desto weniger Probleme bei der Durchführung.
Davon abgesehen lautet die kurze Antwort ja.
Eines der Probleme mit dieser Straße ist, dass sobald die Entscheidung getroffen wird, die Straße zu fahren.
Es gibt viele, viele Fahrzeuge, um die Straße hinunterzukommen.
Die Entscheidung für das richtige Fahrzeug wird oft über Monate, wenn nicht Jahre des Sandkastenspiels getroffen.

BEARBEITEN
Wenn Sie Polygone bearbeiten und keine ausgeklügelten Techniken und Werkzeuge verwenden, möchten Sie Topologieregeln, die bei der Qualitätskontrolle helfen (möglicherweise ein anderer Software-Stack wie Radius). Wenn Sie ein Polygon teilen, möchten Sie, dass beide die gleichen Attribute erhalten oder nicht. Wenn ein Scheitelpunkt verschoben wird, wird er an einem anderen ausgerichtet, wenn kein Splitter vorhanden ist. und so weiter und so fort. Wenn Sie esri nicht verwenden, sind Sie allein (oder in der räumlichen Datenbank), um einige grundlegende GIS-Funktionen anzuwenden. Sie müssen nur wissen, was Sie wollen und wie es geht (oder dass es gemacht werden kann).

Wir speichern SDE-Daten im nativen Geometrietyp SQL Server 2008, und ich würde es nicht anders machen. Dies ermöglicht maximale Flexibilität bei der räumlichen Abfrage in der Datenbank. Geoserver hat gerade die Unterstützung für SQL Server-Datentypen erheblich verbessert, aber wir haben dies nicht genutzt, sodass ich diesbezüglich nicht viel Input liefern kann. Zu beachten ist, dass beim Erstellen einer SDE-Datenbank mit der Standard-Nachinstallation eine Tabellenstruktur für SDE erstellt wird. Es wäre ratsam, diese Struktur zu untersuchen. Wenn ich sde zugunsten von Foss-Lösungen entfernen würde, würde ich nicht alle nicht benötigten sde-Systemtabellen wollen. Daher würde ich eine saubere Datenbank neu erstellen und die Tabellen in die neue Umgebung verschieben. Dies wäre eine Gelegenheit, Postgis anstelle von SQL Server zu testen, da Geoserver eine Entwicklungshistorie mit Postgis hat. Ich würde nicht'

Ich hoffe, das hilft!