Будет ли PostGIS иметь преимущество перед MySQL для приложения на ферме?


23

У меня есть веб-приложение, которое хранит информацию о местонахождении ферм в Западном Мичигане. Вы можете искать продукт (например, «брокколи»), и он покажет вам все фермы, которые выращивают этот продукт.

Прямо сейчас я использую MySQL и тригонометрию, чтобы вычислить разницу между местоположением пользователя и местоположением каждой фермы. Это не плохой путь, но это заняло некоторое время.

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

Я понимаю, что это открытый и, возможно, наивный вопрос, но стоит ли мне переходить на PostgreSQL / PostGIS, чтобы воспользоваться его пространственными возможностями?


1
Вы планируете динамические "сезонные" карты или статические?
Подземье

Если я понимаю, что вы спрашиваете, динамичный. Пример: вегетационный период для яблок вблизи Гранд-Рапидс, Мичиган, с августа по октябрь.
Джейсон Светт

Ответы:


21

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

Но из того, что ты пишешь, я думаю о двух причинах перехода.

Во-первых, вам, безусловно, будет гораздо проще реализовать новые функции, такие как указанная вами карта сезона.

во-вторых, когда вы сегодня делаете свои тригонометрические вычисления, я полагаю, что вы делаете это вне БД. если вы делаете все это в БД, то вы намного свободнее в разработке оверлейных приложений.

вам, вероятно, не придется делать какие-либо вычисления вне базы данных, если вы запустите postgis.

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

/ Никлас


18

Хотя бы потому, что у вас будет намного больший выбор в сторонних приложениях для создания карт вашей информации (картосервер, геосервер и т. Д.) И загрузки данных (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) - это хороший графический интерфейс для postgis через PgAdmin (v4 ..?) С визуализатором (как FME безопасного программного обеспечения) - не только атрибуты были бы основным плюсом. В настоящее время используйте QGIS для визуализации данных postgis.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.