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!).