Выбор между форматами хранения координат

[heleo]

Доброго времени суток.

Коротенько опишу проблему: В БД проекта приходится хранить координаты объектов, в legacy коде изначально было хранение координат в радианах (при этом долгота была смещена, т.е. левая часть [-180 : 0) пересчитывались в (180 360]). Сейчас трюки с пересчётом ушли в прошлое и координаты продолжают храниться с использованием радиан, но уже под "соусом" PostGIS.

Тут возникает основной вопрос и пару дополнительных:
1. Координаты можно хранить в различных видах: радианы, градусы десятичные, метры. В принципе PostGIS это позволяет без особых проблем. Но всё же червячок сомнений гложет и возникает вопрос: какой вид для хранения считается наилучшим? (Радианы для хранения мы использовали де факто из-за расчётов, но это не принципиально).

2. Может кто-то сталкивался с "поворотом" долготы и может пояснить для чего могли такое делать?

3. В связи с приснопамятным переходом на ПЗ-90.11, можете пояснить каким образом координаты записывать в БД (интересует SRID для ПЗ-90.х)?

4. Если хранить в радианах или десятичных градусах, то сколько знаков после запятой считается нормальной точностью вплоть до сотых секнды?

Заранее благодарен за любую помощь!

[Ariki]

1. Принято хранить в градусах. Можно использовать тип geography, хотя во многих случаях удобней всё-таки по-старинке в geometry (больше функций доступно), а в geography кастовать по необходимости, когда нужны расчёты на эллипсоиде.
2. Трудно сказать. Возможно, разработчики решили, что с неотрицательными числами работать удобнее. Если данные на Россию, Чукотка не отваливается.
3. Добавьте своё определение в таблицу spatial_ref_sys. Из коробки там есть только старая ПЗ-90 (во всяком случае, в той версии, что установлена у меня). Разница будет только в параметрах перехода к WGS84. О стандартном SRID для ПЗ-90.11 слышать не приходилось (может, кто-нибудь знает?) Вроде бы значения больше 32768 зарезервированы для пользовательских определений, можно выбрать любой из этого диапазона.
4. Шести знаков после запятой будет достаточно.

[heleo]

Спасибо за ответы.

Но тогда есть ещё пара моментов:

1. Принято хранить в градусах. Можно использовать тип geography, хотя во многих случаях удобней всё-таки по-старинке в geometry (больше функций доступно), а в geography кастовать по необходимости, когда нужны расчёты на эллипсоиде.

А каким образом PostGIS, точнее даже функционал библиотеки geos, различают в чём им передают координаты при произведении расчётов? Закладка параметра в SRID?

4. Шести знаков после запятой будет достаточно.

Для градусов соглашусь. Для радиан по подсчётам 8 знаков.

[Ariki]

А каким образом PostGIS, точнее даже функционал библиотеки geos, различают в чём им передают координаты при произведении расчётов? Закладка параметра в SRID?

Если вы посмотрите определения систем координат в столбцах srtext и proj4text таблицы spatial_ref_sys, то найдёте там указание на единицы измерения.

Для градусов соглашусь. Для радиан по подсчётам 8 знаков.

Совершенно верно.

[Дмитрий Барышников]

А каким образом PostGIS, точнее даже функционал библиотеки geos, различают в чём им передают координаты при произведении расчётов? Закладка параметра в SRID?

Кажется libgeos все расчеты делает на плоскости. А вот на сфере у PostGIS есть своя библиотека - liblwgeom.

[Ariki]

Да, действительно, поэтому geos'у всё равно, в каких единицах координаты. Если нужно считать буфера или расстояния, нужно либо преобразовывать в geography, переведя предварительно в градусы, либо явно использовать функции, работающие на сфере или эллипсоиде (опять-таки подразумеваются градусы), или использовать проекцию с допустимыми для конкретной задачи искажениями (в этом случае результат будет в единицах проекции).

[heleo]

А каким образом PostGIS, точнее даже функционал библиотеки geos, различают в чём им передают координаты при произведении расчётов? Закладка параметра в SRID?

Кажется libgeos все расчеты делает на плоскости. А вот на сфере у PostGIS есть своя библиотека - liblwgeom.

Спасибо. Погуглил что там в сорцах.

* PROJ4 (Required, Version 4.6.0 or higher):
The PROJ4 catographic projection library is required if you want to use the
ST_Transform() function to reproject features within the database.

* GEOS (Required, Version 3.3.0 or higher
- 3.4+ is strongly recommended and needed for full features):
The GEOS library provides support for exact topological tests such as
ST_Touches(), ST_Contains(), ST_Disjoint() and spatial operations such as
ST_Intersection(), ST_Union() and ST_Buffer(). GEOS 3.4+ is recommended.

Если верить их README.postgis, получается библиотека liblwgeom служит для поддержки топологии, если под этим подразумевается "сфера", ну что же будем знать теперь)

[heleo]

Да, действительно, поэтому geos'у всё равно, в каких единицах координаты. Если нужно считать буфера или расстояния, нужно либо преобразовывать в geography, переведя предварительно в градусы, либо явно использовать функции, работающие на сфере или эллипсоиде (опять-таки подразумеваются градусы), или использовать проекцию с допустимыми для конкретной задачи искажениями (в этом случае результат будет в единицах проекции).

Благадарствую. Значит будем переходить на десятичные градусы в дальнейшем.