AW: AW: AW: [Mapserver-DE] Argumente fuer oder gegen spezielleDBMSfuerGDI

["Jäger, Frank \(KRZ\)"]

Hallo,

MySQL:

>> Ausserdem wird der Datentyp 'geometry' nur in 'MyISAM'-Tabellen
unterstützt, die wiederum keine Transaktionen unterstützen.

Das stimmte bis vor kurzem.
Noch schlimmer: MyISAM kennt auch keine Foreign-Key-Constraints.

Im letzten Newsletter von MySQL stand jedoch, dass seit der aktuellen Version (MySQL 5.0.16 ?) nun Geometriefelder von allen DB-Engines unterstützt werden, also auch von InnoDB.


Trotzdem macht PostGIS auf mich einen besseren Eindruck.

mfG
F.J.


-----Ursprüngliche Nachricht-----
Von: mapserver-de-bounces at freegis.org
[mailto:mapserver-de-bounces at freegis.org]Im Auftrag von Weßling, Achim
Gesendet: Montag, 12. Dezember 2005 16:44
An: mapserver-de at freegis.org
Betreff: AW: AW: AW: [Mapserver-DE] Argumente fuer oder gegen
spezielleDBMSfuerGDI


Hallo,

zu den beiden DB MySQL und PostgreSQL/PostGIS ist zu sagen, das MySQL
zwar das WKT-Format unterstützt, aber weitergehende Funktionen wie
Verschneidungen und Berechnungen nicht, nur rudimentär oder Fehlerhaft
unterstützt.
Ausserdem wird der Datentyp 'geometry' nur in 'MyISAM'-Tabellen
unterstützt, die wiederum keine Transaktionen unterstützen.
Auch bei den OpenSource-Editierwerkzeugen erfährt die PostGIS eine
größere Unterstützung, da sie länger 'am Markt' ist.

Die Editier-Problematik kann man auch ohne WFS-T und ESRI angehen. Z.B.
mit uDIG, QGIG oder JUMP.

Achim Weßling

-----Ursprüngliche Nachricht-----
Von: mapserver-de-bounces at freegis.org
[mailto:mapserver-de-bounces at freegis.org]Im Auftrag von lars lingner
Gesendet am: Montag, 12. Dezember 2005 16:31
An: mapserver-de at freegis.org
Betreff: Re: AW: AW: [Mapserver-DE] Argumente fuer oder gegen spezielle
DBMSfuerGDI

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

_______________________________________________
Mapserver-DE mailing list
Mapserver-DE at freegis.org
https://freegis.org/mailman/listinfo/mapserver-de