Jakiego układu współrzędnych należy użyć do przechowywania danych geograficznych dla współrzędnych niebieskich?

37

Robię projekt astronomiczny. Chcę, aby informacje o naszych obrazach były przechowywane w bazie danych z włączoną przestrzenią. Sądzę, że powinien to być bardzo łatwy specjalny przypadek funkcji GIS, ponieważ niebo można traktować jako idealnie kuliste i nie wymaga ono obróbki eliptycznej jak powierzchnia ziemi. Niestety, nie znalazłem jeszcze sposobu na zrobienie tego i unikałem kopalni za pomocą funkcji przestrzennych wykorzystujących ziemię eliptyczną. (Prawie każda funkcja, która zwraca metry zamiast stopni, może korzystać z obliczeń eliptycznych. Na szczęście wiele funkcji PostGIS, których potrzebowałem, wydaje się mieć niepełne implementacje, w których dokumentacja wyraźnie stwierdza, że ​​zwracane wyniki są dla kuli, a nie dla elipsoida. Ale to może się zmienić w przyszłych wersjach, co jest powodem do niepokoju.)

Tło: Obecnie używam PostgreSQL ze współrzędnymi PostGIS i WGS 84 (SRID = 4326). To działa całkiem dobrze. Tworzę zamknięty POLYGON z właściwego wzniesienia i deklinacji czterech rogów obrazu. Mam dużo zdjęć (10k lub więcej), pokrywających duży obszar nieba. Każde zdjęcie ma około 1 stopnia kwadratowego. Z zestawu tych obrazów wykonuję mozaiki z małych podzbiorów od 15 do 30 obrazów. Każda mozaika ma kwadrat około 1,5 stopnia.

Obecnie przechowuję geografię mozaiki jako MULTIPOLYGON, który składa się ze wszystkich POLYGONÓW odpowiadających każdemu obrazowi, który wszedł do mozaiki. [Lepszym rozwiązaniem byłoby stworzenie pojedynczego POLYGONU, który opisuje obwód unii wszystkich poszczególnych wielokątów. Nie wiem, czy można tego dokonać we współrzędnych sferycznych (tzn. Czy typ geograficzny). To też byłaby dla mnie interesująca odpowiedź.] Linia daty i bieguny niebieskie mogą być zawarte w obrazie w zestawie danych, dlatego unikałem projekcji na współrzędne planarne w możliwym zakresie.

Jakiego układu współrzędnych powinienem użyć dla współrzędnych niebieskich z funkcjami PostGIS?

Spojrzałem na http://spatialreference.org/, ale jak dotąd niczego nie znalazłem. Google niewiele się pojawiło. Jestem zakłopotany. Zasadniczo chcę się upewnić, że jeśli funkcja zwraca metry jako odległość, są to metry wzdłuż wielkiego koła na kuli.

Mówiąc bardziej ogólnie, docenione zostaną również niektóre porady dotyczące używania współrzędnych niebieskich w przestrzennej bazie danych.

Czy popełniłem błąd, wybierając PostGIS?

Czy istnieją znacznie lepsze wybory handlowe?

Wybory FOSS?


Używam PostGIS 1.5.2. Nie próbowałem jeszcze PostGIS 2.0. Jestem ciekawy, czy funkcja ST_CoveredBy współpracuje z POLYGON i MULTIPOLYGON o typie geograficznym. Jeśli ktoś korzysta z wersji 2.0, czy możesz mi powiedzieć, czy występuje ten sam błąd:

mydb=# select ST_CoveredBy(ST_GeographyFromText('MULTIPOLYGON(( (10.37795 -69.57926,8.9498 -69.54875,9.0178 -69.21643,10.4242 -69.24648,10.37795 -69.57926),(10.42436 -69.24618,9.01774 -69.2162,     9.08363 -68.88389,10.46914 -68.91344,10.42436 -69.24618)))'),ST_GeographyFromText('POLYGON((10.46915 -68.91315,9.08371 -68.88364,9.14755 -68.5513,10.5125 -68.58038,10.46915 -68.91315))'));
ERROR:  geography_covers: only POLYGON and POINT types are currently supported
CONTEXT:  SQL function "st_coveredby" statement 1

Próbowałem PostGIS 2.0. Ta funkcja nadal działa tylko na punktach i wielokątach, a nie na bardziej ogólnych kształtach.

Dr Osoba Osoba II
źródło
Czy to nie jest podobne do tego, co robi wcs2kml? Jeśli tak, być może możesz dostosować część kodu do swoich potrzeb. code.google.com/p/wcs2kml
Kirk Kuykendall
Natknąłem się na tę prezentację USGS, „PLANETARY GIS 101” i krótko zobaczyłem, że jest kilka slajdów na temat projekcji, może to ci pomoże.
jonatr
Zamiast tworzyć wiele wielokątów, dlaczego nie stworzyć wielu wielokątów, które mają wspólny identyfikator grupy?
raphael

Odpowiedzi:

17

