[gdal-dev] Retrieving Sub Datasets from an RPF's A.TOC file

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Retrieving Sub Datasets from an RPF's A.TOC file

Miller, Doug
When retrieving a sub dataset from GDAL using GDALOpen() and expressing the file path as  "NITF_TOC_ENTRY:CADRG_TLM50_50K_2_18:C:/rpf/a.toc "  there is a considerable delay.  This delay is acceptable if the RFP's coverage is for the United States, but if the coverage is for the world then it becomes a problem.

Is there a different way that I should be working with RPF (CADRG) within the GDAL framework or should I move on to something like OSSIM?

Thanks for any help you can give,

Doug
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving Sub Datasets from an RPF's A.TOC file

Even Rouault-2
Doug,

you might try defining the RPFTOC_FORCE_RGBA envirnoment variable/config option
to YES. This should avoid GDALOpen'ing all the tiles at dataset creation.
However the presence of all tiles will be checked via a 'stat' call, which can
still be a potential bottleneck. That could probably be disabled with some
code changes (the code would then assume that all declared tiles are
effectively present on the disk).

Even

> When retrieving a sub dataset from GDAL using GDALOpen() and expressing the
> file path as  "NITF_TOC_ENTRY:CADRG_TLM50_50K_2_18:C:/rpf/a.toc "  there
> is a considerable delay.  This delay is acceptable if the RFP's coverage
> is for the United States, but if the coverage is for the world then it
> becomes a problem.
>
> Is there a different way that I should be working with RPF (CADRG) within
> the GDAL framework or should I move on to something like OSSIM?
>
> Thanks for any help you can give,
>
> Doug
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving Sub Datasets from an RPF's A.TOC file

Even Rouault-2
Le lundi 26 octobre 2015 19:11:02, Miller, Doug a écrit :
> Even,
>
> Thanks for the response.  How is that set programmatically?  Is it with
> CPLSetConfigOption?

Yes

>
> Thanks,
>
> Doug
> ________________________________________
> From: Even Rouault <[hidden email]>
> Sent: Monday, October 26, 2015 1:28 PM
> To: [hidden email]
> Cc: Miller, Doug
> Subject: Re: [gdal-dev] Retrieving Sub Datasets from an RPF's A.TOC file
>
> Doug,
>
> you might try defining the RPFTOC_FORCE_RGBA envirnoment variable/config
> option to YES. This should avoid GDALOpen'ing all the tiles at dataset
> creation. However the presence of all tiles will be checked via a 'stat'
> call, which can still be a potential bottleneck. That could probably be
> disabled with some code changes (the code would then assume that all
> declared tiles are effectively present on the disk).
>
> Even
>
> > When retrieving a sub dataset from GDAL using GDALOpen() and expressing
> > the file path as  "NITF_TOC_ENTRY:CADRG_TLM50_50K_2_18:C:/rpf/a.toc "
> > there is a considerable delay.  This delay is acceptable if the RFP's
> > coverage is for the United States, but if the coverage is for the world
> > then it becomes a problem.
> >
> > Is there a different way that I should be working with RPF (CADRG) within
> > the GDAL framework or should I move on to something like OSSIM?
> >
> > Thanks for any help you can give,
> >
> > Doug
> > _______________________________________________
> > gdal-dev mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev