Suite

En quoi les projections ESRI WKT sont-elles différentes des projections OGC WKT ?


Quelqu'un connaît-il la liste précise des différences entre les chaînes de format de projection ESRI WKT et OGC WKT ?

Je sais qu'il existe divers outils pour aider à convertir ESRI WKT en OGC WKT, y compris les utilitaires GDAL et divers services de sites Web. Mais ma question n'est pas d'ordre pratique, je veux simplement comprendre les différences de formatage/syntaxe que ces services utilisent. Les questions précédentes de Stackexchange n'ont parlé que de la différence dans des exemples spécifiques ou des outils et services disponibles.

Même si vous ne connaissez qu'une seule différence, ce serait formidable si vous pouviez simplement la publier. D'après ma propre expérience, il ne devrait y avoir qu'une petite poignée de différences. Les différences que je connais sont :

  • la plupart des éléments de texte dans la définition esri utilisent un trait de soulignement où ogc utilise un espace.
  • le texte définissant la donnée dans esri wkt est le même que ogc wkt sauf qu'il commence par "D_".
  • parfois, les identificateurs de texte pour certains PROJCS, PROJECTION, GEOGCS et DATUM prédéfinis sont écrits différemment (par exemple "NAD83" dans l'un étant "North_American_1983"). Je suppose que la seule façon de savoir quels identifiants sont orthographiés différemment serait d'avoir une liste ou une table de recherche, alors veuillez nommer ceux que vous savez être différents.
  • les différentes valeurs de texte PARAMETER sont toutes les mêmes, sauf que ogc a chaque mot en majuscule alors que esri a tout en minuscule. Cependant, j'ai vu des cas où cette règle n'a pas été utilisée, est-ce que quelqu'un sait si la casse du titre est vraiment importante lorsqu'il s'agit de logiciels essayant de les charger?
  • le type d'UNITE s'écrit en majuscule en ogc et en minuscule en esri, par exemple "Degree" vs "degré". Dans certains cas, j'ai vu ogc être orthographié à la fois comme "meter" et "m" pour "Meter" et dans d'autres cas avec l'orthographe française "metre". Quelqu'un sait quelle est la convention correcte pour ceux-ci ou tout autre type d'unité pour les deux formats ?

Je n'ai pas une telle liste, mais parcourir le code GDAL vous guidera :

https://svn.osgeo.org/gdal/trunk/autotest/osr/osr_esri.py

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri.cpp

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri_names.h

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrspatialreference.cpp


Vous avez saisi beaucoup de différences. Esri n'a jamais adopté les WKID pour les algorithmes de projection cartographique ou les noms de paramètres, ils sont donc tous différents. Nous n'étions pas d'accord avec la précision avec laquelle les définitions des paramètres sont définies. Les nôtres sont plus généralisés.

Nous ne prenons pas en charge TOWGS84 ni certains des mots clés les plus récents.

Lorsque nous comparons des chaînes (noms), nous ignorons les traits de soulignement, les GCS_ et D_, et la casse. Cela peut ne pas être vrai dans d'autres parseurs. Notre analyseur est strict sur les noms, mais nous avons ajouté quelques synonymes et maintenons maintenant des listes de noms de divers fournisseurs à des fins de comparaison.

La spécification du système de coordonnées d'origine de l'OGC n'était pas spécifique en ce qui concerne les noms d'objets. Il existe une nouvelle spécification OGC/ISO, "Informations géographiques - Texte bien connu pour la norme des systèmes de référence de coordonnées", qui fait son chemin dans le processus de normalisation. C'est beaucoup plus précis sur ce que les noms devraient être (correspond au registre EPSG !). Ce sera très excitant de mettre en œuvre cette norme à l'avenir.

Divulgation : Je travaille chez Esri, je suis membre du sous-comité qui tient le registre EPSG et j'ai été membre du comité de rédaction CRS WKT 2.0.


Le 4 janvier 2018, Esri a créé un référentiel GitHub avec des équivalents EPSG-Esri dans différents formats : json, txt, csv…

Documentation de la base de données du moteur de projection Esri


Comme point de départ potentiel pour une liste de différences, il pourrait être utile de voir mon nouveau package PyCRS, où j'ai tenté de créer une classe pour chaque élément crs, paramètre et nom datum/ellips/proj, ainsi que leur orthographe esri_wkt vs ogc_wkt . J'ai également spécifié comment je vois les différences d'analyse en termes de structure wkt dans son ensemble dans le_from_wkt()fonction dans leanalyseur.pysous-module. J'espère qu'avec les contributions des utilisateurs, ces différences pourront être encore augmentées et/ou corrigées.

https://github.com/karimbahgat/PyCRS


Problèmes liés au système de coordonnées OGC WKT

Le seul cas où il n'est pas suivi par un fournisseur que je connaisse la définition ESRI de Lambert Conformal Conic. Dans EPSG, il existe une forme 1SP et une forme 2SP. ESRI les fusionne et a juste des paramètres différents selon le type.

Un autre problème est que la spécification CT répertorie explicitement les paramètres pour les projections Transverse Mercator, LCC 1SP et LCC 2SP. la même spécification CT. Ma position est que le tableau de la section 10.x de la spécification CT est erroné et que la forme largement utilisée est correcte. Notez que le tableau de la spécification CT est en conflit avec d'autres exemples de la même spécification.

Un troisième problème est la formulation pour Albers. Alors que j'ai utilisé longitude_of_center et latitude_of_center, ESRI utilise Central_meridian et latitude_of_origin.


La représentation OGC Well-Known Text des systèmes de référence spatiale

Les définitions de la représentation textuelle bien connue sont modélisées d'après le modèle de données du système de coordonnées POSC/EPSG.

Un système de référence spatiale, également appelé système de coordonnées, est un système de coordonnées géographiques (latitude-longitude), projeté (x,y) ou géocentrique (x,y,z).

Le système de coordonnées est composé de plusieurs objets. Chaque objet a un mot-clé en majuscules (par exemple, DATUM ou UNIT) suivi des paramètres définis et délimités par des virgules de l'objet entre parenthèses.

Certains objets sont imbriqués, les objets eux-mêmes sont composés d'objets. Les implémentations sont libres de substituer des crochets standard ( ) aux crochets [ ] et doivent être prêtes à lire les deux formes de crochets.

La définition de la forme étendue de Backus-Naur (EBNF) pour la représentation sous forme de chaîne d'un système de coordonnées est la suivante, en utilisant des crochets (voir la note ci-dessus) :

Le système de coordonnées d'un jeu de données est identifié par le mot-clé PROJCS si les données sont en coordonnées projetées, par GEOGCS si en coordonnées géographiques, ou par GEOCCS si en coordonnées géocentriques. Le mot-clé PROJCS est suivi de toutes les pièces qui définissent le système de coordonnées projeté. La première pièce de tout objet est toujours le nom. Plusieurs objets suivent le nom du système de coordonnées projetées : le système de coordonnées géographiques, la projection cartographique, un ou plusieurs paramètres et l'unité de mesure linéaire. Tous les systèmes de coordonnées projetés sont basés sur un système de coordonnées géographiques, de sorte que les éléments spécifiques à un système de coordonnées projetées sont décrits en premier. Par exemple, la zone UTM 10N sur le datum NAD83 est définie comme

Le nom et plusieurs objets définissent tour à tour l'objet du système de coordonnées géographiques : le datum, le premier méridien et l'unité de mesure angulaire.

La chaîne du système de coordonnées géographiques pour la zone UTM 10N sur NAD83 est

L'objet UNIT peut représenter des unités de mesure angulaires ou linéaires.

Le facteur de conversion spécifie le nombre de mètres (pour une unité linéaire) ou le nombre de radians (pour une unité angulaire) par unité et doit être supérieur à zéro.

Par conséquent, la représentation sous forme de chaîne complète de la zone UTM 10N est

Un système de coordonnées géocentriques est assez similaire à un système de coordonnées géographiques. Il est représenté par


En quoi les projections ESRI WKT sont-elles différentes des projections OGC WKT ? - Systèmes d'information géographique

Je pense que Microsoft doit montrer plus de preuves à l'appui de cette interprétation de la spécification. Cette interprétation aura un coût très élevé pour les clients en termes d'interopérabilité et de barrière à l'adoption des technologies Microsoft.

Le reste de l'industrie a interprété la norme comme lon/lat si Microsoft veut interpréter cela différemment, ils devraient fournir une explication à toute épreuve justifiant pourquoi ils sont l'une des seules implémentations utilisant l'ordre lat/lon dans SQL.

Je crois comprendre que la majorité des membres de l'OGC ont interprété cette norme comme lon/lat. donc même si Microsoft a raison dans son interprétation, le comité a voté sur la signification de la norme avec leurs claviers. Je pense qu'il serait déraisonnable pour Microsoft de mener cette bataille de conformité en utilisant sa clientèle - cela devrait se produire dans les arrière-salles enfumées des réunions de l'OGC.

Pouvez-vous montrer où ce document, cette page, ce paragraphe et cette phrase, où il est indiqué que la norme s'applique uniquement aux systèmes planaires ou exclut autrement les systèmes géographiques ? J'ai lu le document plusieurs fois et mes collègues l'ont également examiné. rien n'a amené aucun d'entre nous à croire que les crs géographiques soient exclus.

6.1 décrit l'architecture du modèle Géométrie, qui indique clairement que chaque objet géométrique est associé à un "Système de Référence Spatial". cela ne se limite pas aux systèmes de coordonnées du projet.

La section 9 décrit la représentation WKT des systèmes de référence spatiale. Cela couvre à la fois les systèmes géographiques et les systèmes projetés. Nulle part il ne limite la spécification aux seuls systèmes planaires.

L'annexe B.8 de la partie 1 de la SFA indique que la "latitude_d'origine" est "la latitude choisie comme origine des coordonnées y". false-easting/northing ont une définition similaire. Cette section contredit toute notion d'utilisation de l'ordre CRS pour X et Y, car elle définit explicitement X/Y dans un système de coordonnées projetées.

Comment Microsoft résout-il le conflit où un CRS peut projeter la latitude en X au lieu de la longitude ? Vous référez-vous à la définition fournie dans la norme, ou vous référez-vous aux meilleures pratiques ?

Comme cela a été souligné, WKT tel que défini par la spécification SFA n'utilise pas la notation appropriée pour les systèmes non planaires. Donc, si nous devions supposer que Microsoft a raison et que le SFA ne s'applique qu'au planaire, alors il ne serait pas standard de représenter un système de coordonnées géographiques en utilisant WKT selon SFA. Dans ce cas, Microsoft devrait s'en remettre aux normes de facto.

Si Microsoft choisit de faire cavalier seul dans cette implémentation, alors je suggérerais de le faire absolument clairque SQL Server implémente la norme OGC 05-126 en utilisant les meilleures pratiques de juin 2005/06-135r1 et que cette norme est nettement différente de l'OGC 99-049.

Dans ce cas, il doit y avoir un mode de compatibilité OGC 99-049 qui implémente la convention lon/lat. Lors de l'utilisation de la norme OGC 99-049, le lon/lat est le correct l'interprétation de la norme, comme en témoignent les certifications OGC sur d'autres produits spatiaux.

Ne pas inclure une implémentation conforme à l'OGC 99-049 créerait un grave problème d'interopérabilité qui empêcherait mon organisation d'adopter SQL Server.

Nous comprenons le problème d'interopérabilité et nous cherchons comment combler ce fossé plus facilement. Permettez-moi d'essayer d'expliquer pourquoi nous avons pris cette décision. Comme point de départ :

Ces éléments pris ensemble semblent jeter le doute sur la bonne façon de gérer cela. Les normes entrent cependant en jeu :

Lors de la séance plénière de clôture du CT pour la réunion de juin 2005, les membres présents ont convenu que :

1. À l'avenir, pour les nouvelles spécifications, les valeurs de coordonnées doivent être répertoriées dans l'ordre des axes tel que spécifié par le système de référence de coordonnées (CRS) référencé.

2. À l'avenir, lorsqu'un RWG travaille sur des modifications d'une spécification adoptée existante liée au CRS et à l'ordre des axes, les valeurs des coordonnées doivent être répertoriées dans l'ordre des axes spécifié par le système de référence de coordonnées (CRS) référencé.

  • Enfin, la liste standard EPSG des SIR, que nous adoptons pour le type géographie, uniformément utilise l'ordre latitude/longitude pour tous les systèmes de coordonnées géographiques.

Nous réalisons que cela causera des problèmes aux gens et nous cherchons des moyens de les atténuer, mais j'espère que cela vous aidera à comprendre notre raisonnement.

Permettez-moi d'abord de répéter que je me rends compte que nous faisons quelque chose d'un peu différent du reste des joueurs et que cela cause de la douleur. Nous écoutons les commentaires que nous recevons à ce sujet, et nous cherchons comment nous pouvons faciliter l'import/export de données entre nous et d'autres systèmes.

Cela dit, je ne suis pas d'accord sur les normes. Je pense qu'ils disent très peu sur les coordonnées géographiques, et le peu qu'ils disent semble nous soutenir.

Tout d'abord, jetons un coup d'œil à l'OGC 99-049. Bien que je convienne qu'ils n'indiquent pas explicitement qu'ils excluent les systèmes géographiques, ils disent que "les caractéristiques sont basées sur la géométrie 2D avec interpolation linéaire entre les sommets" [début de la section 1]. Cela m'indique qu'ils travaillent dans l'avion.

De plus, si nous supposons que la spécification couvre les coordonnées géographiques, nous constatons que la spécification est terriblement inadéquate. Par exemple.:

De plus, gardez à l'esprit que même si nous essayons de nous en tenir à 99-049 autant que possible avec notre type de géographie, nous ne visons pas la conformité qui n'est qu'un objectif difficile avec notre type de géométrie. Nous dirions que la conformité à 99-049 pour les systèmes géographiques n'a pas beaucoup de sens, et nous aimerions voir une norme qui traite des systèmes géographiques.

Enfin, concernant 05-126, bien que la citation que vous tirez soit exacte, je ne la considère pas comme pertinente : je ne pense pas que quiconque prétende que dans (la plupart) des projections cartographiques, la latitude est représentée le long de l'axe y de la terrain. Je trouve intéressant que la section 6.4.2 déclare, "A Spatial Reference System, également appelé système de coordonnées, est un (latitude Longitude), un système de coordonnées projeté (X,Y) ou géocentrique (X,Y,Z)." [c'est moi qui souligne]

