[gdal-dev] TOC sub-dataset retrieving when frame with same coverage share the same boundary rectangle.

Mon Feb 10 04:15:24 PST 2014

Selon Nicolas G <nicolas.g-dev at outlook.fr>:

> Hi Andreas,
>
> The fact is that I can't use the GDAL API to get the different sub-datasets
> in this particular case, so can't make any combination of frames without
> going directly to all NITF frames as suggested by Even.
>
> Regarding your answer, maybe the meaning of Zone and Scale is not clear for
> me:
> Zone = Arc Zone?Scale = Logical name (as in your example LFC, TFC...)? but
> not really the resolution.
>
> For me, the subdataset could be a directory in RPF directory tree, as each
> directory is generated according to different parameters.
>
>
> You normally have one directory (path) by [Arc Zone/Scale Logical Name (LFC,
> TFC...)] couple (I don't take into account the fact that a directory can be
> splitted if frames files are not contiguous).
>
> The problem appears when two [Arc Zone/Scale Logical Name (LFC, TFC...)]
> contain data at the same resolution, so with the same tiling, so potentially
> with frames at the same col/row.

I suspect your A.TOC is not correctly formatted, or in a uncommon way. For
frames attached to one given (Arc Zone, Scale Logical Name), called a "rectangle
boundary" in RPF spec, you
should not have 2 frames with same col/row.

According to
http://earth-info.nga.mil/publications/specs/printed/2411/2411_RPF.pdf page 20 :

"""b. Each boundary rectangle defined in the [boundary
rectangle section] of a [table of contents file] will act as a
logical container for a rectangular “virtualmatrix” of frames
(see 5.2.1 below). Individual frames may be referenced by their
(row, column) position within such a matrix."""

And then page 30 :
"(3) The [boundary rectangle section) will contain the
boundaries of one or more boundary rectangles, each defining the
periphery of a geographic area containing all of the [frame file]s
in the given data interchange volume that have a given data typet
compression ratio, producer, latitudinal zone, and scale (or
resolution). A given record will also specify the dimensions of a
rectangular “virtual matrix” of fixed-size frames of the given scale
or resolution that fills the given boundary rectangle"

Page 31:
"(4) The [frame file index section] will contain scales
and data types for all [frame file]s in the given volume. Each
entry will identify the boundary rectangle (named in the [boundary
rectangle section]) where the frame is located, and it will
specify the row and column in a “virtual matrix” of frames within
the boundary rectangle where the specific frame is located"

==> So this sounds pretty clear to me that you shouldn't have 2 frames within
the same boundary rectangle that have identical row,col
The solution would be to have 2 boundary rectangles (with same extent) and
attach one single frame to one of those boundary rectangles

Where does your A.TOC comes from : is it provided by a data producer, or your
own creation ?

>
>
> As you have written "There should be overlaps between the zones but this data
> content
>       "shall be identical". "
> So the following example is not really possible?
>
> Example:
> I have one boundary rectangle which belongs to two differents paths (but for
> the same coverage (same Arc zone)) by example a path with LFC-FR_(Night)
> content and a path with LFC-FR_(Day) content (all at the same resolution).
> For each frame coverage I have one frame in LFC-FR_(Night) path and one frame
> in LFC-FR_(Day) path (so different paths and frame names and extensions),
> then GDAL reports to me only one Sub-dataset, and then I can't access through
> GDAL Subdataset API the data in the two paths. I need to analyse the TOC file
> in my App to get the paths, boundaries... and then access the frame files.
>
> Nico
>
> Date: Mon, 10 Feb 2014 09:27:03 +0100
> From: ao at t-kartor.se
> To: even.rouault at mines-paris.org; nicolas.g-dev at outlook.fr
> CC: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] TOC sub-dataset retrieving when frame with same
> coverage share the same boundary rectangle.
>
>
>
>
>
>
>     Hi
>
>
>
>       A RPF structure (CADRG, CIB, ECRG etc) may include any combination
>       of scalelevels and/or geographic zones as referenced in the A.TOC
>       file. So there may be both scale-overlaps and zone-overlaps.
>
>       There is also a frame-based update concept but this is seldom
>       used.
>
>       An example from a CADRG dataset containing 14 subdatasets:
>
>
>       Corps du message
>
>       SUBDATASET_6_NAME=NITF_TOC_ENTRY:CADRG_TFC_250K_6_5:A.TOC
>
>       SUBDATASET_6_DESC=CADRG:TFC:Transit Flying Chart (UK):250K:6:5
>
>       SUBDATASET_7_NAME=NITF_TOC_ENTRY:CADRG_LFC-FR_(Day)_500K_1_6:A.TOC
>
>
>       SUBDATASET_7_DESC=CADRG:LFC-FR (Day):Low Flying Chart (Day) - Host
>       Nation:500K:1:6
>
>
>
>       This means that you must analyze the individual subdatasets to
>       extract/combine info for each scalelevel individually. To my
>       knowledge, there is no consistent naming principle in the standard
>       - so the scalelevels are just logical names in the A.TOC file.
>
>       There should be overlaps between the zones but this data content
>       "shall be identical".
>
>
>
>       Best Regards
>
>
>
>       Andreas Oxenstierna
>
>
>
>
>
>       Selon Nicolas G <nicolas.g-dev at outlook.fr>:
>
> hi
>
> yes you have well described the behaviour of the driver. The
> subdatasets match the boundary rectangles
> And it is very odd to have two frames with same col row
> coordinates for the same boundary rectangle.
> in your case you have to directly open the nitf tile instead
> of the a.toc
>
>
>
>         Hi,
>
>
>
> Iï¿œm using GDAL to get the CADRG database sub-dataset list.
>
>
> As an example (TOC file content):
>
> - Only one boundary rectangle defined in ï¿œboundary rectangle sectionï¿œ,
>
> - In ï¿œframe file index sectionï¿œ, I have two frames covering the same
> area (same resolution, ï¿œ, but different functional content),
>
> - These two frames are stored in different path but all referring to the
> same boundary rectangle.
>
>
> Then in that case, the message "Frame entry(%d,%d) for frame file index
> %d was already found." is raised by GDAL when loading the TOC file, and
> finally
> only one sub-dataset is given back to me(the first one of the TOC file) ->
> method ï¿œRPFTOCReadFromBuffer()ï¿œ of Rpftocfile.cpp.
>
>
> It seems that GDAL uses boundary rectangles and frame files to build the
> sub-dataset list and if, for a same boundary rectangle, two or more frames
> with
> the same coverage belong to different path
> then only one GDAL sub-dataset is created.
>
>
> Does someone can help me and explain me how to access the data of these
> two frames files (same coverage, same boundary rectangle but different path)
> through GDAL API?
>
>
> Or is there any development on this subject?
>
>
>
> Thanks,
>
>
>
> Nicolas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
>