Postgresql i postgis

[Kaczka]

Witam,
Mam pytanie czy da się przyspieszyć odświeżanie połączenia z postgisem jeśli baza z którą się łączymy zawiera kilkadziesiąt schematów ?
Obecnie po połączeniu trwa to u mnie kilka ładnych minut.
Może da się wywołać połączenie z parametrami do jednego określonego schematu ?

Postgresql 8.3.x , postgis 1.3.x Qgis 1.8

K.

P.S. Podobnie mam w wersji rozwojowej przy połączeniu z Oraclem Spatial

[borys]

Kilka minut łączenia wskazuje na to, że QGIS zagląda do tabel, żeby określić typ geometrii. Więc pierwsze pytanie: czy wszystkie tabele z geometrią są wpisane w tabeli geometry_columns ? Jeśli je tam znajdzie, to nie powinien już kontynuować dochodzenia. Być może to rozwiąże problem.

Nic mi nie wiadomo o możliwości ograniczenia przeszukiwanych schematów (poza oczywiście "Sprawdź tylko schemat public" w ustawieniach połączenia Postgre). Pewnym obejściem byłoby utworzenie roli, która ma prawa odczytu tylko z wybranego schematu. O ile pamiętam, to to "Sprawdź tylko schemat public" było jedyną przydatną opcją w ustawieniach połączenia w QGIS-ie 1.8. W wersji rozwojowej widzę jeszcze dwie (jeszcze nieprzetłumaczone, więc zakładam że to nówki, których nie było w 1.8):
Only look in layers registries
Don't reso've type of unrestricted columns (GEOMETRY)

Nie bawiłem się nimi, ale rozumiem, że chodzi o zaniechanie dalszego dochodzenia, jeśli tabel nie ma w geometry_columns. Te nowości trafią do nadchodzącej wersji 2.0 (planowe wydanie 7 czerwca).

[sebaq]

Cześć!
A jak najszybciej uzupełnić tabelę geometry_columns? Insertami, czy może QGIS/PostgreSQL/PostGIS to zrobi automatem? QGIS ładnie dodaje wpisy przy użyciu wtyczki SPIT, aczkolwiek dane mogą być dodawane z różnych źródeł i nie zawsze się o tym pamięta. I jak rozpoznać poprawną geometrię... Nie zawsze mamy pewność czy mamy do czynienia tylko z LINESTRING czy MULTILINESTRING. Być może lepiej wtedy stosować 'nadmiarowo' prefix MULTI? No i co w przypadku warstw opartych na widokach?
Dodatkowo spytam czy dodanie CONSTRAINTów typu enforce_geotype_the_geom, enforce_srid_the_geom czy enforce_dims_the_geom na tabeli z geometrią jest obligatoryjne i czy cokolwiek poprawia?
Ciekawi mnie to, gdyż jestem w trakcie przejścia PostgeSQL z 8 na 9 ze zmianą PostGIS 1.4 na 2.0. O ile przejście się udało i projekt QGISa działa, o tyle tam nie ma tam już tabeli geometry_columns, a DUMP bazy nic nie zmienił w schemacie topology...
Pozdrawiam!

[borys]

Cześć!
A jak najszybciej uzupełnić tabelę geometry_columns? Insertami, czy może QGIS/PostgreSQL/PostGIS to zrobi automatem? QGIS ładnie dodaje wpisy przy użyciu wtyczki SPIT, aczkolwiek dane mogą być dodawane z różnych źródeł i nie zawsze się o tym pamięta.

Kiedy tworzysz tabelę, w poleceniu CREATE TABLE powinieneś pominąć kolumnę geometrii i dodać ją później funkcją AddGeometryColumn (patrz: dok. PostGIS-a), która od razu doda wpis do geometry_columns oraz pozakłada constrainty. SPIT również trzyma się tej zasady.

Jeśli dodałeś (albo coś dodało) kolumnę od razu w poleceniu CREATE TABLE, to trzeba oddzielnie wstawiać insertami.

I jak rozpoznać poprawną geometrię...

Np. SELECT DISTINCT ST_GeometryType na każdej tabeli, czyli to, co teraz robi QGIS przy każdym łączeniu się z bazą.

Nie zawsze mamy pewność czy mamy do czynienia tylko z LINESTRING czy MULTILINESTRING. Być może lepiej wtedy stosować 'nadmiarowo' prefix MULTI?

Mieszanie różnych typów geometrii w jednej tabeli generalnie nie jest dobrym pomysłem. Po pierwsze QGIS nie obsługuje mieszanych warstw i właśnie po to analizuje typy geometrii w każdej tabeli, żeby móc je porozbijać na osobne warstwy w razie znalezienia różnych typów. Jeśli oszukasz go w geometry_columns, to może to prowadzić do błędów (a co najmniej do pominięcia rekordów z niepasującym typem). Po drugie to się zwykle wyspie przy eksporcie (np. przez ogr2ogr), po trzecie czasami przy wewnętrznych operacjach w PostGISie trzeba wiedzieć, czy to jest MULTI czy nie i wtedy trzeba takie działania robić dwukrotnie z WHERE ST_GeometryType. Poza tym wszystkim, gdybym wiedział, że w tabeli jest tylko jeden typ geometrii, to w poprzednim akapicie zamiast DISTINCT dałbym zwykłe LIMIT 1.

Absolutnie nie możesz wpisać do geometry_columns MULTI, jeśli w tabeli siedzą zwykłe linie. To jest inny typ, np. po pierwszej konwersji do WKT wysypie się na brakujących nawiasach. Jeśli masz w tabeli MULTI i zwykłe, to przekonwertuj wszystkie zwykłe do MULTI (patrz: google).

No i co w przypadku warstw opartych na widokach?

Nie próbowałem, ale jeśli masz porządek w danych, to typy nie powinny się pomieszać, a wpis w geometry_columns powinien działać i dla widoków. Jeśli masz tylko kilka, to zresztą można by je zostawić je w spokoju - może przyśpieszenie na zwykłych tabelach wystarczy.

Dodatkowo spytam czy dodanie CONSTRAINTów typu enforce_geotype_the_geom, enforce_srid_the_geom czy enforce_dims_the_geom na tabeli z geometrią jest obligatoryjne i czy cokolwiek poprawia?

Technicznej obligatoryjności nie ma, ale poprawia rzecz najbardziej fundamentalną, czyli spójność danych...

[sebaq]

Wielkie dzięki Borys!!
Wszystko wyjaśnione
Pozdrawiam!

[Kaczka]

Dzięki za pomoc, póki co to klikam <Przerwij>
Koledzy strasznie rozbudowali bazę, jest tam mnóstwo tabel z geometrią i chyba nie wszystkie są założone zgodnie z zasadami postgisa, ale jest to serwer testowy który obsługuje dane zebrane z całego miasta.
Danych jest naprawdę dużo : kilka schematów i może nawet tysiąc tabel.

pozdrawiam


K.

[PanKuleczka]

Dzięki za pomoc, póki co to klikam <Przerwij>
Koledzy strasznie rozbudowali bazę, jest tam mnóstwo tabel z geometrią i chyba nie wszystkie są założone zgodnie z zasadami postgisa, ale jest to serwer testowy który obsługuje dane zebrane z całego miasta.
Danych jest naprawdę dużo : kilka schematów i może nawet tysiąc tabel.

pozdrawiam


K.

Wyedytuj połączenie do postgisa i zaznacz mu fistaszka "Użyj szacunkowych metadanych tabeli". To ci pomoże.