Я використовую свої інтуїтивні "великі правила" ... Це корисно для швидкого рішення,
Про вашу ДАТАБАЗУ : якщо функції та / або просторовий аналіз мають континентальний масштаб і потребують точності (серйозні програми), використовуйте географію . Інакше використовуйте геометрію: коли вся база даних приблизно однакової ( місто масштабу ) регіону, або вам не потрібна точність і т. Д., Вам потрібна лише геометрія.
Дивіться подібне правило на пропозиційній лекції @underdark .
Про ваші потреби в плані ВІДНОСНІСТЬ / РЕГІСТРУВАННЯ ПРЕЦІЗІЇ: геометрія швидша; якщо вам потрібна продуктивність і ви думаєте використовувати географію, спочатку зробіть свої орієнтири.
Ключові поняття
На цій сторінці ми бачимо деякі ключові слова та акцент на деяких поняттях: точність , продуктивність та щось на кшталт гнучкості / товару .
Як пам'ятають інші, різниця для зберігання та обчислень полягає у використанні сфери в географії та площини в геометрії:
- сфера (географія) краща, точніша. Дивіться приклад Лос-Анджелес / Париж .
- еволюція географії: як кажуть @DavidF, "тип географії був нещодавно доданий, тому менше функцій підтримується / реалізується".
Можливо, в 2020 році всі бази даних ГІС будуть встановлені на той самий стандарт SRID / EPSG (еквівалентно коду 4326 на сьогоднішній день для WGS84). Сьогодні географія не є вибором за замовчуванням через продуктивність та функціональні обмеження.
Обговорення
На мою думку, це питання "найкращої практики", а не глибокої технічної / теоретичної проблеми.
Точність
Оцінивши помилку ваших даних, зробіть тести та порівняйте результати: приріст точності з географією вище, ніж помилка даних? Функція ST_Distance (з агрегаторами MAX та AVG ) є основною орієнтиром у цьому експерименті.
Продуктивність
Приклади орієнтирів у міській місцевості ~ 100 км2 (діаметр ~ 11 км), усі вони зберігаються як геометрія в планарній системі координат UTM. ПРИМІТКА: починаючи з часто використовуваної конверсії геометрії / географії - часто тому, що деякі функції не існують, а деякі інші, такі як ST_Buffer і ST_Intersection, здійснюють перетворення всередині країни.
Лавка №1: таблиця з ~ 87000 багатокутників, що представляють міські ділянки, кожен з poly з (середньо) ~ 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 полігонами, що представляють міські блоки, кожен з poly з (середньою) ~ 50 балів: 0,6s проти 2,7s, geography_time = 4,5 * geometry_time.
Лавка №3: ~ 10000 ліній, що представляють міські вулиці, кожна з яких має ~ 5 балів. ~ 0,87s проти ~ 0,36s, geography_time = 2,4 * geometry_time.
Назад до лавки №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!).