Avec l'OGC 99-049, l'OGC a certifié d'autres systèmes pour une utilisation avec des systèmes de coordonnées géographiques utilisant l'ordre des axes lon/lat pour les systèmes géographiques. Même si votre interprétation est correcte à la lettre de la norme, elle est incorrecte sur la base de la pratique, de l'application et des tests de la norme. Le comité a démontré son intention d'appliquer cette norme aux systèmes géographiques.

Oui, vous avez tout à fait raison de dire que 99-049 est terriblement inadéquat pour les coordonnées géographiques. Si j'ai fait croire que je croyais le contraire, je m'excuse car cela n'a jamais été mon intention.

Cependant, l'inadéquation ou l'ambiguïté n'est pas une intention. Je pense que les actions de l'OGC concernant 99-049 montrent l'intention de l'OGC lors de la mise en œuvre de cette norme - et rien de ce que vous avez dit ne montre le contraire (vous avez souligné ce que je soupçonnais - les normes de l'OGC sont à moitié cuites et besoin de beaucoup de travail pour être "bien"). À moins que vous ne puissiez montrer que l'OGC a certifié de manière incorrecte d'autres systèmes ou que leur certification a exclu les portions géographiques des implémentations, alors je pense que la position de Microsoft est toujours fausse.

La citation est assez pertinente. Je signale qu'il y a une ambiguïté dans la norme sur les systèmes géométriques--pas seulement dans les systèmes géographiques. Comment allez-vous résoudre ces ambiguïtés et/ou conflits ? Ou, plus important encore, choisirez-vous une implémentation différente du reste de l'industrie ?

Si vous travaillez en fait vers la conformité 99-049 (Spécification des fonctionnalités simples pour SQL), alors la réunion de juin 2005 ne s'appliquerait pas (car c'est une norme qui précède cette réunion - les mises à jour ne comptent pas comme nouvelles). Si vous travaillez vers 05-126/06-104r3 (Implementation Spec for Geo Info - Simple Feature Access), alors la réunion de juin 2005 pourrait s'appliquer car il s'agit d'un Nouveau norme qui a remplacé 99-049.

