PostGIS offrirebbe un vantaggio rispetto a MySQL per un'applicazione di produzione agricola?


23

Ho un'app Web che memorizza le posizioni delle fattorie nel West Michigan. Puoi cercare un prodotto (ad esempio "broccoli") e ti mostrerà tutte le aziende agricole che coltivano quel prodotto.

In questo momento sto usando MySQL e utilizzo la trigonometria per calcolare la differenza tra la posizione dell'utente e la posizione di ogni farm. Non è una brutta strada da percorrere, ma ci è voluto del tempo.

Un'altra cosa che voglio fare presto è mappare le stagioni di crescita per diversi prodotti per diverse regioni. (Ad esempio, voglio dimostrare che gli avocado crescono in un certo periodo dell'anno in California ma mai nell'Ohio.)

Mi rendo conto che si tratta di una domanda aperta e forse ingenua, ma potrebbe valerne la pena passare a PostgreSQL / PostGIS per sfruttare le sue capacità spaziali?


1
Stai pianificando mappe "stagionali" dinamiche o statiche?
underdark

Se capisco cosa stai chiedendo, dinamico. Esempio: la stagione di crescita per le mele vicino a Grand Rapids, MI va da agosto a ottobre.
Jason Swett,

Risposte:


21

Sono un grande fan di PostGIS e non ho esperienza con MySQL, quindi devo essere di parte.

Ma da quello che scrivi penso a due motivi per passare.

in primo luogo, sarà sicuramente molto più semplice implementare nuove funzionalità come la mappa stagionale che hai citato.

secondo, quando oggi fai i tuoi calcoli di trigonometria immagino che tu lo stia facendo fuori dal db. se fai tutto ciò nel db invece sei molto più libero nello sviluppo delle applicazioni sovrapposte.

probabilmente non dovrai fare alcun calcolo al di fuori del db se esegui Postgis.

la cosa della stagione che hai citato potrebbe essere fattibile in MySQL dal momento che suona molto semplice ma avrai una maggiore flessibilità in PostGIS con accesso a tutte le funzionalità spaziali.

/ Nicklas


18

Se solo perché avrai molta più scelta nelle applicazioni di terze parti per generare mappe dei tuoi dati (mapserver, geoserver, ecc.) Caricando dati (ogr2ogr, fme, ecc.) PostGIS farebbe una scelta migliore. MySQL si adatta solo se le tue esigenze continuano ad essere relativamente limitate.


FME supporta MySQL e PostGIS.
Raven,

8

MySQL ha anche un'estensione spaziale ma, per quanto ne so (non l'ho mai usato), non è così ricco e stabile come PostGIS .

Se stai pensando di utilizzare un database spaziale, PostGIS è una buona scelta e ne varrà la pena.

Mentre MySQL fornisce già alcune funzionalità per archiviare e operare su dati geospaziali, la funzionalità lascia molto a desiderare ed è ben lungi dal fornire la piena compatibilità OpenGIS.

In particolare, tutte le funzioni che interrogano i dati spaziali operano solo su MBR (rettangoli minimi di delimitazione), per semplificare le operazioni.

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


6

La battaglia tra MySQL e Postgis risorge:

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

Nota che i commentatori più sono di qui (scambio di stack gis.)

collegamenti anche

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

Hanno avuto implementazioni più riuscite con Postgis di mysql. (dipende dalle impostazioni dei clienti e da ciò che stanno cercando di ottenere)

Il mio unico suggerimento a Paul Ramsey (e al team di PostGIS) è una bella interfaccia grafica per i postini tramite PgAdmin (v4 ..?) Con un visualizzatore (come FME del software sicuro) - non solo gli attributi sarebbero un grande vantaggio. Attualmente utilizza QGIS per visualizzare i dati postgis.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.