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

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.

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

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

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