Je pense toujours que la meilleure solution est de permettre aux clients de choisir s'ils souhaitent utiliser le 99-049 obsolète tel qu'il est mis en œuvre par le reste de l'industrie ou 06-104r3 tel qu'il est mis en œuvre dans Katmai à partir du CTP de novembre.

Veuillez vous assurer de refléter la norme que vous soutenez dans vos documents d'aide, car ils revendiquent 06-104r3.

Je ne peux pas ajouter grand-chose à la discussion sur les normes. Au fil des ans, en tant que responsable SIG, j'ai gardé un œil sur eux pour voir s'ils seraient utiles dans l'organisation pour laquelle je travaillais, mais je ne les ai trouvés utiles que dans le domaine de l'interopérabilité de base (je veux dire de base).

Maintenant, ce que j'attends de Katmai, c'est la fonctionnalité et la flexibilité du point de vue d'une base de données autonome. Le problème que j'ai sur la base de mon expérience limitée avec l'ordre des coordonnées lat/long dans le type de géographie est moins l'ordre (Remarque : Google Maps utilise Lat/Long - qu'utilise Virtual Earth ?) mais qu'il n'y a pas de fonctions disponibles pour cartographier entre la géométrie et la géographie ou une API flexible pour accéder aux objets géométrie/géographie. Par exemple, je ne peux actuellement pas mettre à jour les coordonnées d'une géométrie/géographie sauf via le piratage de chaînes WKT (qui sont limitées en 2D et n'incluent pas les SRIDS). Notez que j'ai dit MISE À JOUR et non LIRE. Oui, nous pouvons LIRE les coordonnées via STPointN mais nous ne pouvons pas facilement faire quelque chose comme mettre à niveau un objet 2D en 3D (ou inverser) sauf en utilisant WKT. Notez que certains traitements d'objets ne nécessitent pas de savoir si l'on traite l'anneau extérieur ou intérieur d'un polygone et une partie d'une chaîne de lignes en plusieurs parties.

Mon ami Anand Kannan de MapInfo m'a envoyé du T-SQL pour inverser le XY, Lat/Long qui repose sur le traitement des chaînes WKT. J'ai envisagé d'écrire une fonction similaire et j'en suis arrivé à la même conclusion : cela nécessiterait le piratage de chaînes (le script d'Anand est arrivé le lendemain où j'avais décidé que je n'allais pas m'engager dans cette voie). C'est moche, lent et a d'autres difficultés (par exemple l'internationalisation et l'utilisation de virgules comme points décimaux en Europe, etc.).

J'ai écrit de nombreuses fonctions supplémentaires dans le PL/SQL d'Oracle précisément parce que je peux accéder à tous les aspects du format de stockage. Je ne veux pas avoir à écrire C# (pour lire/écrire WKB ou WKT) et déployer le code dans la base de données si je peux l'aider.

Donc, si nous sommes coincés avec l'ordre lat/long, mon principal plaidoyer est de voir beaucoup plus de puissance déployée dans la base de données pour le traitement T-SQL via une API beaucoup plus riche qui est actuellement couverte par n'importe quelle norme OGC ou SQL/MM. Pour ma part, je ne veux pas avoir à coordonner un progiciel SIG de gros client (le gros client n'est pas censé être péjoratif) et un processus de base de données afin de traiter les données.

C'est bon de te voir ici! :-) Mais je ne suis pas d'accord avec ce qui précède : l'ordre des coordonnées pour la projection "Latitude / Longitude" (également appelé "lat/lon") en KML défini par Google est lon / lat.

Permettez-moi de changer de vitesse pour défendre Microsoft, qui, je pense, est injustement distrait dans ce fil avec une discussion sur l'analyse de la bouillie OGC. Ce n'est pas le propos. Il s'agit d'un nouveau type, la GÉOGRAPHIE, qui peut faciliter la vie de certains utilisateurs. C'est une mission différente de quelque chose comme GEOMETRY fourni pour une utilisation avec des données SIG existantes par des personnes SIG expérimentées.

J'ai l'impression que certaines personnes qui lisent ce fil sont novices en matière de données géospatiales et ne réalisent pas que l'expression anglaise courante "Latitude / Longitude" data est exactement à l'opposé de la façon dont les données sont réellement ordonnées dans le monde des données SIG. Vous n'êtes pas seul si c'est ce que vous attendiez.

Ce n'est pas destiné à être une critique, car c'est plutôt un argument très solide pour avoir l'ordre des coordonnées tel qu'il est dans le type GEOGRAPHY si cela est effectivement destiné aux non-SIG. Si le but de la GEOGRAPHIE est d'avoir quelque chose pour les types non SIG, l'ordre (lat, lon) est parfaitement logique.

La chose la plus naturelle au monde pour quelqu'un qui découvre les données géospatiales est de penser, non, de * s'attendre * que lorsque quelqu'un dit qu'il a des données "Latitude / Longitude" que l'ordre des coordonnées pour ces données est en effet dans l'ordre (lat, lon) juste comme l'expression anglaise couramment utilisée pour le décrire le dit. Les personnes familières avec les données géospatiales comprennent que la phrase anglaise n'est qu'une phrase, pas une description mathématique de l'ordre des axes de coordonnées, mais les débutants ne le savent généralement pas. Manifold a vendu plus de SIG robustes à de nouveaux utilisateurs que tous les autres fournisseurs de SIG réunis, alors j'assure aux lecteurs qu'il s'agit d'un phénomène bien réel.

Une partie de ce que SQL Server peut faire en ajoutant des extensions spatiales consiste à élargir les avantages de la technologie géospatiale à un public beaucoup plus large. Microsoft a la capacité de le faire, contrairement aux autres fournisseurs. Concilier les attentes des débutants géospatiaux (même s'ils peuvent être des experts en SGBD et pas du tout des débutants en programmation) avec la pratique accumulée au sein des téraoctets de données SIG n'est pas facile, mais avoir deux types est une innovation utile qui peut y arriver.

Si Microsoft peut faciliter la vie des personnes qui découvrent les données géospatiales avec un classement des coordonnées dans GEOGRAPHY différent des données SIG héritées, eh bien, c'est parfaitement correct et une raison suffisante pour moi. Quoi qu'il en soit, nous le soutiendrons. Microsoft a également implémenté GEOMETRY pour ceux qui utilisent des données SIG, il n'y a donc aucun inconvénient pour ceux qui travaillent avec des données SIG.

Comme je l'ai déjà dit, si vous utilisez des données SIG, vous feriez mieux de les stocker dans GEOMETRY afin de ne pas perdre d'informations essentielles, telles que les données, nécessaires à la précision. Utilisez GEOMETRY avec les données SIG, qu'il s'agisse de projection "Latitude / Longitude" ou non, et il n'y a aucun problème avec l'ordre des coordonnées. Par conséquent, mon conseil à Simon serait d'utiliser la GÉOMÉTRIE et d'être heureux que vous l'ayez.

Un post-scriptum pour ceux qui aiment les discussions sur les détails techniques :

Juste pour que tout le monde sache que je ne prétends pas capricieusement que l'ordre dans GEOGRAPHY est OK parce que je ne comprends pas que l'ordre (lon, lat) est universel, permettez-moi de citer quelques exemples et de corriger certaines idées fausses qui peuvent s'être glissées dans ce fil, à commencer par l'idée que n'importe qui devrait se soucier de ce que fait l'OGC ou une idée fausse de ce que GML ou EPSG spécifie.

Premièrement, les "standards" de l'OGC sont presque inutiles dans la vraie vie. Isaac a mis le doigt sur la tête quand il a écrit " De plus, si nous supposons que la spécification couvre les coordonnées géographiques, nous trouvons que la spécification est terriblement inadéquate." Bien dit !

En parlant de "normes" OGC presque inutiles, cela fait apparaître GML, qui a été décrit comme "peut-être le pire format pour les données géospatiales, juste après le braille". Étant donné que GML représente peut-être moins d'un millionième des données géospatiales là-bas, je ne Je ne pense pas qu'il importe du tout dans un sens pratique quel ordre de coordonnées GML utilise. Mais, si nous fendons les cheveux en quatre et prétendons que GML est important, je dois respectueusement être en désaccord avec la suggestion selon laquelle GML spécifie l'ordre (lat, lon).

La norme GML stipule que l'ordre des coordonnées doit suivre celui de la projection. Pas très utile d'un point de vue pratique. Ainsi, bien que GML inclue des moyens de spécifier explicitement l'ordre des axes de coordonnées, il ne choisit pas explicitement l'ordre (lat, lon) plutôt que l'ordre (lon, lat). Dans tous les cas, l'utilisation de GML pour les données lat/lon est si rare que nous n'avons pas encore vu de fichier GML réel avec des données lat/lon quel que soit l'ordre des coordonnées.

En ce qui concerne EPSG, je ne suis pas d'accord non plus avec ce qui est normalement traité comme un ordre (lat, lon): Les gars d'EPSG ont conçu leur système de sorte que les axes utilisés par un système de coordonnées soient numérotés. Je n'ai jamais entendu parler de personne (Oracle, etc.) reflétant l'ordre de ces axes sur des valeurs de coordonnées réelles. Je peux voir l'intérêt de SQL Server comme il le fait dans GEOGRAPHY et je respecte cela à 100%, mais je pense que toute la justification dont on a besoin est de savoir comment c'est fait dans SQL Server, car la façon dont c'est fait là-bas devient le de norme de facto que nous suivrons.

J'ai été mis au défi dans le passé pour avoir déclaré que la commande (lon, lat) était une pratique "universelle" dans les données SIG, alors permettez-moi de préciser pourquoi j'affirme que c'est le cas : appelées projections "Latitude / Longitude" :

1. Les coordonnées dans les ensembles de données TIGER/Line produits par le US Census Bureau sont en lat/lon. L'ordre des coordonnées est lon/lat.

2. Les coordonnées dans les ensembles de données NTAD produites par le US Bureau of Transportation Statistics sont en lat/lon. L'ordre des coordonnées est lon/lat.

3. Les coordonnées en GDF et autres ensembles de données produits par TeleAtlas, une grande société européenne de cartographie, sont en lat/lon. L'ordre des coordonnées est lon/lat.

4. Les coordonnées dans les ensembles de données VMap produits par le département américain de la Défense peuvent être dans plusieurs systèmes de coordonnées différents. Pour les systèmes de coordonnées lat/lon, l'ordre des coordonnées est lon/lat.

5. Les coordonnées dans SHP (ESRI "shapefiles"), MIF (MapInfo) et d'autres fichiers produits par les packages SIG actuels peuvent être dans de nombreux systèmes de coordonnées différents. Pour les systèmes de coordonnées lat/lon, l'ordre des coordonnées est lon/lat dans ces systèmes.

6. Les coordonnées au format DGN (Intergraph, Bentley), DWG (Autodesk et bien d'autres), DXF et les fichiers similaires produits par les progiciels de CAO actuels peuvent se trouver dans de nombreux systèmes de coordonnées différents. Pour les systèmes de coordonnées lat/lon, l'ordre des coordonnées est lon/lat.

7. Les coordonnées en valeurs WKB / WKT stockées dans les bases de données traditionnelles telles que Oracle, DB/2, PostgreSQL et MySQL (qui n'ont pas d'équivalents au type GEOGRAPHY mais sont néanmoins utilisées pour stocker beaucoup de données en circulation) peuvent être dans de nombreux différents systèmes de coordonnées. Pour les systèmes de coordonnées lat/lon, l'ordre des coordonnées est lon/lat.

8. La représentation des coordonnées dans un raster (les écrans de Terre virtuelle étant un exemple) suit presque toujours la notation XY, qui pour les rasters lat/lon signifie presque toujours lon/lat.

9. Lorsque les gens commencent à utiliser SQL Server 2008 pour stocker des données spatiales, beaucoup d'entre eux utiliseront le type GEOMETRY même si leurs données sont en lat/lon, pour diverses raisons. Pour ces personnes, l'ordre des coordonnées sera à nouveau lon/lat et cet ordre sera préservé lorsque ces données seront utilisées dans les produits SIG.

Ouf! . c'est ce que j'entends par utilisation "universelle", comme les formats ci-dessus comprennent, quoi ? 99,99 % ? des données là-bas. Si quelqu'un peut pointer ne serait-ce qu'un seul référentiel de données "Latitude / Longitude" qui utilise l'ordre (lat, lon) au lieu de l'ordre (lon, lat), je serais très reconnaissant de voir l'URL de ce référentiel.

Pour tout ce qui précède, le choix de Microsoft de commander pour la GÉOGRAPHIE est parfait si, en effet, cela peut aider les personnes novices en données géospatiales qui prennent l'expression "Latitude / Longitude" au pied de la lettre, comme elles le font habituellement. Aussi fier que quiconque puisse être à propos de l'utilisation du SIG à ce jour, même 100 % de toutes ces données ne représentent pas 1 % de ce qui arrive à mesure que la technologie géospatiale se généralise, donc ce que les gens qui découvrent l'art attendent n'est pas quelque chose à négliger à la légère .

Si c'était moi, j'aurais probablement été conventionnel et m'en serais tenu à la commande (lon, lat). Mais alors, il ne fait aucun doute que j'aurais pris la tâche d'expliquer encore et encore à des centaines de millions de personnes à l'avenir (dont aucun ne lira de documentation) que par "Latitude / Longitude" je voulais vraiment qu'ils comprennent qu'ils doivent mettre leurs coordonnées dans l'ordre "Longitude / Latitude". Quiconque critique Microsoft dans ce choix devrait réfléchir à deux fois à la façon dont il gérerait cela.


Équivalent WKT de la projection locale

J'essaie d'utiliser gdal pour projeter des formes de base à partir d'un certain nombre de systèmes de coordonnées locaux. Ces systèmes de coordonnées sont pris en charge par ArcGIS, mais en fin de compte, je me fatigue simplement à utiliser gdal (et proj4) pour convertir ces géométries en lat/long de base (EPSG: 4326). Voici ce que renvoie gdalsrsinfo :

Si j'essaie d'utiliser ogr pour traduire le fichier de formes de points, j'obtiens l'erreur suivante :

Est-ce que proj4 prend en charge les systèmes de coordonnées locales ? Une suggestion sur ce que je devrais utiliser pour le paramètre PROJECTION ?


Système de coordonnées de référence (CRS) dans Geopandas¶

Heureusement, définir et modifier les projections est facile dans Geopandas. Dans ce tutoriel, nous verrons comment récupérer les informations du système de coordonnées de référence à partir des données et comment modifier le crs. Nous allons reprojeter un fichier de données de WGS84 (coordonnées lat, lon) dans une projection Lambert Azimuthal Equal Area qui est la projection recommandée pour l'Europe par la Commission européenne.

Pour ce tutoriel, nous utiliserons un Shapefile appelé Europe_borders.shp représentant les frontières des pays en Europe, que vous auriez déjà dû télécharger lors du tutoriel précédent dans le dossier L2_data.

Dans Shapefiles, des informations sur le système de référence de coordonnées sont stockées dans le fichier .prj (si ce fichier est manquant, vous pourriez avoir des problèmes !). Lors de la lecture des données dans GeoDataFrame avec Geopandas, les informations crs sont automatiquement stockées dans l'attribut .crs du GeoDataFrame.


Un cas de préfixes manquants : ArcGIS . Géométries

par JoshuaBixby

Dans /blogs/tilting/2014/07/25/semantic-overloading, j'aborde l'une des principales motivations pour écrire le blog Tilting at Globes :

Je crois que la sémantique est importante dans tous les aspects de la vie. Qu'il s'agisse du droit, de la médecine, des sciences, des affaires, des technologies de l'information ou de tout autre domaine ayant un langage commun ne sert à rien s'il n'y a pas une compréhension commune des mots qui composent le langage. Étant donné que les langues évoluent, maintenir une compréhension commune des mots au fil du temps est un défi permanent.

Idéalement, une compréhension commune signifierait qu'un mot ou un terme a un sens unique, et ce sens singulier est connu et compris par tous ceux qui utilisent le mot ou le terme. Malheureusement, la réalité n'est pas toujours idéale, et parfois le contexte du mot ou du terme joue un grand rôle dans sa signification. Par exemple, la façon dont le terme « à grande échelle » est appliqué aux cartes peut sembler contre-intuitif par rapport à la façon dont il est appliqué aux actions, aux événements et aux objets typiques. Quand on comprend que l'échelle de la carte s'applique à la représentation des données sur la carte, c'est-à-dire le rapport de la distance sur la carte à la distance au sol, cela permet d'expliquer pourquoi les cartes « à grande échelle » couvrent de petites zones géographiques au lieu de grandes zones géographiques. . Bien sûr, une carte à grande échelle pourrait couvrir une grande zone géographique si elle était imprimée sur un support énorme, mais je suppose des tailles d'impression typiques.

Passant des cartes aux géométries, j'évoque un cas d'opérateurs spatiaux dans /blogs/tilting/2015/05/14/whats-within-when-esri-clementini . Dans l'article de blog, je souligne comment la réponse à la question de savoir si une géométrie est "à l'intérieur" d'une autre géométrie peut dépendre de la personne à qui vous demandez, ou plus précisément, de la définition de "à l'intérieur" utilisée pour répondre à la question. Souvent, les qualificatifs sont soit incomplets, soit complètement exclus des réponses, et nous finissons par nous fier au contexte pour combler les lacunes.

En plus de la façon dont les géométries sont liées les unes aux autres, il existe même des contextes différents pour comprendre la structure des géométries ou des types de géométrie. Le modèle d'objet géométrique ArcGIS de génération actuelle d'Esri existe depuis la sortie d'ArcMap 8.0. Bien que le modèle ait évolué au fil du temps, il n'est pas très différent de celui de sa sortie en 1999. Je ne connais pas bien l'historique du type de stockage ST_Geometry d'Esri, mais je sais qu'il existe depuis au moins ArcGIS 9.x journées. Même dans un contexte de types de géométrie Esri, la suppression de qualificateurs peut parfois conduire à une ambiguïté. On peut affirmer que l'API REST d'Esri représente un troisième modèle géométrique Esri, mais l'ajout de ce modèle géométrique dans ce billet de blog ne change pas les observations et les conclusions.

Instead of diving into object model diagrams and reference documentation, let's look at an example of how ArcGIS and ST_Geometry types differ in terms of structure. Below is an image of, and the code to create, four geometries in a SQLite database using Esri's ST_Geometry type. Each geometry is attributed with both its ST_Geometry and ArcGIS geometry type.

  • ArcGIS has a single polyline geometry type, ST_Geometry has ST_LINESTRING and ST_MULTILINESTRING types.
  • ArcGIS has a single polygon geometry type, ST_Geometry has ST_POLYGON and ST_MULTIPOLYGON types.
  • Whereas ArcGIS has point and multipoint there is no multi- prefix when working with polyline and polygon .

If the ST_Geometry types look familiar to those who work with open standards, it isn't coincidence. The documentation on How is ST_Geometry implemented?—Help | ArcGIS Desktop states in several places that ST_Geometry "is a high-performance storage type that includes ISO- and OGC-compliant SQL access to spatial data." There are several ISO- and OGC- standards when it comes to geometries, and the "SQL access to spatial data" part of the statement is actually quite important as a qualifier.

ISO- and OGC-compliance is fairly broad across various geometry models or storage types, e.g., Microsoft's STGeometry, Oracle's SDO_GEOM, PostGIS/PostgreSQL ST_Geometry, and others. The OGC/OpenGIS geometry object model is described in OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common. . Instead of embedding a geometry class hierarchy diagram or listing all of the geometry types, I will share there are LineString and MultiLineString types as well as a Polygon and MultiPolygon types.

All of this leads to a point, and yes I do have a point, that ArcGIS polyline and polygon types are basically multi-types, just with the multi- prefix missing. Worse yet, most of the ArcGIS documentation abstracts the user even further from the structure of the ArcGIS Geometry Object Model. Instead of polylines having paths and polygons having rings, which they do, everything just has "parts." I touch on this problem of "parts" in /blogs/tilting/2016/02/20/the-single-multipart-polygons-with-interior-boundaries:

Whether it is missing prefixes or the ubiquitous part, understanding the nuances of the implementation and documentation of the ArcGIS Geometry Object Model can help one understand how ArcGIS software, including ArcPy, interacts with other geometry types.


Contenu

Use the existing data dictionary framework to implement the SRS definition storage and caching. Implement SRSs as strong entities in the dictionary.

Store SRS definitions as WKT strings. Parse the string on demand when the data dictionary reads the definition from disk and return an error if the string doesn't contain a valid SRS definition. The GIS function will catch this error and raise an exception condition.

Interface of class dd::Spatial_reference_system

Class dd::Spatial_reference_system is a subclass of dd::Dictionary_object. Most public functions are getters/setters for parameter values.

To begin with, only one property is needed: whether the SRS is a projection or not. As geography support is implemented, the interface will be extended with functions to access other properties of the SRS (i.e., getters for attributes of gis::srs::Spatial_reference_system). The plan is to access these properties indirectly through the dd::Spatial_reference_system object.

Non-inherited public member functions

Table mysql.st_spatial_reference_systems

Implement the table as suggested in SQL/MM 2011, Section 18.3, without the CHECK constraints. Use the following definitions for implementation-defined meta-variables:

ST_MaxSRSNameLength 256
ST_MaxOrganizationNameLength 256
ST_MaxSRSDefinitionLength 4096
ST_MaxDescriptionLength 2048

These definitions are similar to the recommendations in OGC CT Sect. B.3.

In addition, add columns for catalog, creation timestamp and last modification timestamp, similar to other data dictionary tables.

Table definition

The names of the id and name columns deviates from the suggestion in SQL/MM, but is in line with the other dictionary tables.

The catalog_id is left out of the primary key because the current data dictionary implementation expects the ID to be a globally unique number. This makes the SRID globally unique. The ID type can be changed to make SRIDs catalog specific when catalog support is implemented.

Names are taken from the EPSG Dataset and are defined in OGC 373-7-1, Annex C. That definition does not mention case sensitivity, but it seems safe to assume that OGP will not use case differences to make names unique. Therefore, the name column, and the index on it, uses a case insensitive collation.

The order of the last_altered and created colums is chosen to avoid any problems with the implicit defaults of the first TIMESTAMP column in a table (cf. http://dev.mysql.com/doc/refman/5.7/en/timestamp-initialization.html).

Locking

Implement a new metadata lock namespace, "SRID", to protect SRS definitions in the cache. MDL keys have namespace "SRID", DB/schema "" (empty string), and the SRID number (ASCII string) as name.

Take a transaction lifetime shared read lock before retrieving the SRS definition and a transaction lifetime exclusive lock when adding/updating SRS definitions.


Problem with WKT in SQL Server 2008 R2 and SDE 10 SP1

I'm inserting via SQL a bunch of multi-part lines, that are represented in WKT. I'm using the STIsValid() and MakeValid() functions of SQL Server.

All was well until I hit this part:
MULTILINESTRING((-97505.1929793411 -105143.43196521,-97505.1929775407 -105143.431963236),(-97529.3438960883 -105163.592387535,-97505.1929793411 -105143.43196521),(-97532.572884962 -105166.287443998,-97529.3438960883 -105163.592387535),(-97565.2298758472 -105184.926958411,-97532.572884962 -105166.287443998),(-97600.6628490141 -105206.56252583,-97565.2298758472 -105184.926958411),(-97621.1848213568 -105220.102861102,-97600.6628490141 -105206.56252583),(-97621.1848213568 -105220.102861102,-97691.0012017201 -105262.139530079))

For some reason (that I don't know why) when I add this line to the feature, ArcMap starts behaving strangely: sometimes it doesn't show the new line. If I delete this record from the table all goes to normal.

When I try to export to a shape using ArcMap, it gives the following error:
Error exporting data
The number of points is less than required for feature

This features has already more than 2000 records, and this is the only one giving me trouble.

To SQL Server it is valid, and it represents it in the spatial results tab.

I also tried to use PostGre/PostGis, it accepted the WKT geom and converted into GeoJson and I was able to represent that on QGis.


Geotools reversing lat/lon for WGS when transforming between projections

I'm having issues with Geotools reversing the latitude and longitude, using JTS.transform(). It's been driving me mad now for days.

I have different data sets defined in different projections. The goal is that I can map any coordinate in a given projection WKT to a (lon, lat) in WGS84. Here's my util that does the conversion:

and here are my unit tests:

What happens is really confusing. For the WGS84 to WGS84 projection testWgs(), the transform action reverses the coordinates. Coordinate.x becomes the latitude, Coordinate.y is the longitude, thus the assert fails:

Le testLaea() passes without problems.

When I run the tests now, testWgs() passes, but now the coordinates are reversed for testLaea()!!

The final thing I tried is to use

which does nothing at all. Can anybody explain what's happing here, and does anyone know how I can force the outcome of the transform always to have x=longitude and y=latitude? Thanks!