¿Qué sistema de coordenadas debería usarse para almacenar datos de geografía para coordenadas celestes?

37

Estoy haciendo un proyecto de astronomía. Quiero tener la información sobre nuestras imágenes almacenadas en una base de datos espacialmente habilitada. Creo que este debería ser un caso especial muy fácil para las funciones SIG porque el cielo puede tratarse como perfectamente esférico y no requiere un tratamiento elíptico como la superficie de la tierra. Desafortunadamente, todavía no he encontrado una forma de hacerlo y he estado esquivando minas con funciones espaciales que usan una tierra elíptica. (Casi cualquier función que devuelve metros en lugar de grados puede estar usando un cálculo elíptico. Afortunadamente, muchas de las funciones PostGIS que he necesitado parecen tener implementaciones incompletas donde la documentación declara explícitamente que los resultados devueltos son para una esfera y no para el elipsoide. Pero eso puede cambiar con versiones futuras, lo cual es motivo de preocupación).

Antecedentes: Actualmente estoy usando PostgreSQL con coordenadas PostGIS y WGS 84 (SRID = 4326). Esto funciona bastante bien. Estoy creando un POLÍGONO cerrado a partir de la ascensión recta y la declinación de las cuatro esquinas de la imagen. Tengo muchas imágenes (10k o más), que cubren una gran área del cielo. Cada imagen es de aproximadamente 1 grado cuadrado. Del conjunto de estas imágenes, estoy haciendo mosaicos de pequeños subconjuntos de 15 a 30 imágenes. Cada mosaico es de aproximadamente 1,5 grados cuadrados.

Actualmente, estoy almacenando la geografía de los mosaicos como un MULTIPOLÍGONO que consiste en todos los POLÍGONOS correspondientes a cada imagen que entró en el mosaico. [Una mejor solución sería crear un POLÍGONO único que describa el perímetro de la unión de todos los polígonos individuales. No sé si esto se puede hacer en coordenadas esféricas (es decir, que el tipo de geografía). Esta también sería una respuesta interesante para mí.] La línea de fecha y los polos celestes pueden incluirse en una imagen en el conjunto de datos, por lo que he evitado proyectar coordenadas planas en la medida de lo posible.

¿Qué sistema de coordenadas debería usar para las coordenadas celestes con las funciones de PostGIS?

He mirado en http://spatialreference.org/ pero no he encontrado nada hasta ahora. Google ha aparecido poco. Estoy perplejo Básicamente, quiero asegurarme de que si una función devuelve metros como una distancia, es metros a lo largo de un gran círculo en una esfera.

En términos más generales, también se agradecerían algunos consejos para utilizar coordenadas celestes en una base de datos espacial.

¿He errado al elegir PostGIS?

¿Hay opciones comerciales muy superiores?

Opciones de software libre?


Estoy usando PostGIS 1.5.2. Todavía no he probado PostGIS 2.0. Tengo curiosidad por saber si la función ST_CoveredBy funciona con un POLYGON y un MULTIPOLYGON de tipo geografía. Si alguien está ejecutando 2.0, ¿podría decirme si obtiene el mismo error que este:

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

He intentado con PostGIS 2.0. Esta función solo funciona en puntos y polígonos, no en formas más generales.

Dr. Persona Persona II
fuente
¿No es esto similar a lo que hace wcs2kml? Si es así, tal vez podría adaptar parte del código para sus usos. code.google.com/p/wcs2kml
Kirk Kuykendall
Me encontré con esta presentación de USGS, "PLANETARY GIS 101" y brevemente vi que hay algunas diapositivas en las proyecciones, tal vez te ayude.
jonatr
En lugar de crear multipolígonos, ¿por qué no crear múltiples polígonos que comparten una identificación de agrupación?
Rafael

Respuestas:

17

Echa un vistazo a pgsphere, está específicamente diseñado para manejar datos astronómicos.

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

Paul Ramsey
fuente
Esto es muy bueno. Desafortunadamente, no parece admitir ninguna clase de geometría "smultipoly". Sin embargo, gracias por el gran aviso de este proyecto.
Dr. Person Person II
1
Cuando trato de seguir este enlace aparece "Prohibido No tienes permiso para acceder / en este servidor".
PolyGeo
12

Es posible almacenar posiciones celestes en PostGIS: ¡solo necesita crear su propio sistema de coordenadas!

PostGIS obtiene todo su sistema de coordenadas e información de proyección de la tabla spatial_ref_sysque normalmente se rellena cuando se inicializa la base de datos. Pero no hay nada que le impida agregar sus propias proyecciones; de hecho, es prácticamente recomendable .

En común con casi todos los productos GIS / base de datos espacial / mapeo que existen, PostGIS usa Proj4 para sus necesidades de proyección, por lo que debe colocar una cadena Proj4 en la spatial_ref_systabla. Un SRS esférica simple en su forma Proj4 es: +proj=longlat +ellps=sphere +no_defs. PostGIS también requiere una versión WKT de la proyección, pero creo que solo se usa como texto bonito.

También necesitará un SRID único para su nuevo SRS, así como una "autoridad", pero esto puede ser lo que quiera.

Entonces, para insertar una nueva entrada spatial_ref_sys, solo realice este 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');

Tenga en cuenta que he elegido 40000 como SRID: este es el número que usa en su tabla de objetos celestes. La autenticidad es "YO", pero este podría ser su nombre, organización o cualquier cosa de hasta 256 caracteres. El siguiente número, 1, es solo su identificador único para esa entrada, en relación con la autoridad. En teoría, podría referirse a esta entrada como ME: 1, pero para todo el procesamiento de PostGIS, es el SRID único lo que cuenta. La entrada WKT que generé con GDAL y Python:

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

Ahora las advertencias:

  • La ascensión recta deberá especificarse en grados en lugar de ángulos horarios.
  • Varias funciones de PostGIS no están diseñadas para datos no proyectados, pero es el mismo problema si tiene datos terrestres en WGS84 long / lat.
  • Tal como están las cosas, los datos son geocéntricos. Si quieres hacer algún trabajo de observación con él, sugiero usar algo como PyEphem .
  • No he intentado crear ningún dato en este SRS, así que YMMV.
  • Sin embargo, ahora estoy bastante interesado en esto, así que quizás tenga que jugar con la importación del catálogo Hipparchos ... :)
MerseyViking
fuente
2
+1. Puede comenzar bien el mapeo de los cielos cargando una versión de la base de datos HYG , multiplicando la ascensión recta por 15 y restando 180 para convertir a una "longitud" GIS estándar, y utilizando cualquier dato perfectamente esférico que desee. Para visualización y mapeo, las proyecciones gnomónicas y ortográficas son bastante estándar.
whuber
@whuber: y la latitud? es el DEC?
Magno C
@ MagnoC Sí, eso es correcto. Los campos se describen en el sitio web al que me vinculé: solo desplácese un poco hacia abajo. Para verificarlo, descargué la versión "pequeña" (solo 31K estrellas) en un programa de visualización en 3D, convertida a coordenadas cartesianas (en una esfera celeste unitaria, ignorando la distancia), y las tracé: se ve bien.
whuber
@whuber: "RA, Dec: la ascensión recta y la declinación de la estrella, para la época 2000.0. Las estrellas presentes solo en el Catálogo Gliese, que usa coordenadas 1950.0, han tenido estas coordenadas precesadas a 2000". No estoy tan claro sobre Lat / Lon. Entonces, LON = (RA*15) - 180y LAT = DEC?
Magno C
@MagnoC He encontrado que en.wikipedia.org/wiki/Equatorial_coordinate_system es útil para resolver esto.
whuber