<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi<br>
<br>
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. <br>
There is also a frame-based update concept but this is seldom
used.<br>
An example from a CADRG dataset containing 14 subdatasets:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<title></title>
<meta name="generator" content="LibreOffice 4.2.0.4 (MacOSX)">
<style type="text/css">
<!--
@page { margin: 2cm }
p { margin-bottom: 0.25cm; direction: ltr; color: #000000; line-height: 120%; widows: 0; orphans: 0 }
p.western { font-family: "Liberation Serif", "Times New Roman", serif; font-size: 12pt; so-language: sv-SE }
p.cjk { font-family: "Arial Unicode MS", sans-serif; font-size: 12pt; so-language: zh-CN }
p.ctl { font-family: "Arial Unicode MS", sans-serif; font-size: 12pt; so-language: hi-IN }
a:link { so-language: zxx }
-->
</style>SUBDATASET_6_NAME=NITF_TOC_ENTRY:CADRG_TFC_250K_6_5:A.TOC <br>
SUBDATASET_6_DESC=CADRG:TFC:Transit Flying Chart (UK):250K:6:5 <br>
SUBDATASET_7_NAME=NITF_TOC_ENTRY:CADRG_LFC-FR_(Day)_500K_1_6:A.TOC
<br>
SUBDATASET_7_DESC=CADRG:LFC-FR (Day):Low Flying Chart (Day) - Host
Nation:500K:1:6 <br>
<br>
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.<br>
There should be overlaps between the zones but this data content
"shall be identical". <br>
<br>
Best Regards<br>
<br>
Andreas Oxenstierna<br>
<br>
</div>
<blockquote cite="mid:1391786061.52f4f84ddf19c@imp.free.fr"
type="cite">
<pre wrap="">Selon Nicolas G <a class="moz-txt-link-rfc2396E" href="mailto:nicolas.g-dev@outlook.fr"><nicolas.g-dev@outlook.fr></a>:
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
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
<br>
</body>
</html>