Какую систему координат следует использовать для хранения географических данных для небесных координат?

37

Я делаю астрономический проект. Я хочу, чтобы информация о наших изображениях сохранялась в пространственно включенной базе данных. Это, я думаю, должно быть очень простым особым случаем для ГИС-функций, потому что небо можно рассматривать как совершенно сферическое и не требует эллиптической обработки, как поверхность земли. К сожалению, я еще не нашел способ сделать это, и я уклоняюсь от шахт с пространственными функциями, которые используют эллиптическую землю. (Практически любая функция, которая возвращает метры вместо градусов, может использовать эллиптическое вычисление. К счастью, многие из необходимых мне функций PostGIS имеют неполные реализации, где в документации явно говорится, что возвращаемые результаты относятся к сфере, а не к эллипсоид. Но это может измениться с будущими версиями, что является причиной для беспокойства.)

Справочная информация: в настоящее время я использую PostgreSQL с координатами PostGIS и WGS 84 (SRID = 4326). Это работает довольно хорошо. Я создаю замкнутый ПОЛИГОН из правильного восхождения и склонения четырех углов изображения. У меня есть много изображений (10k или более), охватывающих большую область неба. Каждое изображение около 1 градуса. Из набора этих изображений я делаю мозаику из небольших подмножеств от 15 до 30 изображений. Каждая мозаика имеет площадь около 1,5 градуса.

В настоящее время я сохраняю географию мозаик как МНОГОПОЛИГОН, который состоит из всех ПОЛИГОНОВ, соответствующих каждому изображению, которое вошло в мозаику. [Лучшим решением было бы создать один полигон, который описывает периметр объединения всех отдельных полигонов. Я не знаю, может ли это быть сделано в сферических координатах (то есть, что тип географии). Это также было бы интересным ответом и для меня.] Линия даты и небесные полюса могут быть включены в изображение в наборе данных, поэтому я избегаю проецирования на плоские координаты в максимально возможной степени.

Какую систему координат я должен использовать для небесных координат с функциями PostGIS?

Я посмотрел на http://spatialreference.org/, но пока не нашел ничего. Гугл появился мало. Я в тупике. По сути, я хочу убедиться, что если функция возвращает метры как расстояние, то это метры вдоль большого круга на сфере.

В более общем смысле, некоторые советы по использованию небесных координат в пространственной базе данных также будут оценены.

Я ошибся, выбрав PostGIS?

Есть ли намного более высокий коммерческий выбор?

Выбор FOSS?


Я использую PostGIS 1.5.2. Я еще не пробовал PostGIS 2.0. Мне любопытно, если функция ST_CoveredBy работает с POLYGON и MULTIPOLYGON типа география. Если кто-нибудь использует 2.0, не могли бы вы сказать мне, если вы получаете ту же ошибку, как это:

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

Я попробовал PostGIS 2.0. Эта функция все еще работает только с точками и полигонами, а не с более общими фигурами.

Доктор Человек Персона II
источник
Разве это не похоже на то, что делает wcs2kml? Если это так, возможно, вы могли бы адаптировать часть кода для ваших нужд. code.google.com/p/wcs2kml
Кирк Куйкендалл
Я наткнулся на эту презентацию USGS «ПЛАНЕТАРНАЯ ГИС 101» и кратко увидел, что есть несколько слайдов по прогнозам, возможно, это поможет вам.
Джонатр
Вместо создания мультиполигонов, почему бы не создать несколько полигонов, которые имеют идентификаторы группировки?
Рафаэль

Ответы:

17

Посмотрите pgsphere, он специально разработан для обработки астрономических данных.

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

Пол Рэмси
источник
Это очень хорошая вещь. К сожалению, он не поддерживает какой-либо "smultipoly" класс геометрии. Спасибо за отличный хедз-ап на этот проект.
Доктор Человек Персонал II
1
Когда я пытаюсь перейти по этой ссылке, я получаю сообщение «Запрещено. У вас нет разрешения на доступ / на этом сервере».
PolyGeo
12

В PostGIS можно хранить небесные координаты - вам просто нужно создать собственную систему координат!

PostGIS получает всю свою систему координат и информацию о проекции из таблицы, spatial_ref_sysкоторая обычно заполняется при инициализации базы данных. Но ничто не мешает вам добавлять свои собственные прогнозы - это действительно поощряется .

Как и почти все ГИС / пространственные базы данных / картографические продукты, PostGIS использует Proj4 для своих потребностей проецирования, поэтому вам нужно поместить строку Proj4 в spatial_ref_sysтаблицу. Простой сферический SRS в форме Proj4:+proj=longlat +ellps=sphere +no_defs . PostGIS также требует версию проекции WKT, но я думаю, что это просто текст.

Вам также потребуется придумать уникальный SRID для вашей новой SRS, а также «авторитет», но это может быть все, что вам нравится.

Чтобы вставить новую запись spatial_ref_sys, просто выполните этот 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');

Обратите внимание, что я выбрал 40000 в качестве SRID - это число, которое вы используете в своей таблице небесных объектов. Authroity - «ME», но это может быть ваше имя, организация или что-то действительно длиной до 256 символов. Следующее число, 1, это просто ваш уникальный идентификатор для этой записи относительно полномочий. Теоретически вы можете ссылаться на эту запись как ME: 1, но для всей обработки PostGIS это уникальный SRID, который имеет значение. Запись WKT, которую я создал с помощью GDAL и Python:

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

Теперь предостережения:

  • Правильное восхождение должно быть указано в градусах, а не в часах.
  • Некоторые функции PostGIS не предназначены для непроецированных данных, но это та же проблема, если у вас есть наземные данные в WGS84 long / lat.
  • В настоящее время данные являются геоцентрическими. Если вы хотите сделать какую-либо наблюдательную работу с ним, я предлагаю использовать что-то вроде PyEphem .
  • Я не пробовал создавать какие-либо данные в этой SRS, поэтому YMMV.
  • Хотя сейчас я весьма заинтересован в этом, поэтому мне, возможно, придется поиграться с импортом каталога Hipparchos ... :)
MerseyViking
источник
2
+1. Вы можете получить хорошее начало при картировании небес, загрузив версию базы данных HYG , умножив правильное восхождение на 15 и вычтя 180, чтобы преобразовать в стандартную «долготу» ГИС, и используя любые идеально сферические данные, которые вам нравятся. Для отображения и картирования, гномические и орфографические проекции являются довольно стандартными.
whuber
@whuber: а широта? такое DEC?
Магно C
@MagnoC Да, это правильно. Поля описаны на сайте, на который я ссылаюсь: просто прокрутите немного вниз. Чтобы проверить это, я сбросил «маленькую» версию (всего 31K звездочек) в программу трехмерного просмотра, преобразовал ее в декартовы координаты (на единичной небесной сфере, игнорируя расстояние) и нарисовал их: выглядит хорошо.
whuber
@whuber: «RA, декабрь: прямое восхождение и склонение звезды, для эпохи 2000.0. У звезд, присутствующих только в каталоге Gliese, который использует координаты 1950.0, эти координаты были предварительно обработаны до 2000». Мне не очень понятно про Лат / Лон. Так LON = (RA*15) - 180а LAT = DEC?
Magno C
@MagnoC Я нашел en.wikipedia.org/wiki/Equatorial_coordinate_system, чтобы помочь разобраться в этом.
whuber