Czy PostGIS oferowałby przewagę nad MySQL w przypadku aplikacji w gospodarstwach rolnych?

23

Mam aplikację internetową, która przechowuje lokalizacje gospodarstw w West Michigan. Możesz wyszukać produkt (np. „Brokuły”), a zobaczysz wszystkie farmy, które go uprawiają.

Obecnie używam MySQL i używam trygonometrii, aby obliczyć różnicę między lokalizacją użytkownika a lokalizacją każdej farmy. Nie jest to zła droga, ale zajęło to trochę czasu.

Kolejną rzeczą, którą chcę wkrótce zrobić, jest wyznaczenie sezonów wegetacyjnych dla różnych produktów dla różnych regionów. (Na przykład chcę pokazać, że awokado rośnie o określonej porze roku w Kalifornii, ale nigdy w Ohio).

Zdaję sobie sprawę, że jest to pytanie otwarte i być może naiwne, ale czy warto opuścić PostgreSQL / PostGIS, aby skorzystać z jego możliwości przestrzennych?

Jason Swett
źródło
1
Czy planujesz dynamiczne mapy „sezonowe” czy statyczne?
podmrok
Jeśli rozumiem, o co pytasz, dynamiczny. Przykład: sezon wegetacyjny dla jabłek w pobliżu Grand Rapids, MI, trwa od sierpnia do października.
Jason Swett,

Odpowiedzi:

21

Jestem wielkim fanem PostGIS i nie mam doświadczenia z MySQL, więc mogę być stronniczy.

Ale z tego, co piszesz, myślę o dwóch powodach zmiany.

po pierwsze, z pewnością łatwiej będzie wprowadzić nowe funkcje, takie jak wspomniana mapa sezonu.

po drugie, kiedy dzisiaj wykonujesz obliczenia trygonometryczne, myślę, że robisz to poza db. jeśli zrobisz to wszystko w db, zamiast tego będziesz o wiele bardziej wolny w rozwoju nakładających się aplikacji.

prawdopodobnie nie będziesz musiał wykonywać żadnych obliczeń poza db, jeśli uruchomisz postgis.

rzecz sezonu, o której wspomniałeś, może być wykonalna w MySQL, ponieważ brzmi to bardzo prosto, ale zyskasz większą elastyczność w PostGIS z dostępem do wszystkich funkcji przestrzennych.

/ Nicklas

Nicklas Avén
źródło
18

Choćby dlatego, że będziesz mieć dużo większy wybór w aplikacjach innych firm do generowania map twoich informacji (mapserver, geoserver, itp., Itp.) Ładowanie danych (ogr2ogr, fme, itp.) PostGIS byłby lepszym wyborem. MySQL będzie odpowiedni tylko wtedy, gdy twoje potrzeby będą nadal stosunkowo ograniczone.

Paul Ramsey
źródło
FME obsługuje MySQL oraz PostGIS.
Raven
8

MySQL ma także rozszerzenie przestrzenne, ale o ile wiem (nigdy go nie używałem), nie jest tak bogaty w funkcje i stabilny jak PostGIS .

Jeśli zastanawiasz się nad wykorzystaniem przestrzennej bazy danych, PostGIS jest dobrym wyborem, a wysiłek przełączenia się opłaci.

Chociaż MySQL zapewnia już pewne funkcje przechowywania i obsługi danych geoprzestrzennych, funkcjonalność ta pozostawia wiele do życzenia i jest daleka od zapewnienia pełnej zgodności z OpenGIS.

Co najważniejsze, wszystkie funkcje odpytujące dane przestrzenne działają tylko na MBR (minimalne prostokąty ograniczające), aby uprościć operacje.

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

dariapra
źródło
6

Bitwa MySQL vs Postgis ponownie się podnosi:

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

Zauważ, że większość komentujących pochodzi stąd (wymiana stosu gis.)

linki też

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

Miałem więcej udanych wdrożeń z postgis niż mysql. (zależą od konfiguracji klientów i tego, co próbują osiągnąć)

Moją jedyną sugestią dla Paula Ramseya (i zespołu PostGIS) jest ładny GUI dla Postgis za pośrednictwem PgAdmin (v4 ..?) Z wizualizatorem (jak FME bezpiecznego oprogramowania) - nie tylko atrybuty byłyby dużym plusem. Obecnie używaj QGIS do wizualizacji danych postgis.

Mapperz
źródło