Hallo,
mich würde mal interessieren, was es bei den Materialized Views in PostgreSQL zu beachten gibt. Besonders in Verbindung mit Geometrien. Im Bereich PostgreSQL bin ich noch Anfänger und es fällt mir aktuell noch etwas schwer, mich von anderen Datenbanken umzugewöhnen.
Ich habe also eine MV mit dem Namen PUNKTE aus einer Foreign-Tabelle (tbl1) erstellt. Zur Info: Feld 2 und 3 sind x und y Koordinaten:
SELECT
row_number() OVER () AS objektid,
tbl1.feld1 AS jahr,
st_setsrid(st_point(tbl1.feld2, tbl1.feld3), 25832) AS geopraphy
FROM tbl1
WHERE tbl1.feld3 > 0;
Diese ist etwas gekürzt in der Mitte. Dazu habe ich dann einen Index erstellt:
CREATE INDEX mv_punkte_idx
ON mv_punkte
USING GIST (st_point);
So. Abgesehen davon, dass sich das alles falsch anfühlt, werden mir im QGIS Punkte angezeigt. Es gibt aber den Hinweis: Spalten in Spalte ‘Objektkennung’ wählen, die die Objekte des Layers eindeutig bezeichnen.
Im Infrastructure MapServer (mapguide) von Autodesk, kann ich die Verbindung herstellen. Möchte ich einen Layer erstellen, dann fehlt mir aber die FEATURE CLASS bzw. die Objektklasse.
Frage: Fehlt noch etwas, um eine MV für andere Systeme korrekt herzustellen? In einer früheren Datenbank musste die MV noch in eine METADATA-Tabelle eingetragen werden, damit andere Produkte (AutoCAD Map z.B.) diese anzeigen konnten. Vergleichbares habe ich hier nicht gefunden.
Zu QGIS kann ich nix sagen, aber mat. View in PG stellen sich nach außen wie ganz normale Tabellen dar. Evtl. will Dir der Hinweis aber sagen, daß Du einen unique Index erstellen solltest, damit die einzelnen Datensätze eindeutig identifiziert werden können. Nur eine Vermutung, kenn QGIS nicht.
Ok, das QGIS-Problem hat sich erledigt. Durch deinen Hinweis habe ich festgestellt, dass QGIS nur eine weitere Info haben wollte. Wer lesen kann…
Der Rest der Frage bleibt aber
In QGIS kommt die Meldung, wenn es keinen (oder mehrere) Kandidaten für eine ID findet. Dann mußt du den halt auswählen. Zu Autodesk kann ich wenig sagen, aber anscheinend kann er nicht automatisch feststellen was dargestellt werden soll. ODer aknn den Datenbankinhalt nicht in sein eigenes Datemmodell überführen. Wie gesagt, ich kenn mich mit Autodesk und FDO nicht wirklich aus. Vielleicht hat gibt es auch nur ein Problem mit dem (falsch geschriebenen ;)) Geometrie-Feld.
Gruß Uwe
Oh, man. Bist du schnell. Das ist auch noch eine Idee. Ich halte die Dinge zwar immer möglichst einfach, falls der Support aber keine Lösung hat, wäre das eine. Immerhin kommen die Daten über einen Wrapper, in ein foreign Table, in eine MV, in eine View…
Aber die Idee ist gut.
Am Anfang als die MVs eingeführt wurde war das in QGIS ähnlich. Grund war, es wurde irgendwo im information_schema nach einem Typ gefiltert und da war der MV in QGIS nicht eingeschlossen. Die Lösung von castorp bracht damals die Lösung, mal abgesehen davon, daa man das in der Anwendung geändert hat (was in diesem Falle eher nicht geht).
Gruß Uwe
Danke für die Info. Der Support kennt das Problem. Mal sehen was die machen. Vielleicht gibt es ja einen Fix. Bei Autodesk wird es aber wohl eher so sein, dass das in der nächsten Version behoben wird. Mal abwarten.
So, hier mal ein aktueller Stand: Der FDO-Provider PostgreSQL unterstützt wohl keine Materialized VIEWs. Also habe ich es über eine MV gelöst und darüber noch eine View laufen lassen. Was ein Umweg…