Tworzysz krąg w PostGIS?

22

Używam PostGIS 1.5.2 z geometriami w SRID: 900913. Muszę utworzyć koła, używając listy punktów jako środka, o promieniu 600 kilometrów. Korzystam z tego zapytania:

INSERT INTO circles (geom) (
   SELECT ST_Buffer(point, 600000, 'quad_segs=8') 
   FROM points
);

Ale utworzone koła nie mają promienia 600 kilometrów (promień jest bliski tej długości, ale nie dokładnie).

Czy istnieją inne metody tworzenia kręgów w PostGIS?

UWAGA: Przedstawione informacje pochodzą z Hiszpanii. Prawidłowa projekcja to 4326, ale klient używa rastrów Google, więc przechowuję dane w 900913, aby uniknąć ponownych rzutów i zwiększyć wydajność.

postgis postgis-1.5 angelcervera
źródło
1
Jak zmierzyłeś promienie, aby dowiedzieć się, że nie są to 600 km?
podmrok
1
@underdark Wiem, że odległość między dwoma miastami i okręgiem wygenerowana przy użyciu jako centrum jedno z tego miasta nie rozciąga się na inne miasto. Sprawdzam odległość między dwoma miastami za pomocą gmap-pedometer.com
angelcervera
3
Brzmi to związane z gis.stackexchange.com/questions/10148/...
podmroku
@underdark Korzystając ze SELECT ST_Distance( (select point from points where id = 7), (select point from points where id = 42));zwrotu o ponad 100 km różnicy, przestrzegaj gmap-pedometer.com, ale jeśli przypuszczam, że ta długość jest poprawna, promień okręgu jest idealny. Ale ludzie używają pierwszej odległości jako promienia, bez odległości zwracanej przez st_distance. Czy możliwe jest przekształcenie pierwszej odległości na drugą?
angelcervera

Odpowiedzi:

15

Spróbuj tego:

 SELECT ST_Transform(geometry( 
            ST_Buffer(geography( 
                ST_Transform( point, 4326 )), 
                600000)), 
            900913) FROM points`

To zmienia się w geografię, a następnie wykorzystuje wbudowany wybór SRID do (ironicznie) odwrócenia z powrotem do geometrii, w której uruchamiany jest dobry bufor płaski, a następnie odwraca się. Problem z twoim podejściem w Mercator polega na tym, że Mercator nie zachowuje odległości. Zastosowanie bardziej odpowiedniej lokalnej projekcji daje lepsze wyniki, i tak dzieje się w powyższej metodzie.

Paul Ramsey
źródło
4

Możesz zwiększyć wartość quad_seg, aby uzyskać dokładniejszy okrąg. Aby uzyskać prawdziwy okrąg, musisz pracować z zakrzywioną geometrią, ale nie wiem, jakie oprogramowanie może to pokazać.

Dokładność srida 90013 jest również bardzo zła, ponieważ jest to projekcja obejmująca cały świat.

Uzyskasz dokładniejszy wynik dzięki lokalnej projekcji.

Nicklas Avén
źródło
@ nicklas-aven Czy jest możliwe 100 km różnicy w odległości 600 km, ponieważ używam projekcji 900913, a nie 4326?
angelcervera
1
tak to mozliwe. sprawdź, czy Pauls skomentował ją, gdy nie mogłem uwierzyć w tę niedokładność gis.stackexchange.com/questions/3264/… . Chodzi o to, że 4326 nie jest wyświetlany.
Nicklas Avén
3

To zależy od tego, gdzie tworzone są twoje kręgi. Czy znajdują się w pobliżu równika lub bliżej biegunów?

Spójrz na tę mapę . Czy uważasz, że Antartica lub Grenlandia są tak duże? To jest projekcja, której używasz, prawda?

Polecam szybkie przeczytanie tego dokumentu USGS na temat rzutów , w szczególności poniższej tabeli, która daje szybki obraz tego, które rzuty są odpowiednie do czego.

A po tym wszystkim myślę, że powinienem w końcu odpowiedzieć na twoje pytanie :)

To, co powiedział Nicklas, było dobrą radą. Czy dla Twojej okolicy jest jakaś prognoza, która działałaby lepiej?

W przeciwnym razie warto przyjrzeć się nowemu typowi Geografii PostGIS . Niemniej jednak najbardziej odpowiednia odpowiedź zależy od tego, gdzie znajdują się Twoje dane.

AKTUALIZACJA: Odkąd wiemy, że Twoje dane znajdują się w Hiszpanii, czy zastanawiałeś się nad przechowywaniem ich w lokalnej projekcji, takiej jak UTM Zone 31N , wykonując swoje operacje, a następnie rzutując je z powrotem do Google Web Mercator?

Ragi Yaser Burhum
źródło
1
+1 za użycie typu geograficznego dla map obejmujących wielkie obszary. problem polega na tym, że w postgis nie ma natywnej funkcji bufora dla typu geograficznego. ale jest wbudowana obsada „najlepszego srida”, budowanie bufora, a następnie powrót do 4326. Zatem znajomość danych i ręczne wybranie srida daje lepszą kontrolę.
Nicklas Avén
Nicklas, masz rację co do castingu i zgadzam się z tobą w 100% na temat lokalnej projekcji (tj. Znajomości twoich danych). Niemniej jednak, jeśli odpowiedź brzmi, że po prostu chce mieć dane „ogólnoświatowe”, IMHO, logika rzutowania wewnątrz typu Geografia wykona znacznie lepszą robotę w ustaleniu, który SR jest odpowiedni dla tej konkretnej operacji na odległość, niż jakiejkolwiek innej skomplikowana logika niestandardowa. Kolejną dobrą rzeczą w typie geograficznym jest to, że chociaż wiele operacji jest obecnie kierowanych do matematyki kartezjańskiej, operacje są ciągle aktualizowane, aby używać matematyki sfery.
Ragi Yaser Burhum
2

Możesz użyć nowego typu geometrii SQL / MM część 3 CIRCULARSTRING i / lub CURVEPOLYGON.

Należy jednak pamiętać, że obsługa tego typu jest ograniczona, zarówno w przypadku funkcji wewnętrznych, jak i programów zewnętrznych. Możesz użyć ST_CurveToLine, aby pomóc w wizualizacji.

Co więcej, jest to nieco odstręczające (od PostGIS 2.0 svn), które SELECT ST_Area('CURVEPOLYGON(CIRCULARSTRING(2 1, 1 2, 0 1, 1 0, 2 1))'::geometry)jest jedynie przybliżonym przybliżeniem π . (Porównaj 3.14033115695475 z 3.14159265358979 od pi()).

Mike T.
źródło
Tak, najwyraźniej PostGIS przechowuje koła jako icosidodecagon.
Evan Carroll,