Я использую свои интуитивно понятные «эмпирические правила» ... Это полезно для быстрого решения,
О вашей базе данных : если объекты и / или пространственный анализ имеют континентальный масштаб и нуждаются в точности (серьезные приложения), используйте географию . Иначе используйте геометрию: когда вся база данных находится примерно в одной ( масштаб города ) области, или вам не нужна точность и т. Д., Вам нужна только геометрия.
Смотрите подобное правило на лекции по предложению @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!).