PostGIS vs SQL Server pour les données SIG

15

J'ai donc récemment commencé dans une nouvelle entreprise et j'ai beaucoup d'utilisateurs d'ArcGIS qui semblent vraiment désireux d'aller de l'avant avec une instance PostGIS pour servir des données à nos clients. Bien que cela ne me pose aucun problème, nous sommes une boutique SQL Server à 95% et une boutique Oracle à 5%. Notre SIG interne actuel fonctionne avec SQL Server et je n'ai pas encore entendu de plaintes.

Je sais que SQL Server a beaucoup de capacités spatiales / géométriques améliorées en 2012, mais y a-t-il des fonctionnalités tueuses dans PostGIS qui méritent d'être introduites dans la nouvelle plate-forme? J'ai essayé de le rechercher mais je ne trouve rien de vraiment approfondi ou ce n'est pas complètement biaisé.

Je veux leur donner les meilleurs outils pour faire leur travail, mais je dois également peser le fait que j'apprendrai Postgres / SIG dès le début et c'est un voyage en soi.

— LowlyDBA
source

1

Si vous fournissez des données à des clients à partir de celui-ci à l'aide d'ArcGIS For Server, la seule considération serait la performance. Bien qu'il ait une plus grande gamme de fonctionnalités spatiales, je ne pense pas que tout cela soit une fonctionnalité de tueur ou susceptible d'être requis par ArcGIS. Malheureusement, je n'ai pas de référence sur les performances.

— MickyT

Le mantra séculaire d'utilisation de ce que vous savez s'applique certainement ici. Passer à une plate-forme différente semble toujours être une excellente idée avant de se lancer dans le changement. Pas tellement plus tard, lorsque vous en êtes à 6 mois et que vous réalisez que vous venez juste de commencer à acquérir les connaissances nécessaires. Avez-vous déjà entendu parler du coût d'opportunité?

— Max Vernon

2

Aucune expérience avec les produits ARC, mais en parlant uniquement de bases de données. PostGIS est une implémentation beaucoup plus mature de la base de données spatiale que le serveur MSSQL, plus d'exemples, plus de contenu gratuit. Si vous avez besoin de faire quelque chose de spatial dans db, PostGIS a plus d'options. PostGIS est gratuit, MS SQL ne l'est pas, les bases de données spatiales semblent avoir tendance à grossir plus que prévu. Il y a donc des maux de tête liés aux licences, etc. Bien sûr, Linux + PostGIS a ses propres problèmes si les administrateurs sont plus habitués à l'environnement Windows.

— simplexio

21

J'ai travaillé avec Postgres et SQL Server. J'ai trouvé que Postgres était supérieur dans la fonctionnalité SIG. Et pendant que je vais détailler brièvement mes conclusions ci-dessous, je suggère ceci: Donnez-vous un délai bref mais raisonnable pour examiner la solution inconnue par rapport à celle que vous connaissez, avec des objectifs spécifiques à l'esprit. Par exemple, peut-être une période de 2 semaines pour installer et apprendre certaines fonctionnalités spécifiques actuellement utilisées. Si vous constatez que vous êtes bloqué ou manque de fonctionnalités pendant cette période, vous savez que ce n'est pas pour vous. C'est un investissement dans la recherche qui élargit votre vue et vous aide à réaliser que vous avez peut-être raté quelque chose que vous ignoriez auparavant, ou simplement à confirmer que votre cours actuel est le bon moment.

En ce qui concerne la base de données, j'ai trouvé que Postgres avait une courbe d'apprentissage plus courte et plus superficielle. La documentation est tout simplement incroyable. SQL Server possède pas mal de documentation, mais je la trouve difficile à lire, avec pas assez d'exemples et de tutoriels.

PostGIS vs SQL Server Spatial est similaire à ce qui précède en ce qui concerne la documentation, mais PostGIS bat le pantalon de SQL Server Spatial en termes de fonctionnalité. Par exemple, Google Maps, et dans une moindre mesure Bing Maps, a récemment ajouté une prise en charge complète de geoJSON à son API de cartes. Eh bien, PostGIS peut facilement retourner un résultat geoJSON directement à partir d'une requête de base de données en utilisant ST_AsGeoJSON () . Ce résultat geoJSON peut ensuite être transmis directement à tout ce qui peut comprendre geoJSON. SQL Server vous oblige à utiliser une bibliothèque et un traitement supplémentaires , ou à utiliser ogr2ogr. En outre, PostGIS dispose de plus de 300 fonctions disponibles pour la conversion de données dans et hors de la base de données, par rapport à SQL Server qui en a environ 70-100.

— TechJohn
source

Dès que vous avez besoin de polygones, utilisez PostGIS - vous vous épargnerez bien des ennuis. Si vous n'avez besoin que de points, SQL-Server est peut-être suffisant, mais vous pouvez également utiliser deux colonnes décimales également (2 colonnes déconseillées si vous devez faire des calculs de distance - utilisez GeoPoint). GeoPoint n'est pas recommandé si vous utilisez EntityFramwork / LINQ2SQL / AverageCrappyORM.

— Quandary

0

Il me semble que la meilleure base de données n'est pas votre principale préoccupation ici et au lieu de cela, vous avez deux considérations différentes qui s'opposent, à savoir la connaissance commerciale vs les désirs des clients. En fin de compte, ce sera une décision commerciale, pas une décision technique.

Évidemment, il y a un coût d'opportunité comme Max l'a noté dans un commentaire. Il n'y a pas de chemin aux alentours. Si vous empruntez la route Postgres, veuillez envisager d'obtenir de l'aide, sous la forme d'un bon accord de conseil, d'un dba chevronné, ou les deux.

Si vos utilisateurs veulent PostGIS, cela peut être un gain net cependant. Combien plus de vos services allez-vous vendre en effectuant le changement? Est-ce que cela en vaudra la peine au niveau des coûts? Ce ne sont pas des décisions qui vont être prises en fonction de la base de données qui est la meilleure à vos yeux ou en termes de spécifications techniques, mais en termes de courbe d'apprentissage et de marketing.

— Chris Travers
source

Grand aperçu du choix à portée de main - merci Chris.

— LowlyDBA

La meilleure base de données est la principale préoccupation ici. SQL-server n'est pas en mesure de gérer cette taille de données (planet.osm). En outre, il manque de nombreuses fonctionnalités dont vous avez réellement besoin si vous voulez faire plus que de la recherche universitaire (tuiles vectorielles, geojson, etc.). En outre, il ne peut pas gérer les polygones qui vont d'un côté à l'autre de l'équateur (stupide), ce qui est une préoccupation si vous avez besoin du Brésil, de l'Équateur, de la Colombie, de la RDC, du Gabon, du Kenya, de la Somalie, de la Malaisie, de l'Indonésie, de Singapour, de Singapour, Papouasie ou océan Indien, Pacifique ou Atlantique etc. Aussi, des erreurs si le polygone a la mauvaise direction - au lieu de l'auto-conversion ...

— Quandary