PostGIS vs. SQL Server per dati GIS


15

Quindi di recente sto iniziando con una nuova società e ho molti utenti ArcGIS che sembrano davvero desiderosi di andare avanti con un'istanza PostGIS per fornire alcuni dati ai nostri clienti. Anche se non ho problemi con questo, siamo un 95% di SQL Server e il 5% di Oracle shop. Il nostro attuale GIS interno viene eseguito su SQL Server e non ho ancora sentito alcun reclamo.

So che SQL Server ha molte funzionalità spaziali / geometriche migliorate a partire dal 2012, ma ci sono alcune caratteristiche killer in PostGIS per le quali vale la pena entrare nella nuova piattaforma? Ho provato a ricercarlo, ma non riesco a trovare nulla di veramente approfondito o che non sia completamente distorto.

Voglio dare loro gli strumenti migliori per svolgere il loro lavoro, ma devo anche valutare il fatto che imparerò Postgres / GIS sin dall'inizio e questo è un intero viaggio in sé e per sé.


1
Se si forniscono dati ai client da esso usando ArcGIS For Server, l'unica considerazione sarebbe la prestazione. Sebbene abbia una gamma più ampia di funzionalità spaziali, non credo che nessuna di queste sarebbe una caratteristica killer o probabilmente richiesta da ArcGIS. Sfortunatamente non ho parametri di riferimento sulle prestazioni.
MickyT,

Il vecchio mantra d'uso quello che sai certamente si applica qui. Passare a una piattaforma diversa sembra sempre un'ottima idea prima di iniziare il cambiamento. Non molto più tardi, quando hai 6 mesi e ti rendi conto che hai appena iniziato a ottenere le conoscenze necessarie. Hai mai sentito parlare del costo opportunità?
Max Vernon,

2
Nessuna esperienza con i prodotti ARC, ma quando si parla solo di database. PostGIS è un'implementazione molto più matura del database spaziale rispetto al server MSSQL, più esempi, più contenuti gratuiti. Se hai bisogno di fare qualcosa di spaziale in db, PostGIS ha più opzioni. PostGIS è gratuito, MS SQL no, i database spaziali sembrano avere la tendenza a crescere più del previsto. Quindi ci sono mal di testa dovuti alle licenze, ecc ... Naturalmente Linux + PostGIS ha i suoi problemi se gli amministratori sono più abituati all'ambiente di Windows.
simplexio,

Risposte:


21

Ho lavorato con Postgres e SQL Server. Ho trovato Postgres superiore nella funzionalità GIS. E mentre descriverò brevemente le mie conclusioni di seguito, suggerirei questo: concediti un periodo di tempo breve ma ragionevole per rivedere la soluzione sconosciuta rispetto a quella che conosci, con obiettivi specifici in mente. Ad esempio, forse un periodo di 2 settimane per installare e apprendere alcune funzionalità specifiche attualmente in uso. Se scopri di essere bloccato o privo di funzionalità entro quel periodo di tempo, allora sai che non fa per te. È un investimento nella ricerca che amplia il tuo punto di vista e ti aiuta a capire che potresti esserti perso qualcosa di cui non eri a conoscenza prima, o semplicemente confermare che il tuo corso attuale è proprio ora.

Per quanto riguarda il database, ho scoperto che Postgres ha una curva di apprendimento più breve e più superficiale. La documentazione è semplicemente incredibile. SQL Server ha abbastanza documentazione, ma trovo molto difficile da leggere, con esempi e tutorial non sufficienti.

PostGIS vs SQL Server Spatial è simile alla precedente per quanto riguarda la documentazione, ma PostGIS batte le mutande di SQL Server Spatial in termini di funzionalità. Ad esempio, Google Maps, e in misura minore Bing Maps, ha recentemente aggiunto il supporto completo geoJSON all'API delle mappe. Bene, PostGIS può facilmente restituire un risultato geoJSON direttamente da una query del database usando ST_AsGeoJSON () . Questo risultato geoJSON può quindi essere passato direttamente a qualunque cosa possa comprendere geoJSON. SQL Server richiede l'utilizzo di librerie ed elaborazioni aggiuntive o di utilizzare ogr2ogr. Inoltre PostGIS ha a disposizione oltre 300 funzioni per la conversione dei dati all'interno e all'esterno del database, rispetto a SQL Server che ha circa 70-100.


Non appena hai bisogno di poligoni, usa PostGIS: ti risparmierai un sacco di problemi. Se hai solo bisogno di punti, forse SQL Server è sufficiente, ma puoi anche usare anche due colonne decimali (2 colonne non sono consigliate se devi fare calcoli di distanza - usa GeoPoint). GeoPoint non è raccomandato se si utilizza EntityFramwork / LINQ2SQL / AverageCrappyORM.
Quandary,

0

Mi sembra che quale db sia meglio non sia la tua preoccupazione principale qui e invece hai due diverse considerazioni che si contrappongono, ovvero la conoscenza del business rispetto ai desideri dei clienti. Alla fine sarà una decisione commerciale, non una decisione tecnica.

Ovviamente c'è un costo opportunità come ha notato Max in un commento. Non c'è modo di aggirare questo. Se stai seguendo il percorso di Postgres, ti preghiamo di prendere in considerazione un aiuto, sotto forma di un buon accordo di consulenza, un dba esperto o entrambi.

Se i tuoi utenti desiderano PostGIS, questa potrebbe essere una vincita netta. Quanto più dei tuoi servizi venderai effettuando il passaggio? Ne varrà la pena opportunità dal punto di vista dei costi? Queste non sono decisioni che verranno prese in base a quale db è migliore ai tuoi occhi o in termini di specifiche tecniche, ma in termini di curva di apprendimento e marketing.


Ottima intuizione sulla scelta a portata di mano - grazie Chris.
LowlyDBA

Quale db è meglio è di primaria importanza qui. SQL-server non è in grado di gestire quella dimensione di dati (planet.osm). Inoltre, mancano molte funzioni, di cui hai effettivamente bisogno, se hai intenzione di fare qualcosa di più della ricerca accademica (tessere vettoriali, geojson, ecc.). Inoltre, non può gestire poligoni che vanno da un lato dell'equatore all'altro (stupido), il che è una preoccupazione se hai bisogno di Brasile, Equador, Colombia, Repubblica Democratica del Congo, Gabon, Kenya, Somalia, Malesia, Indonesia, Singapore, Papua o nell'Oceano Indiano, nel Pacifico o nell'Oceano Atlantico ecc. Inoltre, errori se il poligono ha la direzione sbagliata - invece di auto-convertire ...
Quandary
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.