Würde PostGIS einen Vorteil gegenüber MySQL für eine Produktfarm-Anwendung bieten?


23

Ich habe eine Web-App, die die Standorte von Farmen in West Michigan speichert. Sie können nach einem Produkt suchen (z. B. "Brokkoli") und es werden Ihnen alle Farmen angezeigt, auf denen dieses Produkt angebaut wird.

Im Moment benutze ich MySQL und benutze Trigonometrie, um die Differenz zwischen dem Standort des Benutzers und dem Standort jeder Farm zu berechnen. Es ist kein schlechter Weg, aber es hat einiges gekostet.

Eine andere Sache, die ich bald tun möchte, ist, die Vegetationsperioden für verschiedene Produkte für verschiedene Regionen abzubilden. (Zum Beispiel möchte ich zeigen, dass Avocados in Kalifornien zu einer bestimmten Jahreszeit wachsen, aber niemals in Ohio.)

Mir ist klar, dass dies eine offene und möglicherweise naive Frage ist, aber könnte es sich für mich lohnen, auf PostgreSQL / PostGIS umzusteigen, um die räumlichen Möglichkeiten zu nutzen?


1
Planen Sie dynamische oder statische Saisonkarten?
underdark

Wenn ich verstehe, was Sie fragen, dynamisch. Beispiel: Die Vegetationsperiode für Äpfel in der Nähe von Grand Rapids, MI, dauert von August bis Oktober.
Jason Swett

Antworten:


21

Ich bin ein großartiger PostGIS-Fan und habe keine Erfahrung mit MySQL.

Aber von dem, was Sie schreiben, denke ich an zwei Gründe, um zu wechseln.

Erstens wird es mit Sicherheit viel einfacher sein, neue Funktionen wie die von Ihnen erwähnte Saisonkarte zu implementieren.

zweitens, wenn Sie heute Ihre Trigonometrie-Berechnungen durchführen, dann tun Sie das vermutlich außerhalb der Datenbank. Wenn Sie dies alles in der Datenbank tun, sind Sie viel freier in der Entwicklung der überlagernden Anwendungen.

Sie müssen wahrscheinlich keine Berechnung außerhalb der Datenbank durchführen, wenn Sie postgis ausführen.

Das, was Sie erwähnt haben, ist in MySQL möglicherweise machbar, da es sich sehr einfach anhört, aber Sie erhalten in PostGIS eine größere Flexibilität mit Zugriff auf alle räumlichen Funktionen.

/ Nicklas


18

Schon allein deshalb, weil Sie in Drittanbieteranwendungen viel mehr Auswahl haben, um Karten Ihrer Informationen (Kartenserver, Geoserver usw.) zu generieren. Laden von Daten (ogr2ogr, fme usw.) PostGIS würde eine bessere Wahl treffen. MySQL eignet sich nur, wenn Ihre Anforderungen weiterhin relativ begrenzt sind.


FME unterstützt sowohl MySQL als auch PostGIS.
Raven

8

MySQL hat auch eine räumliche Erweiterung , ist aber meines Wissens (ich habe es noch nie benutzt) nicht so funktionsreich und stabil wie PostGIS .

Wenn Sie erwägen, eine räumliche Datenbank zu verwenden, ist PostGIS eine gute Wahl, und der Aufwand für den Wechsel lohnt sich.

Während MySQL bereits einige Funktionen zum Speichern und Verarbeiten von Geodaten bietet, lässt die Funktionalität zu wünschen übrig und bietet bei weitem keine vollständige OpenGIS-Kompatibilität.

Am bemerkenswertesten ist, dass alle Funktionen, die räumliche Daten abfragen, nur auf MBRs (Minimum Bounding Rectangles) ausgeführt werden, um die Operationen zu vereinfachen.

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


6

Der Kampf zwischen MySQL und Postgis steigt erneut:

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

Beachten Sie, dass die meisten Kommentare von hier stammen (gis stack exchange).

Links auch

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

Habe erfolgreichere Bereitstellungen mit postgis als mit mysql. (abhängig von den Kundeneinstellungen und dem, was sie erreichen möchten)

Mein einziger Vorschlag an Paul Ramsey (und das PostGIS-Team) ist eine nette GUI für PostGis über PgAdmin (v4 ..?) Mit einem Visualisierer (wie FME von sicherer Software) - nicht nur Attribute wären ein großes Plus. Verwenden Sie derzeit QGIS zur Visualisierung von Postgis-Daten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.