PostGIS vs. SQL Server dla danych GIS


15

Ostatnio zaczynam pracę w nowej firmie i mam wielu użytkowników ArcGIS, którzy wydają się bardzo chętni do korzystania z instancji PostGIS w celu udostępniania niektórych danych naszym klientom. Chociaż nie mam z tym problemu, jesteśmy 95% serwerem SQL Server i 5% sklepem Oracle. Nasz obecny wewnętrzny system GIS działa na serwerze SQL Server i jeszcze nie słyszałem żadnych skarg.

Wiem, że SQL Server ma wiele ulepszonych funkcji przestrzennych / geometrycznych od 2012 roku, ale czy są jakieś zabójcze funkcje w PostGIS, które są warte włamania się na nową platformę? Próbowałem to zbadać, ale nie mogę znaleźć niczego naprawdę dogłębnego lub nie jest to całkowicie stronnicze.

Chcę dać im najlepsze narzędzia do wykonania ich pracy, ale muszę też rozważyć fakt, że od samego początku będę się uczyć Postgres / GIS i to jest cała podróż sama w sobie.


1
Jeśli serwujemy dane klientom za pomocą ArcGIS For Server, jedyną kwestią będzie wydajność. Chociaż ma większy zakres funkcji przestrzennej, nie sądzę, aby jakakolwiek z tych funkcji była zabójcza lub prawdopodobnie będzie wymagana przez ArcGIS. Niestety nie mam żadnych testów wydajności.
MickyT,

Odwieczna mantra użycia, o której wiesz, z pewnością ma tutaj zastosowanie. Przejście na inną platformę zawsze wydaje się świetnym pomysłem przed rozpoczęciem zmiany. Nie tak dużo później, kiedy masz 6 miesięcy i zdajesz sobie sprawę, że dopiero zacząłeś zdobywać niezbędną wiedzę. Słyszałeś kiedyś o kosztach alternatywnych?
Max Vernon

2
Brak doświadczenia z produktami ARC, ale podczas rozmowy tylko z bazami danych. PostGIS jest znacznie bardziej dojrzałą implementacją przestrzennej bazy danych niż serwer MSSQL, więcej przykładów, więcej darmowej zawartości. Jeśli potrzebujesz zrobić coś związanego z przestrzenią w db, PostGIS ma więcej opcji. PostGIS jest bezpłatny, MS SQL nie, bazy danych przestrzennych wydają się mieć tendencję do powiększania się, niż się spodziewano. Występują problemy z licencjonowaniem itp. Oczywiście Linux + PostGIS ma własne problemy, jeśli administratorzy są bardziej przyzwyczajeni do środowiska Windows.
simplexio

Odpowiedzi:


21

Pracowałem zarówno z Postgres, jak i SQL Server. Uważam, że Postgres ma lepszą funkcjonalność GIS. I chociaż krótko opiszę poniżej moje ustalenia, sugeruję to: Daj sobie krótki, ale rozsądny okres na zapoznanie się z nieznanym rozwiązaniem w stosunku do tego, co znasz, mając na uwadze konkretne cele. Na przykład może być 2-tygodniowy okres na zainstalowanie i nauczenie się niektórych konkretnych funkcji, które są obecnie w użyciu. Jeśli okaże się, że utknąłeś lub brakuje Ci funkcji w tym czasie, wiesz, że to nie jest dla Ciebie. Jest to inwestycja w badania, które poszerzają twoje spojrzenie i pomagają uświadomić sobie, że mogłeś przegapić coś, czego wcześniej nie wiedziałeś, lub po prostu potwierdzić, że twój obecny kurs jest właśnie teraz.

Jeśli chodzi o bazę danych, zauważyłem, że Postgres ma krótszą i bardziej płytką krzywą uczenia się. Dokumentacja jest po prostu niesamowita. SQL Server ma sporo dokumentacji, ale trudno mi ją czytać, z niewystarczającą liczbą przykładów i samouczków.

PostGIS vs SQL Server Spatial jest podobny do powyższego w odniesieniu do dokumentacji, ale PostGIS wyprzedza SQL Server Spatial pod względem funkcjonalności. Na przykład Google Maps, aw mniejszym stopniu Bing Maps, niedawno dodały pełną obsługę geoJSON do API map. Cóż, PostGIS może łatwo zwrócić wynik geoJSON bezpośrednio z zapytania do bazy danych za pomocą ST_AsGeoJSON () . Ten wynik geoJSON można następnie przekazać bezpośrednio do wszystkiego, co może zrozumieć geoJSON. SQL Server wymaga użycia dodatkowej biblioteki i przetwarzania lub użycia ogr2ogr. Ponadto PostGIS ma ponad 300 funkcji dostępnych do konwersji danych do iz bazy danych, w porównaniu do SQL Server, który ma około 70-100.


Gdy tylko będziesz potrzebować wielokątów, skorzystaj z PostGIS - zaoszczędzisz sobie wielu kłopotów. Jeśli potrzebujesz tylko punktów, być może wystarczy SQL-Server, ale możesz także użyć dwóch kolumn dziesiętnych (2 kolumny nie są zalecane, jeśli chcesz wykonać obliczenia odległości - użyj GeoPoint). GeoPoint nie jest zalecany, jeśli używasz EntityFramwork / LINQ2SQL / AverageCrappyORM.
Quandary

0

Wydaje mi się, że to, która db jest lepsza, nie jest tu twoim głównym zmartwieniem, a zamiast tego masz dwa różne względy, które przeciwstawiają się sobie nawzajem, a mianowicie znajomość biznesu a pragnienia klientów. Ostatecznie będzie to decyzja biznesowa, a nie decyzja techniczna.

Oczywiście, jak zauważył Max w komentarzu, istnieje koszt alternatywny. Nie można tego obejść. Jeśli wybierasz się na trasę Postgres, rozważ skorzystanie z pomocy, w postaci dobrej umowy konsultacyjnej, doświadczonego dba lub obu.

Jeśli Twoi użytkownicy chcą PostGIS, może to być wygrana netto. Ile jeszcze swoich usług sprzedasz, dokonując zmiany? Czy będzie to opłacalne pod względem kosztów? Nie są to decyzje, które będą podejmowane na podstawie tego, która db jest lepsza w twoich oczach lub pod względem specyfikacji technicznych, ale pod względem krzywej uczenia się i marketingu.


Świetny wgląd w wybór pod ręką - dzięki Chris.
LowlyDBA,

To, która db jest lepsza, ma tutaj podstawowe znaczenie. Serwer SQL nie jest w stanie obsłużyć tego rozmiaru danych (planet.osm). Ponadto brakuje wielu funkcji, które są naprawdę potrzebne, jeśli chcesz zrobić coś więcej niż badania naukowe (płytki wektorowe, geojson itp.). Ponadto nie radzi sobie z wielokątami, które przechodzą z jednej strony równika na drugą (głupie), co jest problemem, jeśli potrzebujesz Brazylii, Ekwadoru, Kolumbii, Drc, Gabonu, Kenii, Somalii, Malezji, Indonezji, Singapuru, Papua lub Ocean Indyjski, Pacyfik lub Ocean Atlantycki itp. Również błędy, jeśli wielokąt ma niewłaściwy kierunek - zamiast automatycznej konwersji ...
Quandary
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.