Moja firma używa geometry( the_geom) typu danych do przechowywania danych geoprzestrzennych.

Niedawno zapoznałem się z koncepcją typu danych geography( the_geog), który, jak rozumiem, przechowuje SRIDwraz z geometrią.

Jakie są różnice pomiędzy geographya geometryi jest jakaś zaleta korzystania z nich w dużych bazach danych?

Funkcje geograficzne są zawsze przechowywane w WGS84 przed PostGIS 2.2; od tego czasu można stosować dowolny przestrzenny system odniesienia oparty na lon / lat. Pomiary oparte na cechach geograficznych będą wykonywane w metrach zamiast jednostek CRS, a PostGIS użyje obliczeń geodezyjnych zamiast geometrii płaskiej.

Nie wszystkie funkcje obsługują geometrię, ale można rzutować między geometrią a geografią. Bieżąca lista funkcji znajduje się na stronie : https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

Nie sądzę, że można polecić geografię lub geometrię dla dużych baz danych. To zależy od tego, co robisz ze swoimi danymi. Ponieważ obliczenia na kuli są bardziej skomplikowane, spodziewam się, że analizy będą wolniejsze w przypadku elementów geograficznych. Musisz także przekształcić wszystkie swoje dane do WGS84, aby korzystać z geografii.

Jeśli wykonujesz dużo pomiarów i np. Musisz porównać rozmiary dużych wielokątów, sensowniejsze byłoby użycie geografii niż geometrii.

Znalazłem następujące przydatne: http://postgis.net/workshops/postgis-intro/geography.html

Temat jest również omawiany w „PostGIS w akcji” (ISBN: 9781935182269).

Używam intuicyjnych „praktycznych zasad” ... Przydaje się do szybkiej decyzji,

• O twojej BAZIE DANYCH : jeśli cechy i / lub analiza przestrzenna są w skali kontynentalnej i wymagają precyzji (poważne zastosowania), użyj geografii . W przeciwnym razie użyj geometrii: gdy cała baza danych dotyczy tego samego regionu (w skali miasta ) lub nie potrzebujesz precyzji itp., Potrzebujesz tylko geometrii.
  Zobacz podobną zasadę na wykładzie sugerującym @underdark .

• O twoich potrzebach w zakresie WYDAJNOŚCI / BILANS PRECYZYJNY : geometria jest szybsza; jeśli potrzebujesz wydajności i myślisz o geografii, najpierw wykonaj swoje testy porównawcze.

Kluczowe idee

Na tej stronie widzimy kilka słów kluczowych i nacisk na niektóre pojęcia: precyzja , wydajność i coś w rodzaju elastyczności / towaru w użyciu .

Jak pamiętają inni, w przypadku przechowywania i obliczeń różnica polega na wykorzystaniu kuli w geografii i płaszczyzny w geometrii:

• kula (geografia) jest lepsza, bardziej precyzyjna. Zobacz przykład z Los Angeles / Paryża .
• ewolucja geografii: jak mówi @DavidF, „typ geograficzny został ostatnio dodany, więc mniej funkcji jest obsługiwanych / wdrażanych”.

Być może w 2020 r. Wszystkie bazy danych GIS zostaną ustawione na ten sam standard SRID / EPSG (równoważny obecnie kodowi 4326 dla WGS84). Dzisiaj geografia nie jest wyborem domyślnym z powodu ograniczeń wydajności i funkcjonalności.

Dyskusja

Moim zdaniem jest to kwestia „najlepszych praktyk”, a nie głęboki problem techniczny / teoretyczny.

Precyzja

Po oszacowaniu błędu w danych wykonaj testy i porównaj wyniki: przyrost precyzji z geografią jest wyższy niż błąd danych? Funkcja ST_Distance (z agregatorami MAX i AVG ) jest głównym odniesieniem w tego rodzaju eksperymencie.

Występ

Przykłady testów porównawczych w obszarze miejskim ~ 100 km2 (średnica ~ 11 km), wszystkie przechowywane jako geometria, w układzie współrzędnych płaskich UTM. UWAGA: zaczynając od często używanej konwersji geometrii / geografii - często ponieważ niektóre funkcje nie istnieją, a niektóre inne, takie jak ST_Buffer i ST_Intersection, dokonują konwersji wewnętrznie.

