Postgresql i postgis - Wersja do druku +- Forum QGIS (http://forum.quantum-gis.pl) +-- Dział: Desktop GIS (http://forum.quantum-gis.pl/forum-4.html) +--- Dział: QGIS (http://forum.quantum-gis.pl/forum-5.html) +--- Wątek: Postgresql i postgis (/thread-925.html) |
Postgresql i postgis - Kaczka - 22-04-2013 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 RE: Postgresql i postgis - borys - 24-04-2013 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). RE: Postgresql i postgis - sebaq - 26-04-2013 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! RE: Postgresql i postgis - borys - 26-04-2013 (26-04-2013, 08:10)sebaq napisał(a): Cześć! 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. Cytat: 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ą. Cytat: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). Cytat: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. Cytat: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... RE: Postgresql i postgis - sebaq - 26-04-2013 Wielkie dzięki Borys!! Wszystko wyjaśnione Pozdrawiam! RE: Postgresql i postgis - Kaczka - 29-04-2013 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. RE: Postgresql i postgis - PanKuleczka - 15-05-2013 (29-04-2013, 16:49)Kaczka napisał(a): Dzięki za pomoc, póki co to klikam <Przerwij> Wyedytuj połączenie do postgisa i zaznacz mu fistaszka "Użyj szacunkowych metadanych tabeli". To ci pomoże. |