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?


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


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.


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


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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.