Моя компания использует тип данных geometry( the_geom) для хранения геопространственных данных.

Недавно я был знаком с концепцией geography( the_geog) типа данных, который, насколько я понимаю, хранит SRIDвместе с геометрией.

Каковы различия между geographyи geometry, и есть какие - либо преимущества использования одного из них в больших базах данных?

Географические особенности всегда хранятся в WGS84 до PostGIS 2.2; с тех пор может использоваться любая система пространственной привязки на основе lon / lat. Измерения, основанные на географических объектах, будут в метрах вместо единиц CRS, а PostGIS будет использовать геодезические расчеты вместо плоской геометрии.

Не все функции поддерживают геометрию, но вы можете выполнять выбор между геометрией и географией. Текущий список функций см .: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions.

Я не думаю, что можно рекомендовать географию или геометрию для больших баз данных. Это зависит от того, что вы делаете со своими данными. Поскольку вычисления в сфере более сложны, я ожидаю, что анализ географических объектов будет медленнее. Вы также должны преобразовать все свои данные в WGS84, чтобы использовать географию.

Если вы выполняете много измерений и, например, должны сравнивать размеры больших полигонов, имеет смысл использовать географию, а не геометрию.

Я нашел следующее полезное: http://postgis.net/workshops/postgis-intro/geography.html

Тема также освещена в «PostGIS в действии» (ISBN: 9781935182269).

Я использую свои интуитивно понятные «эмпирические правила» ... Это полезно для быстрого решения,

• О вашей базе данных : если объекты и / или пространственный анализ имеют континентальный масштаб и нуждаются в точности (серьезные приложения), используйте географию . Иначе используйте геометрию: когда вся база данных находится примерно в одной ( масштаб города ) области, или вам не нужна точность и т. Д., Вам нужна только геометрия.
  Смотрите подобное правило на лекции по предложению @underdark .

• О ваших потребностях с точки зрения РАБОЧЕГО / ТОЧНОГО БАЛАНСА: геометрия быстрее; если вам нужна производительность и вы думаете, чтобы использовать географию, сначала сделайте свои тесты.

Ключевые понятия

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

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

• сфера (география) лучше, точнее. Смотрите пример Лос-Анджелес / Париж .
• Эволюция географии: как говорит @DavidF, «тип географии был добавлен совсем недавно, поэтому меньше функций поддерживается / реализуется».

Возможно, к 2020 году все базы данных ГИС будут настроены на один и тот же стандартный SRID / EPSG (эквивалент для современного кода 4326 для WGS84). Сегодня география не является выбором по умолчанию из-за производительности и функциональных ограничений.

обсуждение

На мой взгляд, это вопрос «лучших практик», а не глубокая техническая / теоретическая проблема.

точность

После оценки погрешности ваших данных проведите тесты и сравните результаты: прирост точности с географией выше, чем погрешность данных? Функция ST_Distance (с агрегаторами MAX и AVG ) является основным эталоном в этом виде эксперимента.

Представление

Примеры эталонных тестов в городской местности ~ 100 км2 (диаметр ~ 11 км), все они хранятся в виде геометрии в плоской системе координат UTM. ПРИМЕЧАНИЕ: начиная с часто используемого преобразования геометрии / географии - часто потому, что некоторые функции не существуют, а некоторые другие, такие как ST_Buffer и ST_Intersection, выполняют преобразование внутренне.

Скамья № 1: таблица с ~ 87000 полигонов, представляющих городские участки, каждый с поли с (avg) ~ 13 баллами,

 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS 
        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS 
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

Итак, geography_time = 6 * geometry_time.

Скамейка № 2: таблица с ~ 3500 полигонами, представляющими городские кварталы, каждый с поли с (avg) ~ 50 баллами: 0,6 с против 2,7 с, geography_time = 4.5 * geometry_time.

Скамья № 3: ~ 10000 линий, представляющих городские улицы, каждая с ~ 5 точками. ~ 0,87 с против ~ 0,36 с, geography_time = 2,4 * geometry_time.

Вернемся к Bench # 2, создание таблиц и выполнение запросов,

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

Вывод: для небольших задач и хороших аппаратных средств время сходится к «приемлемому времени», но для больших задач необходимо учитывать рейтинги производительности.

Гибкость / товар

На тестах я делаю ежедневное задание, проверяя количество баллов (по ST_NPoints) ... Это пример операции, которая не существует для географии, нуждается в приведении. «География / геометрия» - раздражающая задача для программистов, мастеров и т. Д.

При повторном использовании библиотек функций SQL и PL / pgSQL география нуждается в адаптации. И, если вы хотите оптимизировать код или избежать проблем с точностью при большом количестве промежуточных преобразований, отсутствие полного набора встроенных функций с географией является другой проблемой. Программа по географии, задача не из легких.

Только процесс, обмен данными и т. Д.

В случае необычного спроса, когда нет интенсивного пользователя, такого как Mapserver, когда ваша единственная (PostGIS) работа заключается в обработке входных данных и возврате в любое время (например, часов или дней) обработанных данных, практическое правило гласит: «используйте географию, если вы удобны! (см. «Гибкость / Товар» выше). Если нет, проверьте обычные правила.
ПРИМЕЧАНИЕ: конечно, если ваша (не обычная) задача - показывать только данные из PostGIS на Mapserver, без необходимости процесса, для сохранения того же (геометрия или география) ваших входных данных, это лучшее решение.

Я полагаю, что централизация данных - это еще одна задача, где география лучше: в контексте, где разнообразие входных форматов и эталонных систем является обычным, использование стандарта, такого как тот, что обеспечивается географией, выгодно ... Соглашение по конфигурации - это хороший принцип, когда централизация и обмен данными находятся в центре внимания бизнеса (см. Google Maps!).

Я полагаю, что наиболее существенным отличием является то, что с географическим типом вычисления выполняются на сфере, представляющей Землю, а не на плоской поверхности, используемой в вычислениях, выполненных на объектах типа геометрии.

Документы довольно хороши: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

Тип географии был добавлен совсем недавно, поэтому поддерживаются / реализуются меньше функций.

Возможно, вы найдете эту функцию - и ответ - бесполезной, но одно из преимуществ работы с геометриями заключается в том, что вы можете работать без какой-либо пространственной привязки (то есть SRID установлен в -1).

В настоящее время я работаю в приложении, которое фильтрует бортовые данные LiDAR, среди его источников данных - база данных PostGIS, которая обеспечивает пространственную индексацию первого класса ( RTree поверх GiST ) и без проблем справляется с большим объемом данных. Поскольку это приложение не требует манипулирования или анализа географических объектов, SRID не требуется, что позволяет избежать накладных расходов, которые оно может принести.