MySQL stocke-t-il les types de données de point comme LAT LNG ou LNG LAT?
J'ai l'habitude de voir le format d'emplacement comme la latitude suivie de la longitude, mais en utilisant les bibliothèques, je crois que je comprends MySQL pour le stocker comme POINT(LNG LAT), l'ordre inverse. Ma bibliothèque est-elle incorrecte ou s'agit-il du format réel? Je n'arrive pas à trouver ce détail dans la documentation MySQL.
Syntaxe du constructeur
En recherchant référence de fonction spatiale, vous verrez
Point(x, y)
Constructs a Point using its coordinates
Ce n'est pas tout à fait correct. Toutes les implémentations SIG doivent faire (x,y) Pour les coordonnées projetées qui est (long,lat). Mais, sur les systèmes géodidiques coordonnés, il y a un certain désaccord sur ce qu'il faut faire. MySQL (et SQL Server) font (lat,long) Mais PostGIS gère (long,lat) Partout.
Ceci est abordé dans le spec Norme de mise en œuvre OpenGIS® pour les informations géographiques - Accès simple aux fonctionnalités - Partie 2: Option SQL ,
- Pour les CRS géodésiques ayant un système de coordonnées ellipsoïdales 2D, les axes du système de coordonnées ellipsoïdaux bidimensionnels sont la latitude géodésique, positive vers le nord, et la longitude géodésique, positive vers l'est. La direction de l'axe doit être "nord" et "est" respectivement.
- Pour les CRS géodésiques ayant un système de coordonnées ellipsoïdales tridimensionnelles, le nom et l'abréviation des axes horizontaux dans une chaîne WKT doivent respecter les exigences du point ii). Le nom de l'axe vertical est "hauteur ellipsoïdale"; l'abréviation de l'axe vertical doit être "h" et doit être incluse lorsque les abréviations des axes horizontaux sont incluses.
Notez que les mots ci-dessus sont trouvés textuellement dans Information géographique - Représentation textuelle bien connue des systèmes de référence de coordonnées
Même aussi loin que la spécification 1.1,
Un système de référence spatiale, également appelé système de coordonnées, est un géographique (latitude-longitude) , un projeté (X, Y) ou un système de coordonnées géocentriques (X, Y, Z).
Cela dit, il semble que PostGIS et Oracle et de nombreuses bibliothèques tierces maintiennent (x,y,[z]) Pour tous les types de points. C'est en violation des spécifications pour WKT, mais c'est une convention assez courante. Par exemple GeoJSON fait aussi cela,
Les coordonnées des points sont dans l'ordre x, y (est, nord pour les coordonnées projetées, longitude et latitude pour les coordonnées géographiques)
Et l'ordre (lat, long) est explicitement défini par EPSG pour SRSID 4326, .
Un système de coordonnées 2D ou 3D dans lequel la position est spécifiée par la latitude géodésique, la longitude géodésique et (dans le cas tridimensionnel) la hauteur ellipsoïdale, utilisée dans les CRS géographiques.
Vous pouvez également envisager de consulter Le blog de Paul Ramsey (Captain PostGIS) sur ce sujet intitulé, "Appelons le tout"
Nicities
Comme note spéciale, MySQL apporte deux nouvelles fonctions au mélange,
Ces fonctions se distinguent de ST_X(), et ST_Y() et nécessitent un SRS géographique ou elles lèvent une exception et Erreur.
Espace de rangement
De les docs
En interne, MySQL stocke les valeurs de géométrie dans un format qui n'est pas identique au format WKT ou WKB. (Le format interne est comme WKB mais avec 4 premiers octets pour indiquer le SRID.)
Table 11.1 WKB Components Example
Component Size Value
Byte order 1 byte 01
WKB type 4 bytes 01000000
X coordinate 8 bytes 000000000000F03F
Y coordinate 8 bytes 000000000000F0BF
Un moyen simple de vérifier l'ordre passe hors de la latitude de plage:
SELECT ST_Longitude(ST_SRID(POINT(45, 160), 4326));
Donne ERREUR 3732 (22S03): Un paramètre de la fonction st_srid contient une géométrie avec une latitude 160.000000, qui est hors de portée. Il doit être compris entre [-90.000000, 90.000000];
Attention, la commande peut changer en fonction des fonctions que vous utilisez:
SELECT ST_Longitude(ST_SRID(POINT(45, 90), 4326));
SELECT ST_Longitude(ST_GeomFromText('POINT(45 90)', 4326));