Opened 10 years ago

Closed 10 years ago

#3413 closed defect (fixed)

Add more DTED and CIB/CADRG metadata items

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone: 1.8.0
Component: GDAL_Raster Version: 1.6.1
Severity: normal Keywords: dted cadrg rpftoc nitf



1) Latitude of origin of data — leading zero for values less than 10; H is the hemisphere of the data.

2) Longitude of origin of data— leading zeroes for values less than 100; H is the hemisphere of the data.


The production date for CIB/CADRG.

The production date should be obtained from Production Date parameter that is stored within the "[attribute section]" of the RPF frame file header. According to the Mil-Std-2411-2 “Integration of Raster Product Format Files into the National Imagery Transmission Format” the rpf attribute section is contained within the DESDATA (nitf user-defined data extension group).

Attachments (2)

00004013.GN2 (287.3 KB) - added by gaopeng 10 years ago.
Irwin_GNC_RPF_header.png (21.7 KB) - added by gaopeng 10 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 10 years ago by warmerdam

Keywords: dted cadrg added
Owner: changed from Warmerdam to warmerdam
Status: newassigned

comment:2 Changed 10 years ago by warmerdam


I have added these metadata items as follows in my local tree. I kept the whole field from the DTED file rather than trimming the leading zero for latitudes. I did this mainly because there was apparently some confusion about the lat/long ordering in some versions of the specification.


If that is ok, I'll apply in svn. If you need the latitude trimmed by one, I'll do that.

comment:3 Changed 10 years ago by gaopeng

That is perfectly OK.


comment:4 Changed 10 years ago by warmerdam

The new DTED metadata is committed in trunk (r18970) and 1.6-esri (r18971).

comment:5 Changed 10 years ago by warmerdam

Keywords: rpftoc added

Digging into the RPFTOC driver to see how to add the CADRG metadata.

comment:6 Changed 10 years ago by warmerdam

Keywords: nitf added

In trunk I have added capture of dates from the RPF attribute section of NITF files:


However, for products read via the RPFTOC driver this doesn't actually come through to the application since the individual tiles are abstracted behind a higher level interface. I will investigate if the a.toc file has similar metadata...

comment:7 Changed 10 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

A quick investigation indicates that A.TOC files used by the RPFTOC driver do *not* have RPF attribute sections, so there is no sort of aggregate production date available by this mechanism for the whole product. Individual tiles must be accessed to get this metadata.

The change is backported into 1.6-esri (r18792).

comment:8 Changed 10 years ago by Even Rouault

Frank, here's a dirty hack added in trunk in r18803 : Enable reading RPF attribute table in quite common, but odd, cases where its reported size isn't reliable (#3413). Tested in r18804. Not sure if it is expected by the specification, but was necessary on a non neglectable percentage of CADRG products I have access to. Might be a producer error.

comment:9 Changed 10 years ago by warmerdam

Backported Even's change into 1.6-esri (r18806).

Changed 10 years ago by gaopeng

Attachment: 00004013.GN2 added

comment:10 Changed 10 years ago by gaopeng

Resolution: fixed
Status: closedreopened

I reopen this ticket again with a new test case.

If I load the attached RPF frame using GDAL, the ProductionDate? (ProdDate?) field is populated with the date value 11/1/1994.

If I examine the Production Date value store in the RPF header using the NIMAMUSE software, I find that the value is 19940119 (1/19/1994).

I have attached a test image and screenshot of the applicable header area as shown by NIMAMUSE software with production date circled.

Changed 10 years ago by gaopeng

Attachment: Irwin_GNC_RPF_header.png added

comment:11 Changed 10 years ago by warmerdam

Driver: NITF/National Imagery Transmission Format
Files: 00004013.GN2
Size is 1536, 1536


I have run the 1.6-esri and trunk versions of gdalinfo against this file and GDAL seems to be reporting 19940119 as you desire. Where were you seeing 11/1/1994?

comment:12 Changed 10 years ago by gaopeng

Resolution: fixed
Status: reopenedclosed

Frank, It turned out it's a date conversion problem on our side. Thanks for looking into this.

Note: See TracTickets for help on using tickets.