Vor-/Nachteil mehrerer geometrietypen in einer Tabelle^

Hallo,
ich beginne gerade ein Datenmodell zu erstellen und frage mich ob es zweckmäßig ist - wie beim arbeiten mit vielen GIS-Systemen üblich - die Relationen nach Thema und Geometrie zu trennen. Das Ergebnis sind entsprechend viele Tabellen mit entsprechendem Wartungsaufwand, da ein- bis mehrmals im Jahr neue Daten (ALKIS, eigene Erhebungen etc.) “alte” Objekte ersetzen werden.
Meine idee wäre es daher eine Relation mit allen Geometrien und Geometrietypen zu erzeugen.
enforce_geotype_the_geom entsprechend zu modifizieren scheint ja zu gehen, so dass die Relation alles enthalten kann. (z.B. : How to apply spatial constraints to PostGIS*tables )

Die Frage die ich mir stelle: welche Vorteile hätte eine Zerlegung der Gesamtgeometrien nach deren Geometrietypen? bzw. welchen Nachteil hätte es eine “Gesamttabelle” mit POINT,LINE,POLYGON etc. pp). In der thematischen Zerlegung sehe ich gegenwärtig nur eine deutlich höhere Wartung des Modells.
Die Geometrien werden alle nur mit einem und dem gleichen SRID versehen und mittels einer meta_id wird auf die jeweiligen metadaten verknüpft, die entsprechende Verwendungsmaßstäbe etc. anzeigen.
hat hierzu jemand Ideen/anmerkungen o.ä.?
wäre froh über jedweden konstruktiven beitrag hierzu :slight_smile:

Du hast schon recht, das bedeutet einen höheren Wartungsaufwand. Demgegenüber steht aber auch ein höherer Aufwand in der Applikationsentwicklung, weil irgendwo mußt du das ja wieder auseinander fieseln. Die Komplexität verlagert sich also irgendwie nur. Auch leidet die Übersichtlichkeit wie ich finde, was aber bei entsprechendem Gewinn zu verschmerzen ist. Vermutlich gäbe es Schwerigkeiten bei der Darstellung in z.B. QGis, man könnte das zwar eventuell als View darstellen, müsste dann aber etwas zum Editieren bauen.
Es gibt aber unter PostGIS mittlerweile eine einfache Möglichkeit, verschiedene Geometrietypen in einer Tabelle zu verwalten und gesondert auszulesen (kann aber sein, das das schon 2.0 ist), was das ganze sehr vereinfachen würde. Mein Ansatz war bisher, unabhängige Geometrien in verschiedenen Tabellen zu verwalten, davon abgeleitete Geometrien, z.B. Centroid, Ringe etc. werden bei Bedarf erzeugt. Allerdings fand ich den neuen ‘gemischten’ Ansatz auch sehr interessant, weil man dann z.B. recht einfach eine maßstabsabhängige Darstellung der Geometrien erzeugen kann. Bin aber (wie üblich :wink: ) noch nicht zu Ausprobieren gekommen.

Gruß Uwe

Edit: http://postgis.refractions.net/docs/ST_CollectionExtract.html hilft vielleicht. Man verwaltet die Geomerien in einer Collection, aus der dann die gewünschten extrahiert werden können.

Erstmal schönen dank für die Einschätzung!
Der Aufwand wäre, dass die Enduser entweder ein paar sqls eintippern müssten oder eben via views arbeiten. Q-GIS zerpflückt solche Tabellen direkt nach geometrieart beim ausladen aus pg :slight_smile: und zeigt entsprechend 3 Geometrietabellen an, wie mir ein minitest beglückend demonstrierte.
Die editierung geht via Rules einzustellen. Die Enduser sollen die amtlichen Daten ja auch nicht manipulieren, sondern nur die eigenen Erhebungen
Wie das mit anderen gis-tools aussieht weiß ich leider nicht… map3d wäre da noch relevant zu testen.
Bzgl. Übersicht gebe ich dir bedingt recht. Die ALKIS Daten als shp importieren ist nicht so der Übersichtsknaller…schon gar nicht wenn teile der Daten (Die eigenen Erhebungen und später auch ALKIS) historisiert werden müssen und einzeln wieder herstellbar sein müssen. Hier habe ich auf einer dummytabelle mit einem trigger herumgespielt…das tut was es soll - aber sobald neue datentabellen ins system kommen müsste ich die ganzen trigger und rules neu setzen etc. pp. und es werdennicht wenige Themen dazukommen…

ich entnehme dem aber, dass grundsätzlich keinerlei Probleme seitens postGIS hinzukommen…
oder?
besten dank und gruß

Jo, bei den Anforderungen würde das schon Sinn machen, vor allem wenn man eine Trennung zu den Nutzerdaten hat. Wir kriegen ALKIS immer nur in kleinen Häppchen und das ist schon schlimm genug :slight_smile:
Danke auch für den QGIS-Tip, werd das mal durchprobieren was man da machen kann.

Gruß Uwe

bzgl. q-gis ist es ein wenig tricky falls keine eindeutigen daten kommen, denn macht die OID sinn ansonsten einfach eine rule definieren, mit SET att=new.att

ce ca :slight_smile:
…kleine alkis häppchen würden mich in den Wahn befördern…1000000 shapes alle nase lang reinjuckeln und denn nach diesem konzept wiedre umbasteln :frowning: autsch…
ich hatte irgendwo mal was von einem NAS-Import nach pg gelesen…weißt du da zufällig mehr?
…das wäre auch noch eine sinnige maßnahme…
beste grüße!!

Naja, ich mach das meist per bash-skript, dem ist die Anzahl (fast) egal :wink: . Das mit der OID muß ich mal ausprobieren, hab da ab und an mal Probleme.

Grüßle Uwe