Opened 14 years ago
Closed 14 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 |
Cc: |
Description
DTED:
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.
CIB/CADRG:
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)
Change History (14)
comment:1 by , 14 years ago
Keywords: | dted cadrg added |
---|---|
Milestone: | 1.6.4 → 1.8.0 |
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 14 years ago
comment:4 by , 14 years ago
comment:5 by , 14 years ago
Keywords: | rpftoc added |
---|
Digging into the RPFTOC driver to see how to add the CADRG metadata.
comment:6 by , 14 years ago
Keywords: | nitf added |
---|
In trunk I have added capture of dates from the RPF attribute section of NITF files:
NITF_RPF_CurrencyDate=19950816 NITF_RPF_ProductionDate=19950816 NITF_RPF_SignificantDate=19911105
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 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 by , 14 years ago
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.
by , 14 years ago
Attachment: | 00004013.GN2 added |
---|
comment:10 by , 14 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
by , 14 years ago
Attachment: | Irwin_GNC_RPF_header.png added |
---|
comment:11 by , 14 years ago
Driver: NITF/National Imagery Transmission Format Files: 00004013.GN2 Size is 1536, 1536 ... NITF_ICORDS=G NITF_IGEOLO=413218N1253937W413218N1120431W310913N1120431W310913N1253937W NITF_RPF_CurrencyDate=19940119 NITF_RPF_ProductionDate=19940119 NITF_RPF_SignificantDate=19890302 NITF_IC=C4
Gao,
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 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Frank, It turned out it's a date conversion problem on our side. Thanks for looking into this.
Gao,
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.