Quoi de neuf avec la spécification GeoJSON et CRS en tant qu'IRM?

J'écris une API Web pour nos données SIG, en train de réorganiser notre service de géocodage. Je crée l'option pour que les gens spécifient le type de sortie en tant que GeoJSON, donc j'essaie de suivre les spécifications. Nos données sont stockées dans la projection nord nad83 datum UTM zone 12. La spécification GeoJSON dit d'ajouter un CRS. Le wkid est le 26912 mais qu'est-ce que l'OGN CRS URN?

Je peux comprendre que l'URN OGC CRS se décompose en plusieurs parties.

urn: ogc: def: crs: OGC: 1.3: CRS84

urn est l'identifiant, ogc est l'organisation, def est un autre accord statique, crs est le type (système de référence de coordonnées), OGC est l'autorité, 1.3 est la version et CRS84 est la projection.

Pourquoi l'autorité de l'UTM 26912 est-elle l'European Petroleum Survey Group?

Des frameworks de mappage utilisent-ils même ce nom CRS?

Je veux suivre la spécification mais il semble que plus de frameworks de mappage utilisent le wkid.

http://spatialreference.org/ref/epsg/26912/

semble être le meilleur endroit pour obtenir les informations, mais ils ne répertorient même pas l'urne. La spécification GeoJSON est-elle juste idiote ou quoi?

— Steve
source

Why is the authority of utm 26912 the European Petroleum Survey Group? Vous pensez peut-être que dans le mauvais sens. EPSG gère une base de données de projections et leur attribue des codes. EPSG est donc l'autorité pour une projection UTM 26912, car c'est le code qu'EPSG a attribué à une projection UTM. ESRI ou une autre autorité pourrait attribuer le même code ou un autre à la même définition de projection. Tant que les clients savent comment rechercher l'identifiant de projection dans la base de données des autorités, nous saurons où nous en sommes tous

— nmtoken

EPSG peut vous donner un WKT pour 26912 ~ epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::26912 ou le GML ~ epsg-registry.org/export.htm?gml=urn : ogc: def: crs: EPSG :: 26912

— nmtoken

Vous voulez urn:ogc:def:crs:EPSG::26912du lien GML sur spatialreference.org . GML utilise la syntaxe URN pour décrire les systèmes de coordonnées.

Vous pouvez également spécifier

"crs": {
  "type": "link",
  "properties": {
    "href": "http://spatialreference.org/ref/epsg/26912/esriwkt/",
    "type": "esriwkt"
    }
  }

"crs": {
  "type": "link",
  "properties": {
    "href": "http://spatialreference.org/ref/epsg/26912/proj4/",
    "type": "proj4"
    }
  }

La spécification GeoJSON n'est pas idiote ici. Il essaie de tirer parti de la spécification de description du système de coordonnées la plus précisément spécifiée. Il s'agit très probablement de la description GML SRS de style URN.

Je conviens que la consommation de ce produit n'est pas aussi largement disponible. C'est pourquoi la syntaxe alternative de "lien" dérivable est disponible, et je voulais explicitement qu'elle soit liée à des liens spatialreference.org. Je sais que proj4js tire parti de cette fonctionnalité de la spécification GeoJSON. Vous pourriez y chercher l'inspiration.

— Howard Butler
source

Il me semble que ce serait pénible pour les créateurs / utilisateurs d'API de cartes Web de placer un point sur une carte avec une urne. Puisqu'il y a peu d'adoption de spécifications sur ce front. Surtout s'il s'agissait d'un type de lien. vous devez faire un appel api à l'URL du lien ou quelque chose pour comprendre la projection?

— Steve

ce ne serait pas non plus urn: ogc: def: crs: EPSG :: 26912 car il n'y a pas de numéro de version?

— Steve