<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi Even,<br><br>Thank you, in fact it seems clear according to your RPF Spec analysis that the A.TOC file is not corrcetly formatted.<br>The TOC file has been provided by Data producer...<br>As you say the solution is to define another boundary rectangle with the same coordinate, and it will be ok.<br><br>Thanks,<br><br>Nico<br><br><br><div>> Date: Mon, 10 Feb 2014 13:15:24 +0100<br>> From: even.rouault@mines-paris.org<br>> To: nicolas.g-dev@outlook.fr<br>> CC: ao@t-kartor.se; even.rouault@mines-paris.org; gdal-dev@lists.osgeo.org<br>> Subject: RE: [gdal-dev] TOC sub-dataset retrieving when frame with same coverage share the same boundary rectangle.<br>> <br>> Selon Nicolas G <nicolas.g-dev@outlook.fr>:<br>> <br>> > Hi Andreas,<br>> ><br>> > The fact is that I can't use the GDAL API to get the different sub-datasets<br>> > in this particular case, so can't make any combination of frames without<br>> > going directly to all NITF frames as suggested by Even.<br>> ><br>> > Regarding your answer, maybe the meaning of Zone and Scale is not clear for<br>> > me:<br>> > Zone = Arc Zone?Scale = Logical name (as in your example LFC, TFC...)? but<br>> > not really the resolution.<br>> ><br>> > For me, the subdataset could be a directory in RPF directory tree, as each<br>> > directory is generated according to different parameters.<br>> ><br>> ><br>> > You normally have one directory (path) by [Arc Zone/Scale Logical Name (LFC,<br>> > TFC...)] couple (I don't take into account the fact that a directory can be<br>> > splitted if frames files are not contiguous).<br>> ><br>> > The problem appears when two [Arc Zone/Scale Logical Name (LFC, TFC...)]<br>> > contain data at the same resolution, so with the same tiling, so potentially<br>> > with frames at the same col/row.<br>> <br>> I suspect your A.TOC is not correctly formatted, or in a uncommon way. For<br>> frames attached to one given (Arc Zone, Scale Logical Name), called a "rectangle<br>> boundary" in RPF spec, you<br>> should not have 2 frames with same col/row.<br>> <br>> According to<br>> http://earth-info.nga.mil/publications/specs/printed/2411/2411_RPF.pdf page 20 :<br>> <br>> """b. Each boundary rectangle defined in the [boundary<br>> rectangle section] of a [table of contents file] will act as a<br>> logical container for a rectangular “virtualmatrix” of frames<br>> (see 5.2.1 below). Individual frames may be referenced by their<br>> (row, column) position within such a matrix."""<br>> <br>> And then page 30 :<br>> "(3) The [boundary rectangle section) will contain the<br>> boundaries of one or more boundary rectangles, each defining the<br>> periphery of a geographic area containing all of the [frame file]s<br>> in the given data interchange volume that have a given data typet<br>> compression ratio, producer, latitudinal zone, and scale (or<br>> resolution). A given record will also specify the dimensions of a<br>> rectangular “virtual matrix” of fixed-size frames of the given scale<br>> or resolution that fills the given boundary rectangle"<br>> <br>> Page 31:<br>> "(4) The [frame file index section] will contain scales<br>> and data types for all [frame file]s in the given volume. Each<br>> entry will identify the boundary rectangle (named in the [boundary<br>> rectangle section]) where the frame is located, and it will<br>> specify the row and column in a “virtual matrix” of frames within<br>> the boundary rectangle where the specific frame is located"<br>> <br>> ==> So this sounds pretty clear to me that you shouldn't have 2 frames within<br>> the same boundary rectangle that have identical row,col<br>> The solution would be to have 2 boundary rectangles (with same extent) and<br>> attach one single frame to one of those boundary rectangles<br>> <br>> Where does your A.TOC comes from : is it provided by a data producer, or your<br>> own creation ?<br>> <br>> <br>> ><br>> ><br>> > As you have written "There should be overlaps between the zones but this data<br>> > content<br>> > "shall be identical". "<br>> > So the following example is not really possible?<br>> ><br>> > Example:<br>> > I have one boundary rectangle which belongs to two differents paths (but for<br>> > the same coverage (same Arc zone)) by example a path with LFC-FR_(Night)<br>> > content and a path with LFC-FR_(Day) content (all at the same resolution).<br>> > For each frame coverage I have one frame in LFC-FR_(Night) path and one frame<br>> > in LFC-FR_(Day) path (so different paths and frame names and extensions),<br>> > then GDAL reports to me only one Sub-dataset, and then I can't access through<br>> > GDAL Subdataset API the data in the two paths. I need to analyse the TOC file<br>> > in my App to get the paths, boundaries... and then access the frame files.<br>> ><br>> > Nico<br>> ><br>> > Date: Mon, 10 Feb 2014 09:27:03 +0100<br>> > From: ao@t-kartor.se<br>> > To: even.rouault@mines-paris.org; nicolas.g-dev@outlook.fr<br>> > CC: gdal-dev@lists.osgeo.org<br>> > Subject: Re: [gdal-dev] TOC sub-dataset retrieving when frame with same<br>> > coverage share the same boundary rectangle.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> > Hi<br>> ><br>> ><br>> ><br>> > A RPF structure (CADRG, CIB, ECRG etc) may include any combination<br>> > of scalelevels and/or geographic zones as referenced in the A.TOC<br>> > file. So there may be both scale-overlaps and zone-overlaps.<br>> ><br>> > There is also a frame-based update concept but this is seldom<br>> > used.<br>> ><br>> > An example from a CADRG dataset containing 14 subdatasets:<br>> ><br>> ><br>> > Corps du message<br>> ><br>> > SUBDATASET_6_NAME=NITF_TOC_ENTRY:CADRG_TFC_250K_6_5:A.TOC<br>> ><br>> > SUBDATASET_6_DESC=CADRG:TFC:Transit Flying Chart (UK):250K:6:5<br>> ><br>> > SUBDATASET_7_NAME=NITF_TOC_ENTRY:CADRG_LFC-FR_(Day)_500K_1_6:A.TOC<br>> ><br>> ><br>> > SUBDATASET_7_DESC=CADRG:LFC-FR (Day):Low Flying Chart (Day) - Host<br>> > Nation:500K:1:6<br>> ><br>> ><br>> ><br>> > This means that you must analyze the individual subdatasets to<br>> > extract/combine info for each scalelevel individually. To my<br>> > knowledge, there is no consistent naming principle in the standard<br>> > - so the scalelevels are just logical names in the A.TOC file.<br>> ><br>> > There should be overlaps between the zones but this data content<br>> > "shall be identical".<br>> ><br>> ><br>> ><br>> > Best Regards<br>> ><br>> ><br>> ><br>> > Andreas Oxenstierna<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > Selon Nicolas G <nicolas.g-dev@outlook.fr>:<br>> ><br>> > hi<br>> ><br>> > yes you have well described the behaviour of the driver. The<br>> > subdatasets match the boundary rectangles<br>> > And it is very odd to have two frames with same col row<br>> > coordinates for the same boundary rectangle.<br>> > in your case you have to directly open the nitf tile instead<br>> > of the a.toc<br>> ><br>> ><br>> ><br>> > Hi,<br>> ><br>> ><br>> ><br>> > I�m using GDAL to get the CADRG database sub-dataset list.<br>> ><br>> ><br>> > As an example (TOC file content):<br>> ><br>> > - Only one boundary rectangle defined in �boundary rectangle section�,<br>> ><br>> > - In �frame file index section�, I have two frames covering the same<br>> > area (same resolution, �, but different functional content),<br>> ><br>> > - These two frames are stored in different path but all referring to the<br>> > same boundary rectangle.<br>> ><br>> ><br>> > Then in that case, the message "Frame entry(%d,%d) for frame file index<br>> > %d was already found." is raised by GDAL when loading the TOC file, and<br>> > finally<br>> > only one sub-dataset is given back to me(the first one of the TOC file) -><br>> > method �RPFTOCReadFromBuffer()� of Rpftocfile.cpp.<br>> ><br>> ><br>> > It seems that GDAL uses boundary rectangles and frame files to build the<br>> > sub-dataset list and if, for a same boundary rectangle, two or more frames<br>> > with<br>> > the same coverage belong to different path<br>> > then only one GDAL sub-dataset is created.<br>> ><br>> ><br>> > Does someone can help me and explain me how to access the data of these<br>> > two frames files (same coverage, same boundary rectangle but different path)<br>> > through GDAL API?<br>> ><br>> ><br>> > Or is there any development on this subject?<br>> ><br>> ><br>> ><br>> > Thanks,<br>> ><br>> ><br>> ><br>> > Nicolas<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________<br>> > gdal-dev mailing list<br>> > gdal-dev@lists.osgeo.org<br>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev<br>> ><br>> ><br>> ><br>> ><br>> ><br>> <br>> <br></div></div>
</div></body>
</html>