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

[lars lingner]

Uwe Seher schrieb:
> 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.

Aha, also fehlt der ESRI-Welt die direkte Postgis-Unterstützung, sonst 
müsste man ja nicht mit Shapefiles hantieren? Zu diesem Thema habe ich 
eine Erweiterung fuer ArcMap gefunden PgArc, hatte aber noch keine Zeit 
sie auszuprobieren...

> 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.

In meinem Fall wird nach jetzigem Stand der Dinge der Geoserver als 
WFS-T eingesetzt, der UMN Mapserver als WMS.

> 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.
> 

Vielen Dank, das ist schonmal sehr aufschlussreich und zeigt mir 
gleichzeitig, dass ich mich mit dem Thema intensiver auseinander setzen 
muss als bisher gedacht... man lernt nie aus :

> 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 ;).
> 
Gehversuche habe ich schon mit MySQL und PostgreSQL gemacht, zum 
speichern von Geodaten würde ich spontan zu PostgreSQL/PostGIS greifen. 
Aber sehr oft reicht die eigene Meinung nicht aus, sondern man muss 
verschiedene Faktoren berücksichtigen.

@Liste: Ich freue mich auch über andere Meinungen, möchte die Diskusion 
hier nicht "abwürgen" ;)

> 
> 
> Ich hoffe geholfen zu haben
> 
In der Tat, vielen Dank dafür.

Viele Grüße

Lars Lingner