Le format Well Known Text (WKT) est une représentation standardisée des géométries et des systèmes de référence des coordonnées (CRS) sous forme de texte. Ce format permet d’importer ou d’exporter ces objets avec d’autres logiciels tout en étant lisible pour les êtres humains. Le format Geographic Markup Language (GML) permet à peu près la même chose, mais le WKT est beaucoup plus compact et permet aux humains qui le lisent de comprendre plus rapidement l’objet décrit.
On trouve des Well Known Texts dans des bases de données spatiales, à la fois dans toute colonne de type géométrique ainsi que dans la table SPATIAL_REF_SYS. On trouve aussi des systèmes de référence des coordonnées exprimés au format WKT dans des fichiers portant l’extension « .prj » et qui accompagnent certaines images TIFF ou fichiers Shapefile. La plupart de ces sources de données utilisent la version 1 du format WKT telle que définit dans la norme ISO 19125 (elle-même dérivée d’une norme de l’OGC). La partie de cette norme qui concernait les systèmes de références spatiaux a été clarifiée dans un autre standard de l’OGC avant d’être finalement remplacée pas ISO 19162, aussi connue comme « WKT 2 ». Le texte qui suit ne concerne que les systèmes de références spatiaux; le WKT portant sur les géométries n’est pas discuté.
Les problèmes de la version 1 du format WKT
La norme originale ne précisait pas les unités du méridien d’origine ni celles des paramètres des projections cartographiques. Ainsi, beaucoup de logiciels interprètent le méridien d’origine comme étant exprimé systématiquement en degrés décimaux. C’est le cas notamment de la bibliothèque GDAL et des logiciels qui en dépendent (PostGIS, MapServer, QGis, etc.). Par la suite, ces unités ont été clarifiées dans le standard OGC 01-009 comme étant les mêmes unités que celles utilisées par les axes des longitudes et des latitudes du système géographique — donc pas obligatoirement des degrés décimaux. Cette interprétation a été adoptée par les standards GeoAPI 3.0 et GeoPackage 1.0 de l’OGC, mais beaucoup de logiciels existants ont préféré rester à leur façon de faire pour des raisons de compatibilités avec leurs versions antérieures. Ces logiciels justifient leur choix en disant qu’ils sont conformes à ISO 19125, mais en fait, cette ancienne norme étant silencieuse sur le sujet des unités des paramètres, n’importe quelle interprétation pouvait être considérée conforme.
Exemple: le système géographique de la Nouvelle Triangulation Française (EPSG :4807) exprime les angles en grades plutôt qu’en degrés. Le méridien de Paris est ainsi fixé à 2,5969213 grades. Mais de nombreux logiciels et sites internet utilisent un format WKT dans lequel cette valeur a été convertie à 2,33722917 degrés, tout en continuant de spécifier que les axes sont en grades. Cela concerne entre autres GDAL, MapServer, PostGIS, www.spatialreference.org et www.epsg.io (malgré son nom, ce dernier site n’est pas un site officiel d’EPSG). Un logiciel conforme au standard OGC 01-009 qui lirait un WKT produit par un des logiciels pré-cités interpréterait la valeur 2,33722917 comme étant exprimée en grades. La différence (14 minutes d’angle) représente une erreur d’environ 17 kilomètres à la latitude de Paris.
Une autre source d’incompatibilité est la différence d’interprétation de la chaîne de caractères apparaissant dans l’élément PROJECTION. GDAL et Apache SIS les interprètent comme le nom de la méthode de projection (par exemple « Mercator », comme terme générique désignant le même ensemble de formules pouvant être paramétrées différemment selon les endroits de la planète) alors que d’autres logiciels les interprètent comme le nom de la projection complète, incluant implicitement les valeurs des paramètres (par exemple « WGS 84 / World Mercator »). Cette différence est importante car Apache SIS ne peut pas décoder un WKT s’il ne reconnaît pas la méthode de projection.
En plus des problèmes de compatibilités décrits ci-haut, le format WKT 1 est une transcription dans un format texte d’un ancien modèle de systèmes de référence des coordonnées qui existait avant que la norme ISO 19111 ne soit adoptée. Cet ancien modèle est ambigu dans certains cas (par exemple, il ne spécifie pas directement si des coordonnées géocentriques utilisent un système de coordonnées cartésien ou sphérique), ne prévoie pas d’axe du temps, n’exprime pas certaines informations complémentaires telles que le domaine de validité, et contient un élément (TOWGS84) qui encourage une façon dépréciée de définir les transformations de coordonnées.
Transition de WKT 1 vers WKT 2
Pour résoudre les problèmes du format WKT 1, un nouveau format pour les systèmes de référence des coordonnées (CRS) a été définit en se basant sur le modèle ISO 19111. La spécification de ce nouveau format tente d’éviter le piège des ambiguïtés en décrivant chaque élément de manière détaillée. Le document est ainsi passé de 6 pages pour WKT 1 à environ 80 pages pour WKT 2. La nouvelle spécification est publiée à la fois comme standard ISO 19162 et comme standard OGC disponible en ligne. Pour faciliter la transition, ce format WKT 2 a été conçu de telle manière qu’un CRS exprimé dans un format WKT 1, conforme au standard OGC 01-009 et qui spécifie explicitement ses axes, sera interprété sans ambiguïté par un lecteur WKT 2 (bien que certains éléments puissent être ignorés ou rejetés parce que non-supportés), sans qu’il ne soit nécessaire de spécifier quel format est utilisé. Cette compatibilité n’est toutefois pas assurée pour les logiciels énumérés ci-haut qui utilisent l’interprétation non-conforme des unités.
Apache SIS, depuis sa version 0.6, figure parmi les premières implémentations d’un encodeur/décodeur de CRS au format WKT 2, tout en continuant à supporter le format WKT 1. Le support du format WKT 1 se divise lui-même en deux variantes: avec l’interprétation des unités conforme au standard OGC 01-009, ou avec l’interprétation des unités à la façon de GDAL. Ce dernier mode d’interprétation doit être activé explicitement en spécifiant au décodeur la valeur d’énumération Convention.WKT1_COMMON_UNITS, et sera ignoré si le décodeur détecte que le format est WKT 2.
Il peut y avoir une ambiguïté entre WKT 1 et WKT 2 concernant l’ordre des axes si ces derniers n’apparaissent pas explicitement dans le WKT. Selon la spécification WKT 1, les axes sont optionnels et sont par défaut ceux qui correspondent aux directions Est et Nord, dans cet ordre. La spécification WKT 2 en revanche ne dit pas explicitement si les axes sont optionnels, et détaille différentes directions d’axes selon le type de système de coordonnées. Pour un système ellipsoïdal, les axes y apparaissent systématique dans l’ordre (Nord, Est). Apache SIS procède en utilisant différents axes par défaut selon la version du format WKT qu’il détecte: (Est, Nord) par défaut pour la version 1, ou (Nord, Est) pour la version 2 si le système de coordonnées est ellipsoïdal.
Comparaison des formats WKT 1 et 2 pour un CRS géographique
Prenons l’exemple du système de référence des coordonnées WGS 84, aussi identifié par EPSG::4326. Les colonnes ci-dessous montrent le même système représenté selon les deux formats:
On constate d’abord un renommage des mots clés. Ainsi GEOGCS (l’abréviation de Geographic Coordinate System) est devenu GEODCRS (l’abréviation de Geodetic Coordinate Reference System). L’insertion du « R » pour Reference est significative car la norme ISO 19111 considère les Coordinate Systems (CS) et les Coordinate Reference Systems (CRS) comme deux concepts distincts. Ce remplacement du suffixe CS en CRSest d’ailleurs systématique pour tous les mots clés qui existaient en WKT 1 (PROJCS → PROJCRS, VERT_CS → VERTCRS, etc.) et peut être utilisé comme critère pour distinguer un texte au format WKT 1 d’un texte au format WKT 2. Toutefois, la spécification stipule que les lecteurs WKT 2 doivent reconnaître les anciens mots clés comme synonymes des nouveaux, ce qui (combiné avec d’autres règles présentées plus bas) assure un bon degré de rétro-compatibilité.
Le méridien d’origine (PRIMEM), qui était obligatoire en WKT 1, est devenu optionnel en WKT 2. S’il est omis, alors, la valeur par défaut est le méridien de référence international (Greenwich dans le cas de la planète Terre).
Un nouvel élément, CS (optionnel pour des raisons de rétro-compatibilité avec WKT 1), est apparu pour indiquer le type de système de coordonnées ainsi que le nombre de dimensions. A première vue, cet élément semble redondant avec les autres informations présentes dans le WKT puisque le nombre de dimensions se déduit aisément en comptant le nombre d’éléments AXES et que le type du système de coordonnées est forcément ellipsoïdal pour un CRS géographique, cartésien pour un CRS projeté, etc. Toutefois, certains CRS acceptent différents types de systèmes de coordonnées, auquel cas, tenter de deviner ce type à partir des axes ou autres informations peut devenir délicat. Par exemple, le système de coordonnées associé à un EngineeringCRS peut être quasiment n’importe quoi: des coordonnées polaires autour d’un radar, un système cartésien attaché à un bateau avec les directions tribord et avant, etc. Même pour les systèmes pourtant bien connus, depuis que la norme ISO 19111 a fusionné les systèmes géographique et géocentrique en un seul concept de système géodésique dans lequel le système de coordonnées peut être ellipsoïdal, sphérique ou cartésien, l’information sur le type de système de coordonnées devient importante pour distinguer ces trois cas. Si en outre le texte ne définit pas explicitement les axes, depuis l’alignement sur la norme ISO 19111, rien ne permet de deviner le nombre de dimensions (2 ou 3) d’un GEODCRS qui n’aurait ni AXIS ni CS. La section Définition d’un CRS géographique avec une hauteur ellipsoïdale plus bas explique les raisons.
Note sur le formattage: selon le modèle ISO 19111, les axes sont des composantes des systèmes de coordonnées. Les éléments AXIS auraient donc dû apparaître à l’intérieur de l’élément CS dans l’exemple ci-haut. Pourtant ils apparaissent au même niveau que CS (comme des sous-éléments de GEODCRS), même si une indentation a été artificiellement ajoutée pour donner l’illusion que les AXIS sont des sous-éléments de CS (l’indentation peut varier d’une implémentation à l’autre et est ignorée à la lecture). Le format WKT 2 a été défini ainsi pour des raisons de rétro-compatibilité avec WKT 1.
L’élément donnant les unités de mesure (UNIT) a été décliné en plusieurs éléments selon le type d’unités (LENGTHUNIT, ANGLEUNIT, SCALEUNIT, TIMEUNIT, PARAMETRICUNIT), bien que la spécification demande que l’on continue de reconnaître UNIT. En outre, les unités peuvent être spécifiées un peu partout: dans l’élément ELLIPSOID, dans les éléments AXIS, dans les éléments PARAMETER (non-montrés dans l’exemple ci-haut), etc. C’est beaucoup plus verbeux que le format WKT 1 où chaque type d’unité (linéaire ou angulaire) n’était spécifié qu’une seule fois dans des endroits bien précis, mais évite la confusion décrite plus haut avec l’exemple du méridien de Paris. Pour la rétro-compatibilité avec le format WKT 1, ainsi que pour les personnes préférant une notation plus compacte, il est toujours possible de ne définir chaque type d’unité qu’une fois comme le faisait WKT 1. Dans ce cas, les règles décrites par la spécification WKT 2 pour déduire quelles unités s’appliquent à quels éléments sont les mêmes que celles de la spécification OGC 01-009, au moins pour les éléments qui existaient déjà en WKT 1.
En WKT 2, la description des axes donnée par les éléments AXIS inclue, en plus du nom de l’axe, son abréviation entre parenthèses. Les abréviations permises sont partiellement standardisées: (X, Y, Z) pour les coordonnées géocentriques, souvent mais pas toujours (E, N) pour les coordonnées projetées, H pour une hauteur au-dessus du niveau de la mer, h pour une hauteur au-dessus de l’ellipsoïde, etc. Dans le cas des latitudes et longitudes où les symboles habituels sont les lettres grecs φ et λ, une translittération par les lettres latines P (pour phi) et L (pour lambda) est proposée. La liste des directions possibles (nord, ouest, sud-sud-est, etc.) a été enrichie à près de 40 valeurs pré-définies, dont des nouvelles directions telles que forward (avant), starboard (tribord) et clockwise (sens des aiguilles d’une montre). Une syntaxe particulière a été introduite pour spécifier les directions dans le cas des projections polaires. Ce cas particulier est rendu nécessaire par le fait qu’au pôle nord, toutes les directions vont vers le sud. Pour distinguer les différentes directions sud, on doit spécifier selon quel méridien l’axe s’éloigne du pôle. Exemple:
Enfin, les métadonnées, à la fin du CRS, ont été enrichies. On y trouve une description optionnelle de la zone de validité. Une description du domaine d’utilisation (scope) ainsi que des remarques sont aussi permises, mais ne sont pas montrées dans l’exemple ci-haut. Finalement, le mot-clé permettant de spécifier un identifiant (ID) a été étendu de manière à permettre d’utiliser aussi l’espace de nommage « urn:ogc:def:crs: » (optionnel).
Description d’un CRS géographique avec une hauteur ellipsoïdale
Lorsque le format WKT 1 a été défini, le modèle conceptuel de l’époque ne définissait que des systèmes géographiques à deux dimensions. Les systèmes tri-dimensionnels étaient construits en combinant un système bi-dimensionnel avec un système vertical. Il n’y avait donc pas d’ambiguïté sur le nombre de dimensions d’un CRS géographique (toujours 2), ce qui explique en partie pourquoi il n’avait pas été jugée nécessaire de déclarer le nombre de dimensions dans le WKT. Mais aujourd’hui, le modèle conceptuel défini par ISO 19111 considère les hauteurs ellipsoïdales comme inséparables des deux autres dimensions (latitudes et longitudes). La construction qui était employée en WKT 1 est devenue illégale en WKT 2. Au lieu d’un combiner un système géographique horizontale avec un axe vertical, la norme actuelle exprime directement le système géographique comme un système tri-dimensionnel:
Notez que la construction d’un système géographique tri-dimensionnel est utilisée seulement pour les hauteurs ellipsoïdales. Tous les autres types de hauteurs (hauteurs géoïdales, au-dessus du niveau moyen de la mer, comme mesure de pression, etc.) continuent d’utiliser des combinaisons de CRS similaires à ce qui était fait en WKT 1. Inversement, les combinaisons comme le faisait WKT 1 sont maintenant interdites pour les hauteurs ellipsoïdales, bien qu’utilisées pour tous les autres types de hauteurs.
Note explicative: pourquoi avoir introduit une telle exception pour les hauteurs ellipsoïdales, alors que l’ancienne norme traitait tous les types de hauteurs de la même façon? C’est que les autres types de hauteurs ont généralement un sens même si on les prends isolément. Par exemple, si on s’intéresse à une hauteur au-dessus du niveau moyen de la mer, on peut l’estimer sur n’importe quel rivage de la planète sans qu’il soit nécessaire de connaître notre position géographique. On peut observer le niveau de la mer pendant quelques temps, placer une marque à sa position moyenne, puis mesurer les hauteurs à partir de cette marque en utilisant un fil à plomb pour nous indiquer la direction de l’axe vertical. Si on ne se trouve pas à proximité de la mer, on peut prendre comme point de repère une autre marque dont la hauteur a été déterminée comme décrit précédemment.
Mais, les hauteurs ellipsoïdales, en revanche, sont mesurées à partir d’un ellipsoïde dont la surface peut passer jusqu’à une centaine de mètres au-dessus ou en-dessous de la surface du sol ou de la mer. On ne peut pas connaître la hauteur de l’ellipsoïde par rapport au sol sans connaître la position géographique. Même la direction de l’axe vertical n’est pas connue précisément. Évidemment, cette direction pointe approximativement vers le haut, mais les hauteurs ellipsoïdales, par définition, se mesurent perpendiculairement à la surface de l’ellipsoïde. Or, cette surface n’a pas forcément la même pente que le sol, ni la même pente que la surface équipotentielle du champ de gravité. La direction donnée par un fil à plomb étant dépendante du champ de gravité, cette direction ne sera pas nécessairement perpendiculaire à la surface de l’ellipsoïde. Encore une fois, pour connaître la direction de l’axe vertical, dans un système ellipsoïdal, il faut connaître sa position géographique. En bref, si on dispose d’une hauteur ellipsoïdale, on ne peut rien en faire de précis sur le terrain sans les coordonnées géographiques. Les auteurs de la norme ISO 19111 ont donc jugé prudent de concevoir le standard de manière à interdire la séparation de la hauteur ellipsoïdale des composantes horizontales.
1. Ocean 2. Elipsoide 3. Fil de plomb 4. Continent 5. Géoide source: wikipedia
Même sur le plan purement informatique, dans un programme qui ne s’intéresserait pas à ces « détails » du monde réel, l’existence de ce cas spécial est en fait plutôt avantageux (ce qui peut paraître contre-intuitif, vu qu’en général, les exceptions sont plutôt une source de complications en programmation). La raison est que lors de la transformation de coordonnées d’un référentiel vers un autre, les systèmes ellipsoïdaux tri-dimensionnels sont un point de passage quasiment obligatoire. Le système décrit dans cette section agit comme un « hub » par où transitent un grand nombre de transformations de coordonnées.
Description d’un CRS temporel
Le format WKT 1 ne prévoyait rien pour exprimer le temps. Ce manque a été comblé (du moins si on ignore la problématique des divers calendriers) dans le format WKT 2 par une structure assez simple, comme dans l’exemple suivant:
TIMECRS["Temps GPS",
TDATUM["Origine de l'axe du temps",
TIMEORIGIN[1980-01-01T00:00:00.0Z]],
CS[temporal, 1],
AXIS["Temps (t)", future],
TIMEUNIT["jour", 86400]]
Description d’un CRS projeté
La description d’un CRS basé sur une projection cartographique est assez similaire à ce qu’elle était en WKT 2 (mis à part les changements de mots-clés). Les principales différences sont que le CRS géographique sur lequel est basée la projection utilise un mot clé qui explicite son rôle de « CRS de base », que les axes du CRS de base sont omis, et que les paramètres de la projection cartographique sont englobés dans un nouvel élément CONVERSION. L’exemple ci-dessous utilise la façon WKT 1 de déclarer les unités (qui reste légale en WKT 2) plutôt que de répéter les unités dans chaque paramètres et chaque axes, afin de rendre la similitude plus apparente. La valeur de l’angle dans l’élément PRIMEM a été discutée dans la section sur les interprétations divergentes du WKT 1.
Les CRS dérivés permettent de construire un système de référence propre à un endroit, et de relier ce CRS particulier à un autre CRS plus connu en spécifiant la conversion allant de l’un vers l’autre. Son principe est similaire à celui des projections cartographiques, excepté que la base n’est pas forcément géographique et le résultat n’est pas forcément un système de coordonnées cartésien. La façon de représenter les CRS dérivés en WKT 2 est complètement différente de la façon de faire en WKT 1 — c’est sans doute le type de CRS où la différence est la plus flagrante, au point où l’on peut considérer les deux représentations comme incompatibles. Apache SIS toutefois reste capable de comprendre les deux formats et de passer de l’un à l’autre.
Dans le format WKT 1, tous les systèmes dérivés commençaient par le même mot-clé: FITTED_CS. Cet élément contenait un autre CRS (appelé « CRS de base ») décrit par la même syntaxe que s’il ne se trouvait pas à l’intérieur d’un élément FITTED_CS. La relation entre les deux CRS était spécifiée par une conversion allant du FITTED_CS vers le CRS de base.
Dans le format WKT 2, il n’y a pas de mot-clé annonçant dès le départ que l’on a affaire à un CRS dérivé. Au contraire, les systèmes dérivés commencent par les mêmes mots-clés que les CRS habituels: GEODCRS,VERTCRS, ENGCRS, PARAMETRICCRS, TIMECRS ou la version longue de ces mots-clés. Pour reconnaître qu’un CRS au format WKT 2 est de type dérivé, il faut examiner son contenu: les CRS dérivés contiennent un autre CRS dont le mot-clé commence par BASE, suivit d’un élément DERIVINGCONVERSION. Ce dernier donne la conversion du CRS de base vers le CRS dérivé, c’est-à-dire l’inverse de la conversion qui était donnée en WKT 1.
L’approche du WKT 2 concernant les types de CRS peut paraître plus compliquée que celle du WKT 1, mais possède un avantage qui la rend très intéressante: le résultat de la conversion étant un des types habituels, les CRS dérivés peuvent être utilisés dans du code « normal » qui attendait ces types, sans qu’il ne soit nécessaire de faire de traitement particulier pour les CRS dérivés. Par exemple, un CRS dérivé d’unVERTCRS sera lui-même un CRS vertical, et pourra donc être passé dans toute méthode Java qui attendait en paramètre un objet de type VerticalCRS. Avec l’approche du WKT 1, nous obtenions plutôt un objet de type DerivedCRS, ce qui bloquait son utilisation avec de nombreuses méthodes Java. Dans la pratique, nous utilisions peu les CRS dérivés en partie à cause de cette difficulté, alors qu’ils ouvrent pourtant des perspectives très attrayantes.
L’exemple ci-dessous est très simple afin de comparer plus facilement les deux formats. Il s’agit d’une conversion d’une profondeur sous la surface de la mer mesurée en mètres vers une valeur de l’ordre de grandeur de la pression en kilo-Pascal. Cet exemple est inspiré du fait que les océanographes expriment souvent la profondeur en unités de pression plutôt qu’en mètres puisque c’est ce que leurs instruments mesurent. Toutefois, cet exemple ne prétend pas que les unités du CRS dérivés seront réellement des kilo-Pascals d’abord parce que la formule réelle est plus compliquée que celle utilisée dans cet exemple, et surtout parce que la véritable opération exprimerait une transformation de coordonnées plutôt qu’une conversion (puisqu’il y aurait changement de référentiel), ce qui n’est pas le rôle des CRS dérivés. Nous inventons donc des unités imaginaires pour notre exemple, que nous baptisons « PP » pour « pseudo-pression ». Notre conversion se base sur le fait que la pression augmente d’environ 10 kPa par mètre de profondeur (valeur arrondie et en ignorant les effets tels que la température, la salinité et la compression de l’eau dans les grandes profondeurs) puis nous ajoutons la pression atmosphérique (arrondie à 100 kPa):Hpp = Hm × 10 + 100:
WKT 1
WKT 2
FITTED_CS["Pseudo-pression en kPa",
PARAM_MT["Affine",
PARAMETER["num_row", 2],
PARAMETER["num_col", 2],
PARAMETER["elt_0_0", 0.1],
PARAMETER["elt_0_1”, -10]],
VERT_CS["Profondeur sous la surface de la mer",
VDATUM["Niveau moyen de la mer", 2006],
UNIT[“metre”, 1],
AXIS[“Depth”, DOWN]]]
VERTCRS["Pseudo-pression en kPa",
BASEVERTCRS["Profondeur sous la surface de la mer",
VDATUM["Niveau moyen de la mer"]],
DERIVINGCONVERSION[“De la profondeur vers PP”,
METHOD["Affine"],
PARAMETER["num_row", 2],
PARAMETER["num_col", 2],
PARAMETER["elt_0_0", 10],
PARAMETER["elt_0_1”, 100]],
CS[vertical, 1],
AXIS[“Pseudo-pression (H)”, down],
UNIT[“Unity”, 1]]
Notez que le type du CRS dans le format WKT 2 est resté vertical (contrairement au WKT 1) et que les valeurs des paramètres elt_0_0 et elt_0_1 diffèrent entre ces deux formats. Les valeurs des paramètres de cet exemple se convertissent d’un format à l’autre en exprimant la conversion affine sous forme de matrice, puis en inversant cette matrice. Apache SIS sait effectuer ce genre d’opérations (et des plus complexes) sans que l’utilisateur n’ait à s’en soucier.
Les opérations sur les coordonnées
Le format WKT 1 définissait un élément PARAM_MT (pour Parametric Math Transform) comme une sorte de boîte noire prenant des coordonnées en entré (exprimées selon un CRS source) et retournant de nouvelles coordonnées en sortie (exprimées selon un CRS destination). Les objets PARAM_MT ne se souciaient que du calcul numérique sans connaître les CRS source et destination. Le format WKT 2 remplace cet élément par une nouvelle approche plus riche en métadonnées. Ce nouvel élément (COORDINATEOPERATION) contient des informations sur les CRS source et destination, ainsi qu’une estimation de la précision de la transformation des coordonnées, des remarques, etc. Bien qu’en principe les éléments PARAM_MT ne soient pas supportés dans la spécification WKT 2, en fait l’approche « boîte noire » du WKT 1 a aussi des avantages très importants pour Apache SIS. Les deux approches existent donc en parallèle dans SIS tout en étant intimement liées (elles se complètent l’une-l’autre d’une façon qui pourrait être le sujet d’un autre blog).
A l’intérieur de l’élément COORDINATEOPERATION, la spécification WKT 2 introduit un nouvel élément qui n’existait ni dans WKT 1, ni même dans le standard ISO 19111: INTERPOLATIONCRS. Cet élément optionnel peut accompagner les éléments SOURCECRS et TARGETCRS. Il indique que pour passer du CRS source vers le CRS destination, il est nécessaire d’effectuer des interpolations à des positions exprimées selon le CRS d’interpolation. Par exemple, pour passer d’un VERTCRS vers un autre VERTCRS, il peut être nécessaire de connaître les coordonnées géographiques où se trouvent les hauteurs à transformer. Or, les éléments VERTCRS ne contiennent que l’axe vertical. Le CRS d’interpolation permet de spécifier les axes horizontaux nécessaires à cette transformation.
L’introduction du CRS d’interpolation est une véritable innovation par rapport aux standards OGC précédents. Sur certains aspects, la spécification WKT 2 agit un peu comme une évolution du standard ISO 19111 faite indirectement. Le CRS d’interpolation est peut-être l’évolution la plus notable et pourrait réellement nous enlever une épine du pied dans Apache SIS. L’ajout de quelques valeurs supplémentaires pour des directions d’axes telles que avant et tribord, ainsi que la façon de spécifier des directions telles que Sud le long du méridien 90°E, sont d’autres évolutions à noter.
Variantes du format WKT 2
En plus de considérer les anciens mots clés comme synonymes des nouveaux, la spécification WKT 2 introduit aussi d’autres synonymes plus proches des noms employés dans la norme ISO 19111. Par exemple GeodeticCRS est synonyme de GEODCRS, ProjectedCRS est synonyme de PROJCRS, etc. (l’utilisation des majuscules ou des minuscules n’est pas significative). La spécification WKT 2 recommande d’utiliser les versions courtes et en majuscules, mais Apache SIS utilise les deux conventions selon le contexte:
Les méthodes qui surchargent Object.toString() utilisent la version longue (par exemple GeodeticCRS) car ils sont proches du nom de la classe de l’objet. En outre, ces méthodes n’échouent jamais, même si elles doivent retourner un WKT invalide pour cause d’éléments non-couverts par la norme.
Les méthodes qui surchargent IdentifiedObject.toWKT() utilisent la version courte (par exemple GEODCRS) telle que recommandée par la spécification. En outre, ces méthodes lancent UnformattableObjectException si elles ne peuvent pas retourner un WKT valide.
L’OGC (Open Geospatial Consortium) est un organisme qui édite des normes concernant différents protocoles dans la thématique géospatiale. Ces normes proposent de […]
Various Symbology Best Practices are available for Law Enforcement and Public Safety (LEAPS) used in the context of Emergency Management. None of these […]
