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

Mon Feb 10 08:35:56 PST 2014

Hi Even,

Thank you, in fact it seems clear according to your RPF Spec analysis that the A.TOC file is not corrcetly formatted.
The TOC file has been provided by Data producer...
As you say the solution is to define another boundary rectangle with the same coordinate, and it will be ok.

Thanks,

Nico

> Date: Mon, 10 Feb 2014 13:15:24 +0100
> From: even.rouault at mines-paris.org
> To: nicolas.g-dev at outlook.fr
> CC: ao at t-kartor.se; even.rouault at mines-paris.org; gdal-dev at lists.osgeo.org
> Subject: RE: [gdal-dev] TOC sub-dataset retrieving when frame with same coverage share the same boundary rectangle.
> 
> 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
> >
> >
> >
> >
> >
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140210/968a7d37/attachment.html>