C'est un peu compliqué. Vous devriez lire au moins ce document GeoTIFF
http://www.remotesensing.org/geotiff/spec/geotiff2.5.html#2.5.2.2 et quelques considérations GDAL
http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint .
En règle générale, tous les rasters (images aériennes, images satellite) utilisent pixel-is-area et les données de mesure comme les DEM utilisent pixel-is-point. Mais comment cela se répercute sur le géoréférencement et les étendues d'image n'est malheureusement pas si simple. Pour GDAL, le point d'ancrage du pixel est toujours dans le coin supérieur gauche d'un pixel - si vous stockez un nouveau point de contrôle au sol (GPC), les coordonnées données sont toujours liées au coin supérieur gauche du pixel correspondant et cela importe si les pixels sont définis comme des zones ou des points. GDAL signale également les mêmes étendues pour les images pixel par zone et pixel par point. Il appartient à l'utilisateur ou au logiciel utilisant GDAL de les traiter différemment si nécessaire.
La règle actuelle de l'OGC pour le géoréférencement des couvertures consiste à utiliser une grille définie dans la spécification GML v.3.2.1 longue de 437 pages. Cela fait une différence d'un demi-pixel dans l'emplacement d'origine pour pixel-est-point et pixel-est-zone parce que dans le cas de pixels de zone, l'origine sera définie au milieu d'un pixel. La citation suivante provient de GML dans la norme JPEG2000:
Remarque: GMLJP2 suit la définition des grilles dans GML 3.2.1 [OGC 07-036] clause 19.2.2: «Lorsqu'un point de grille est utilisé pour représenter un espace échantillon (par exemple pixel d'image), le point de grille représente le centre de la espace d'échantillon (voir ISO 19123: 2005, 8.2.2) ». Cela correspond à la valeur pixelInCell d'ImageCRS définie sur CellCenter comme spécifié dans ISO 19111. Cela peut être interprété comme l'origine du RectifiedGrid est le point central du pixel d'angle.
Pour que les choses ne semblent pas trop simples, certains programmes comme ERDAS imagine (AFAIK) suivent en interne le schéma pixel par point ainsi que MapServer jusqu'à la prochaine version 7.0, en essayant de changer à la volée en le schéma pixel-is-area. Pour en savoir plus: http://mapserver.org/fr/development/rfc/ms-rfc-107.html .
Pour une meilleure interopérabilité, je recommanderais d'utiliser pixel-is-area et GeoTIFF pour tous les rasters naturels (images aériennes et satellites, cartes topographiques). Il s'agit d'une combinaison bien connue et donc fiable. Si vous jouez avec des DEM et d'autres données de mesure / capteur et qu'un décalage d'un demi-pixel peut être significatif, sachez qu'ils peuvent être étiquetés pixel par point et que différents programmes peuvent ou non introduire les décalages d'un demi-pixel.
Metadata: AREA_OR_POINT=Area
.Les deux sont courants et aucun ne peut être considéré comme entièrement standard.
Pour GeoTIFF, les deux sont possibles - voir Section 2.5.2.2 pour le
GTRasterTypeGeoKey
qui décrit la méthode d'interprétation. La FAQ GeoTIFF suggère d' utiliser la valeur par défaut (PixelIsArea
) de cette balise pour la compatibilité avec les anciennes versions de GDAL.Le format de fichier mondial utilise le centre du pixel.
Le découpage d'image à partir de NITF (à l'aide de l'extension ICHIPB) code explicitement la position du premier pixel de l'image découpée (sous-ensemble) en tant que coordonnée (0,5. 0,5), et la mappe à une coordonnée spécifique dans l'image parent (sur-ensemble), par exemple ( 2,5, 1,5).
la source
Je ne sais pas s'il existe une convention, mais les coordonnées sur les images se réfèrent normalement aux centres de pixels. Cela peut différer dans le cas de rasters produits à partir, par exemple, de modèles informatiques.
Si vous n'êtes pas sûr, vous pouvez utiliser GMT , les outils de mappage génériques, pour tester vos rasters et les convertir en un format approprié, car il offre explicitement la possibilité de spécifier l'enregistrement de la grille ou du nœud. Voir cette section du tutoriel, ainsi que le manuel de la fonction grdedit .
la source