Selon Nicolas G <nicolas.g-...@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: a...@t-kartor.se > To: even.roua...@mines-paris.org; nicolas.g-...@outlook.fr > CC: gdal-dev@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-...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
