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

[Nicolas G]

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.


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/3fe919d6/attachment-0001.html>