Sprawdź pgsphere, jest on specjalnie zaprojektowany do obsługi danych astronomicznych.

http://pgsphere.projects.postgresql.org/

Paul Ramsey
źródło
To bardzo dobre rzeczy. Niestety wydaje się, że nie obsługuje żadnej „smultipolicznej” klasy geometrii. Dziękuję za wspaniałe informacje na temat tego projektu.
Dr. Person Person II
1
Kiedy próbuję skorzystać z tego linku, pojawia się komunikat „Zabronione Nie masz uprawnień dostępu do / na tym serwerze”.
PolyGeo
12

Istnieje możliwość przechowywania pozycji niebieskich w PostGIS - wystarczy stworzyć własny układ współrzędnych!

PostGIS pobiera wszystkie informacje o swoim układzie współrzędnych i rzucie z tabeli, spatial_ref_sysktóra jest zwykle wypełniana przy inicjalizacji bazy danych. Ale nic nie stoi na przeszkodzie, aby dodać własne projekcje - w rzeczywistości jest to praktycznie zalecane .

Podobnie jak prawie każdy GIS / przestrzenna baza danych / produkt mapujący, PostGIS używa Proj4 do swoich potrzeb w zakresie projekcji, dlatego należy umieścić ciąg Proj4 w spatial_ref_systabeli. Prosty w formie sferycznej SRS Proj4 jest: +proj=longlat +ellps=sphere +no_defs. PostGIS wymaga również wersji projekcji WKT, ale myślę, że jest to po prostu ładny tekst.

Będziesz także musiał wymyślić unikalny SRID dla nowego SRS, a także „autorytet”, ale może to być cokolwiek lubisz.

Aby wstawić nowy wpis spatial_ref_sys, po prostu wykonaj ten kod SQL:

insert into spatial_ref_sys values(40000, 'ME', 1, 
'GEOGCS["Normal Sphere (r=6370997)",DATUM["unknown",SPHEROID["sphere",6370997,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]]',
'+proj=longlat +ellps=sphere +no_defs');

Zauważ, że wybrałem 40000 jako SRID - jest to liczba, której używasz w tabeli obiektów niebieskich. Autorytetem jest „ME”, ale może to być twoje imię, organizacja lub cokolwiek naprawdę do 256 znaków. Następny numer, 1, to tylko twój unikalny identyfikator dla tego wpisu, w odniesieniu do organu. Teoretycznie możesz odnieść się do tego wpisu jako ME: 1, ale dla całego przetwarzania PostGIS liczy się jego unikalny SRID. Wpis WKT, który wygenerowałem za pomocą GDAL i Pythona:

import osgeo.osr as osr
srs = osr.SpatialReference()
srs.ImportFromProj4('+proj=longlat +ellps=sphere +no_defs')
srs.ExportToWkt()

Teraz zastrzeżenia:

  • Właściwe wniebowstąpienie będzie musiało być określone w stopniach, a nie w kątach godzinnych.
  • Wiele funkcji PostGIS nie jest zaprojektowanych dla nieprojektowanych danych, ale to ten sam problem, jeśli masz dane naziemne w WGS84 long / lat.
  • W obecnej postaci dane są geocentryczne. Jeśli chcesz wykonać z nim jakąkolwiek obserwację, sugeruję użycie czegoś takiego jak PyEphem .
  • Nie próbowałem tworzyć żadnych danych w tym SRS, więc YMMV.
  • Teraz jestem tym bardzo zainteresowany, więc być może będę musiał pobawić się importowaniem katalogu Hipparchos ... :)
MerseyViking
źródło
2
+1. Możesz zacząć od mapowania nieba, ładując wersję bazy danych HYG , mnożąc odpowiednie wzniesienie przez 15 i odejmując 180, aby przekonwertować na standardową „długość geograficzną” GIS i używając dowolnej idealnie kulistej bazy danych, którą lubisz. Do wyświetlania i mapowania projekcje gnomoniczne i ortograficzne są dość standardowe.
whuber
@whuber: i szerokość geograficzna? jest DEC?
Magno C
@MagnoC Tak, to prawda. Pola są opisane na stronie, do której linkowałem: po prostu przewiń trochę w dół. Aby to sprawdzić, zrzuciłem „małą” wersję (tylko 31K gwiazd) do programu do oglądania 3D, przekonwertowanego na współrzędne kartezjańskie (na jednostkowej sferze niebieskiej, ignorując odległość) i narysowałem je: wygląda dobrze.
whuber
@whuber: „RA, Dec: Prawidłowe wniebowstąpienie i deklinacja gwiazdy, dla epoki 2000.0. Gwiazdy obecne tylko w katalogu Gliese, który używa współrzędnych 1950.0, miały te współrzędne wcześniejsze do 2000”. Nie jestem tak jasny o Lat / Lon. Tak, LON = (RA*15) - 180i LAT = DEC?
Magno C
@MagnoC Znalazłem en.wikipedia.org/wiki/Equatorial_coordinate_system, który był pomocny w rozwiązaniu tego problemu .
whuber