Le pilote NITF (National Imagery Transmission Format) dans GDAL inclue un nombre d'options avancée et plus ou moins ésotérique ne convient pas à la documentation générale de l'utilisation pour le pilote. Cette information est collecté ici et est surtout utilisable pour les développeurs et les utilisateurs avancés.

Les fichiers NITF qui ont des données CGM (qui sont un segment d etype GR - graphique, ou SY avec un STYPE de valeur 'C') rendront cette information disponible comme méta-données dans le domaine CGM. Les méta-données renvoyés ressemblera à cela :

SEGMENT_COUNT=1
SEGMENT_0_SLOC_ROW=00025
SEGMENT_0_SLOC_COL=00025
SEGMENT_0_DATA=\0!\0...

Les valeurs ROW et COL sont l'emplacement de l'objet CGM relatif à l'image de base. DATA est les données brutes CGM avec une protection par des \ appliquées.Toutes les occurrence de zéro ASCII sera traduit en “\0”, et tous les symboles \ et “ seront protégés avec \. La fonction CPLUnescapeString() peut être utilisé pour protégé les données avec / en format binaire en utilisant le schéma CPLES_BackslashQuotable.

Les fichiers NITF avec plus d'un segment d'image (IM) présentera les segments d'image comme des sous jeux de données. L'ouverture de multiple fichiers NITF par noms de fichier fournira un accès au premier segment d'image. Les méta-données des sous jeux de données pour les trois fichiers NITF images ressemblera à cela :

Subdatasets:
  SUBDATASET_1_NAME=NITF_IM:0:multi_image_jpeg_2.0.ntf
  SUBDATASET_1_DESC=Image 1 of multi_image_jpeg_2.0.ntf
  SUBDATASET_2_NAME=NITF_IM:1:multi_image_jpeg_2.0.ntf
  SUBDATASET_2_DESC=Image 2 of multi_image_jpeg_2.0.ntf
  SUBDATASET_3_NAME=NITF_IM:2:multi_image_jpeg_2.0.ntf
  SUBDATASET_3_DESC=Image 3 of multi_image_jpeg_2.0.ntf

Dans ce cas l'ouverture de multi_image_jpeg_2.0.ntf directement donnera un accès à NITF_IM:0:multi_image_jpeg_2.0.ntf. Pour ouvrir les autres utilisez les noms des sous jeux de données correspondant. Le mécanisme de sous jeu de données est un concept GDAL générique discuté dans le document Modèle de données.

Les fichiers NITF qui ont des segments textes (qui est un segment de type TX) rendra cette information disponible comme méta-données dans le domaine TEXT. La méta-données renvoyée ressemblera à :

DATA_0=This is test text file 01.

DATA_1=This is test text file 02.

DATA_2=This is test text file 03.

DATA_3=This is test text file 04.

DATA_4=This is test text file 05.

Actuellement aucune données d'en-tête de segment TEXT n'est préservé. L'argument à DATA_n est le texte brute du n ^ième (à partir de 0) segment texte avec aucune protection de quelque forme que ce soit appliquée.

La méthode CreateCopy() sur le pilote NITF gère également la création de segments texte sur le fichier de sortie aussi longtemps que le fichier en entré possède des méta-données dans le domaine TEXT comme définie ci-dessus.

Les fichiers NITF avec des extensions enregistrées (ou non enregistrées ?) sur l'en-tête du fichier, ou l'en-tête de l'image géoréférencée les rendront disponible sous une forme brute dans les méta-données via le domaine TRE. Le domaine TRE contiendra une méta-données par TRE qui aura le nom du TRE comme nom, et la données du TRE comme contenu. La donnée contenue sera protégé par \ comme les données CGM ci-dessus.

Metadata (TRE):
  GEOPSB=MAPM  World Geodetic System 1984                                       
               WGE World Geodetic System 1984                                   
                   WE Geodetic                                                  
                      GEODMean Sea                                              
                          MSL 000000000000000                                   
                                                0000
  PRJPSB=Polar Stereographic                                                    
         PG2-00090.00000250000039.99999884000000000000000000000000000000
  MAPLOB=M  0598005958-000003067885.8-000002163353.8

— Yves Jacolin 2009/03/14 16:17 (trunk 15339)