Ławka # 1: stół z ~ 87000 wielokątów reprezentujących działki miejskie, każdy z poli z (średnio) ~ 13 punktami,

 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS 
        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS 
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

więc geography_time = 6 * geometry_time.

Ławka # 2: tabela z ~ 3500 wielokątów reprezentujących bloki miejskie, każdy z poli z (średnio) ~ 50 punktów: 0,6s w porównaniu z 2,7s, geography_time = 4,5 * geometry_time.

Ławka nr 3: ~ 10000 linii reprezentujących ulice miast, każda z ~ 5 punktami. ~ 0,87s vs ~ 0,36s, geography_time = 2,4 * geometry_time.

Wróć do stanowiska nr 2, tworząc tabele i wykonując zapytania,

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

Wniosek: w przypadku małych zadań i dobrego sprzętu czasy są zbieżne z „akceptowalnym tym samym czasem”, ale w przypadku dużych zadań należy wziąć pod uwagę oceny wydajności.

Elastyczność / towar

W testach porównawczych wykonuję codzienne zadania, sprawdzając liczbę punktów (według ST_NPoints) ... Jest to przykład operacji, która nie istnieje dla geografii, wymaga obsady. „Obsada geografii / geometrii” jest denerwującym zadaniem dla programistów, mistrzów itp.

Przy ponownym użyciu bibliotek funkcji SQL i PL / pgSQL geografia wymaga adaptacji. A jeśli chcesz zoptymalizować kod lub uniknąć problemów z precyzją przy wielu konwersjach pośrednich, kolejnym problemem jest brak pełnego zestawu funkcji wbudowanych z geografią. Program dla geografii nie jest łatwym zadaniem.

Tylko proces, wymiana danych itp.

W przypadku niestandardowego zapotrzebowania, bez intensywnego użytkownika, takiego jak Mapserver, gdy twoją jedyną (PostGIS) pracą jest przetwarzanie danych wejściowych i zwracanie w dowolnym momencie (np. Godzin lub dni) przetworzonych danych, ogólna zasada brzmi „używaj geografii, jeśli są wygodne! ” (patrz „Elastyczność / towar” powyżej). Jeśli nie, sprawdź zwykłe zasady.
UWAGA: oczywiście, jeśli Twoim (nietypowym) zadaniem jest wyświetlanie tylko danych z PostGIS do Mapserver, bez potrzeby przetwarzania, aby zachować tę samą (geometrię lub geografię) twoich danych wejściowych, lepsza decyzja.

Uważam, że centralizacja danych to kolejne zadanie, w którym geografia jest lepsza: w kontekście, w którym różnorodność formatów wejściowych i systemów odniesienia jest zwykle, zastosowanie standardu, takiego jak ten wymuszony przez geografię, jest korzystne ... Konwencja w sprawie konfiguracji jest dobra zasada, gdy centralizacja i wymiana danych koncentrują się na działalności biznesowej (patrz Mapy Google!).

Uważam, że najbardziej znaczącą różnicą jest to, że w przypadku typu geograficznego obliczenia są wykonywane na kuli reprezentującej Ziemię, w przeciwieństwie do płaskiej powierzchni stosowanej w obliczeniach wykonanych na cechach typu geometrycznego.

Dokumenty są całkiem dobre: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

Typ geograficzny został ostatnio dodany, więc mniej funkcji jest obsługiwanych / wdrażanych.

Może uważasz, że ta funkcja - i odpowiedź - jest bezużyteczna, ale jedną z zalet pracy z geometriami jest to, że możesz pracować bez odniesienia przestrzennego (to znaczy SRID ustawiony na -1).

Obecnie pracuję w aplikacji, która filtruje unoszące się w powietrzu dane LiDAR, a wśród jego źródeł znajduje się baza danych PostGIS, która zapewnia indeksowanie przestrzenne pierwszej klasy ( RTree przez GiST ) i bez problemu radzi sobie z dużą ilością danych. Ponieważ ta aplikacja nie wymaga manipulowania ani analizowania cech geograficznych, nie jest potrzebny SRID, co pozwala uniknąć narzutu, jaki może to spowodować.