J'ai utilisé OGR2OGR pour importer des données de points SRID 4326 dans MSSQL Server. Je ne savais pas que la valeur par défaut était de créer une colonne de géométrie au lieu de détecter les données comme 4326 et de créer une colonne de géographie. Je connais le code pour contourner ce problème, donc pas de problème.
Les données telles quelles dans une colonne de géométrie s'affichent très bien dans QGIS. Alors, dois-je réellement mettre les données dans une colonne géographique?
Merci!
Réponses:
Si vous n'avez pas besoin de mesurer les distances sur le sphéroïde, la géométrie convient bien. Le manuel PostGIS contient des informations compréhensibles sur ce http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography et il est également valable pour MSSQL.
Je l'ai fait par accident il y a quelques mois, même si c'était avec des lignes et c'était une très grande classe de fonctionnalités (je pense que c'était de l'ordre de 10 millions de fonctionnalités). Je ne me souviens pas non plus si c'était SQL Server 2008 ou 2012.
Une chose que j'ai remarquée dans ArcMap était que tout était vraiment, vraiment lent. Je l'ai profilé. A trouvé la requête à l'origine de la lenteur et l'a insérée dans SSMS et a déterminé que c'était la méthode Filter qui était le coupable (iirc, ArcMap utilise Filter avec une enveloppe pour récupérer les OID). SQL Server ramène chaque ligne du tableau !!
Lorsque je suis passé à la géographie, Filter renvoyait le nombre correct d'entités pour la géométrie donnée.
Je ne me souviens pas que d'autres méthodes se comportent mal, mais je n'ai pas laissé les données 4326 dans la géométrie SQL assez longtemps pour le savoir.
Si la taille de votre table n'est pas très grande, cela peut ne pas avoir d'importance. Mais c'est quelque chose à garder à l'esprit pour les grandes tables. Cela n'aurait pas non plus d'importance si QGIS ne l'utilise pas Filter.