Чи запропонував би PostGIS перевагу перед MySQL для додатків для виробництва ферм?


23

У мене є веб-додаток, який зберігає розташування ферм у Західному Мічигані. Ви можете шукати товар (наприклад, "брокколі"), і він покаже всі господарства, які вирощують цей продукт.

Зараз я використовую MySQL і використовую тригонометрію, щоб обчислити різницю між місцезнаходженням користувача та місцем розташування кожної ферми. Це не поганий шлях, але це зайняло певні дії.

Ще одна річ, яку я хочу незабаром зробити - це намітити сезони вегетації різних продуктів для різних регіонів. (Наприклад, я хочу показати, що авокадо росте в певний час року в Каліфорнії, але ніколи в Огайо.)

Я усвідомлюю, що це відкритий і, можливо, наївний питання, але чи варто для мене зробити перехід на PostgreSQL / PostGIS, щоб скористатися його просторовими можливостями?


1
Плануєте динамічні "сезонні" карти чи статичні?
underdark

Якщо я розумію, про що ви питаєте, динамічний. Приклад: вегетаційний період для яблук поблизу Гранд-Рапідс, Міссісі - серпень-жовтень.
Jason Swett

Відповіді:


21

Я великий шанувальник PostGIS і не маю досвіду роботи з MySQL, тому можу бути упередженим.

Але з того, що ви пишете, я думаю про дві причини переключення.

по-перше, напевно, буде набагато простіше реалізувати нові функції, як-от згадана вами карта сезону.

по-друге, коли ви сьогодні робите свої обчислення тригонометрії, я гадаю, що ви робите це поза межами дебюта. якщо ви все це зробите в db, ви набагато вільніші в розробці накладених додатків.

вам, ймовірно, не доведеться робити жодних обчислень поза db, якщо ви запускаєте postgis.

Те, що ви згадали про сезон, можна зробити в MySQL, оскільки це звучить дуже просто, але ви отримаєте більшу гнучкість у PostGIS з доступом до всіх просторових функцій.

/ Ніклас


18

Хоча б тому, що у вас буде набагато більше вибору у сторонніх додатках для генерування карт вашої інформації (mapserver, geoserver тощо, тощо) завантаження даних (ogr2ogr, fme тощо) PostGIS зробив би кращий вибір. MySQL підійде лише в тому випадку, якщо ваші потреби продовжують бути обмеженими.


FME підтримує MySQL, а також PostGIS.
Ворон

8

MySQL також має просторове розширення, але, наскільки я знаю (я його ніколи не використовував), він не настільки багатий на функції та стабільний, як PostGIS .

Якщо ви плануєте використовувати просторову базу даних, PostGIS - це хороший вибір, і зусилля щодо перемикання будуть варті.

Хоча MySQL вже надає певну функціональність для зберігання та роботи на геопросторових даних, функціонал залишає бажати кращого і далеко не забезпечує повну сумісність OpenGIS.

Найбільше, що всі функції, які запитують просторові дані, працюють лише на MBR (мінімальні обмежувальні прямокутники) для спрощення операцій.

http://forge.mysql.com/wiki/GIS_Functions


6

Битва MySQL проти Postgis знову піднімається:

http://ambergis.wordpress.com/2008/02/19/mysql-vs-postgis/

Зверніть увагу, що більшість коментарів звідси (тут, обмін стеками.)

посилання теж

http://www.spatiallyadjusted.com/2008/02/05/bringing-open-source-gis-into-an-esri-shop/#comment-32680

Були більш успішні розгортання з postgis, ніж mysql. (залежать від налаштування клієнтів і того, що вони намагаються досягти)

Моя єдина пропозиція до Пола Рамзі (та команди PostGIS) - це приємний графічний інтерфейс для постгігів через PgAdmin (v4 ..?) З візуалізатором (як FME безпечного програмного забезпечення) - не просто атрибути були б головним плюсом. В даний час використовуйте QGIS для візуалізації даних постгістів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.