Commençons par regarder le format GeoJSON. Comprendre ces concepts de format informatique/physique/mathématique/géomatique vous aidera à comprendre les données géospatiales en général: les concepts de base derrière GeoJSON ont été une partie de "geo" depuis le tout début.
La spécification GeoJSON elle-même est une spécification formelle d'un format assez lisible pour le javascript:
http://geojson.org/geojson-spec.html
GeoJSON (2008) is a geospatial data interchange format based on JavaScript Object Notation (JSON).
http://www.macwright.org/2015/03/23/geojson-second-bite.html
Ce que vous ne pouvez faire GeoJSON
La popularité de GeoJSON dérive de sa simplicité, ce qui le rend facile à mettre en œuvre, à lire et à partager. Mais comme tous les autres formats, il a ses limites:- GeoJSON n’a aucune construction de topologie, que ce soit pour la compression, tels que TopoJSON ou sémantique, comme OSM XML et certains formats propriétaires. Une couche topologique sur GeoJSON est possible mais elle est restées lettre morte.
- "GeoJSON caractéristiques" ont des propriétés (features) qui sont de JSON. Ces features peuvent utiliser tous les types de données JSON : nombres, chaînes, tableaux null, booléens, et des objets. JSON ne supporte tous les types de données : par exemple, les valeurs de date sont prises en charge par Shapefiles, mais pas dans JSON.
- GeoJSON n’est pas une construction de style caractéristiques ou en spécifiant le contenu popup. Il y a des conventions folkloriques pour le faire, mais ceux-ci ne sont pas et ne sera pas dans la spécification. La plupart des formats de geo n’ont pas style.
- GeoJSON n’est pas un type de géométrie du cercle, ou n’importe quel type de courbe. Seuls quelques formats, comme WKT prend en charge les courbes et des cercles plutôt que des géométries linéaire. Cercles et courbes sont relativement difficiles à mettre en œuvre, car un cercle sur une planète de géoïde sphéroïde est beaucoup plus complex qu’un cercle sur une feuille de papier ;)
- Positions n’ont pas des attributs. Si vous avez une représentation de LineString d'une course/ballade, et votre GPS montre connecté avec 1 000 points différents le long du parcours avec des données comme votre fréquence cardiaque et de la durée, hélas il n’y a aucune réponse claire pour la représentation de ces données. Vous pouvez stocker des données supplémentaires dans des positions coordonnées de quatrième et cinquième, ou dans les propriétés sous forme de tableau avec la même longueur que le tableau de coordonnées, mais aucune de ces options est supporté par l’écosystème des outils. La spécification de fonctionnalités simples, qui a directement inspiré GeoJSON et la plupart des formats SIG, ne supporte pas cette notion d’attributs-à-poste (voir les deux formats - GPX et OSM XML).
Latitude et Longitude
Une incohérence frustrante dans les logiciels géospatiaux (notamment de type mappage) est l'ordre des coordonnées.Les coordonnées sont souvent représentées sous forme de tableaux, comme [45.1, 4.1.], au lieu d'objets, comme {lng: 4.1, lat: 45.1}. Cela laisse au développeur de déterminer si 45.1 est la longitude ou la latitude. Un choix place un point sur Lyon, et l'autre un emplacement profond dans la Somalie.
La latitude de la ville de Lyon est proche de 45. Le pole nord c'est Lat=90 et l'équateur c'est une Lat= 0.
La longitude "0.00" est lié à Greenwich (Lat 51.48; Lng 0.00) un quartier de Londres :
https://fr.wikipedia.org/wiki/Greenwich_(Londres)
Le système de référence de coordonnées (CRS)
Le système de référence de coordonnées (CRS) d'un objet GeoJSON est déterminé par son membre 'crs'. Si un objet n'a pas de membre crs, son membre crs de l'objet parent ou grand-parent peut être acquis. Si aucun membre crs ne peut être ainsi acquis, le CRS par défaut s'appliquera à l'objet GeoJSON.Le CRS par défaut est un système de référence de coordonnées géographiques, utilisant le datum WGS84, et avec des unités de longitude et de latitude de degrés décimaux.
https://fr.wikipedia.org/wiki/WGS_84
GeoJSON (ici minimaliste) pour un point situé sur Fourvière à Lyon:
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {},
"geometry": {
"type": "Point",
"coordinates": [
4.8264312744140625,
45.76581655469703
]
}
}
]
}
GeoJSON a un ordre = Longitude,Latitude
L'ordre latitude longitude ou l'inverse
Il ya un certain consensus croissant autour de l'ordre (longitude, latitude) pour les formats géospatiaux, mais hélas c'est toujours le chaos pour les bibliothèques et les logiciels. Il appartient au développeur d'être conscient de ce problème et de lire la documentation requise, surtout de déplacer les coordonnées si nécessaire pour traduire entre différents systèmes:
La tradition géographique favorise lat, lon mais les mathématiques et souvent les logiciels préfèrent l'ordre lon, lat...
L'utilisation des coordonnées sphériques différent suivant les domaines.
En physique c'est "(r, θ, φ)" avec la distance radiale, l'angle dans le plan équateur, puis l'angle azimuthal.
En mathématiques "(r, θ, φ)" avec la distance radiale, l'angle azimuthal puis l'angle dans le plan équateur.
En fait il existe un ISO standard 80000-2 :2009 pour l'ordre des angles (item 2-16.3 coordinate systems: spherical coordinates). La latitude est en premier.
Hélas cet angle "latitude" mathématique est égal à 0 au "pôle nord" (par rapport à l'axe zenith ou z axis en coordonnées euclidiennes). Il est noté :
L'angle entre l'axe et le plan équateur est dans la borne: [0,π].
L'angle dans le plan équateur (perpendiculaire à l'axe zenith) est dans la borne: [0,2π[.
Qu'en est-il de GPX ou OSM XML?
Les formats qui représentent lat et lon avec des attributs XML distincts et n'imposent aucun ordre de coordonnées, car les attributs XML ne sont pas ordonnés...Ref: en anglais http://www.macwright.org/lonlat/
No comments:
Post a Comment