AW: AW: [Mapserver-DE] Argumente fuer oder gegen spezielle DBMS fuerGDI

[Uwe Seher]

Hallo Herr Lingner, hallo Liste!

Zum ESRI-PostGIS-Problem:
Man kann zwar über das bei PostGIS mitgelieferte Tool Shapefiles in
psql-Statements verwandeln und darüber die Daten in Postgis einpflegen.
Leider ist das ein mühsamer Weg und eigentlich nur dann sinnvoll, wenn ich
nur geringen Änderungsbedarf an den Daten habe. Sobald ich auf eine hohe
Interaktivität angewiesen bin, bekomme ich in der ESRI-Welt ein Problem. Der
Weg bei jeder Änderung ein psql-Statment zu erzeugen ist nicht sehr
ökonomisch und in einer server-basierenden Umgebung aufgrund der
Zugriffsrechte kaum zu verwirklichen. Es gibt mehrere OSS-Ansätze dies zu
ändern.

>Gibt es zu den hier aufgeführten Punkten ein System das "besonders gut"
>mit Mapservern (z.B. UMN Mapserver) zusammenarbeitet? Dabei interessiert
>mich nicht nur die Richtung Server->Client, sondern auch umgekehrt. Also
>das Verändern von vorhandenen Daten in der DB, Stichwort WFS-T.

Für unsere Belange nutzen wir zur Zeit UMN-Mapserver, PostgreSQL/PostGIS.
Das ist zur Zeit mehr als ausreichend und da wir an unseren derzeitigen
Projekten vorwiegend nur darstellende Funktionen benötigen, haben wir auch
nur wenig Probleme mit der ESRI-Welt ;)
Ein 'besonders gutes' System kann ich so ohne Kenntnis der Anforderungen
kaum empfehlen.
Einen WFS-T suchen wir auch noch, testet werden wir wohl Geoserver und
degree, ist aber noch nicht aktuell.

>Was bedeutet es wenn ein DBMS-Hersteller sagt: "wir unterstützen
>Geodaten"? Wie kann man Systeme, über die solche Aussagen gemacht
>werden, vergleichen? Reicht es aus, wenn die Simple Feature
>Specification (SFS) des OGC umgesetzt wurde? Ist dann sichergestellt,
>dass es standardisierte Funktionen zum Lesen und Schreiben von Geodaten
>gibt? Sind verschiedene Stufen der SFS-Konformität möglich?

Dazu muß man fragen, was sind denn Geodaten? Vermutlich sind geometrische
Objekte gemeint. Die kann man prinzipiell in jeder DB als Binärobjekt (WKB)
oder String (WKT) hinterlegen und auslesen. Die Aussage sagt also nicht
allzuviel. Wichtiger ist die Frage nach entsprechenden räumlichen Funktionen
oder der Möglichkeit räumliche Indices aufzubauen. Die Unterstützung von SF
nach OGC sagt eigentlich auch nur, das eben diese Objektbeschreibung
verwendet wird. Insofern ist gewährleistet, das ander SFS-unterstützende
Produkte dies Daten lesen können. Weitere DB-Funktionalitäten sind mir
zumindest dabei nicht bekannt. Vielleicht kennt sich jemand anderes da
besser aus.

>Ich stelle mir vor, dass die Datenbank Funktionen, die über die SFS
>hinausgehen, zur Verfügung stellt, um z.B. raumbezogene Abfragen zu
>vereinfachen. Wie kann ich also die Eignung eines DBMS für die
>Speicherung und Verarbeitung als (DBMS-)Laie prüfen?
>Oder führt diese Frage zu uferlosen Antworten und ich sollte mich
>intensiver mit DBMS beschäftigen?

Z.B. PostGIS stellt Funktionen zum Zusammenfügen und Verschneiden von
Geometrischen Objekten zur Verfügung. Oder Entfernungsabfragen etc. Das hat
aber eigentlich nichts mit SFS zu tun, sondern arbeitet eben mit den
geometrischen Objekten.
Als kleine Vorgehensweise kann ich ihnen vielleich folgendes anraten:

Versuchen sie Ihr Problem zu umgrenzen. welche Datenmengen, wieviele Nutzer,
wieviele gleichzeitig? eher statische Daten oder viel Bewegung? Welche
Aufgaben will ich erfüllen? Welche Funktionen benötige ich dazu? Leider
werden Sie nicht umhinkommen sich recht intensiv mit Datenbanken befassen zu
müssen. Dazu empfehle ich PostgreSQL/PostGIS. Es hat einen Windowsinstaller,
kostet nix und kann alles was das Herz begehrt ;).



Ich hoffe geholfen zu haben

Gruß
Uwe Seher


____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2147 from 12.12.2005
Virus news: www.antiviruslab.com