On Fri, 3 Apr 2020 at 12:11, Nyall Dawson wrote:
>
> On Thu, 2 Apr 2020 at 22:58, Even Rouault wrote:
>
> > Thanks for your thoughts. I've taken an intermediate approach between my
> > initial thoughts and your suggestion, which I hope should be a reasonable
> > default behaviour
> >
> >
> >
>
On Thu, 2 Apr 2020 at 22:58, Even Rouault wrote:
> Thanks for your thoughts. I've taken an intermediate approach between my
> initial thoughts and your suggestion, which I hope should be a reasonable
> default behaviour
>
>
>
> Implemented per https://github.com/OSGeo/gdal/pull/2370:
Just want
Especially as I haven't seen a descriptive document for them yet.
From: Brad Hards
Sent: Thursday, April 2, 2020 12:00 PM
To: Edson, Adam Robert ; gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Accessing DES in NITF through GDAL
I think there could be value i
I think there could be value in adding CSSHPB with new code inside GDAL
NITF. See
https://github.com/OSGeo/gdal/blob/master/gdal/frmts/nitf/nitfdes.c#L209
Do GLAS/GFM later.
Brad
From: gdal-dev On Behalf Of Edson, Adam
Robert
Sent: Friday, 3 April 2020 2:53 AM
To: Even Rouault ; gdal-d
On jeudi 2 avril 2020 15:53:18 CEST Edson, Adam Robert wrote:
> I have been tasked with making GDAL capable of dealing with a new NITF
type
> (https://calval.cr.usgs.gov/apps/sites/default/files/jacie/BarbaraEckstein.
> pdf) that has major buy-in from data providers. Due to the ubiquity of GDAL,
>
I have been tasked with making GDAL capable of dealing with a new NITF type
(https://calval.cr.usgs.gov/apps/sites/default/files/jacie/BarbaraEckstein.pdf)
that has major buy-in from data providers. Due to the ubiquity of GDAL, making
the change at this level will give the most people access.
Th
Adam,
> I am working with NITF data. How are Data Extension Segments (DES) accessed
> through GDAL?
Complicated topic.
TRE stored in DES are reported in the TRE and xml:TRE metadata domains.
For generic DES extraction, you need to build GDAL with the ESRI_BUILD macro
enabled, and then they sho
I am working with NITF data. How are Data Extension Segments (DES) accessed
through GDAL?
Thanks!
Adam
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Greg,
> Matching and skipping also feels fragile, rather than not using and
> having people that want to use them have to be explicit.
Thanks for your thoughts. I've taken an intermediate approach between my
initial thoughts
and your suggestion, which I hope should be a reasonable default behav
Even,
Thanks for your prompt fix and for the workaround!
Guillaume
On Thu, Apr 2, 2020 at 12:39 PM Even Rouault
wrote:
> Guillaume,
>
>
>
> It was a bug. Fix pushed.
>
>
>
> You can workaround it by adding
>
>
>
>
>
>
>
> as a child element of
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospati
Guillaume,
It was a bug. Fix pushed.
You can workaround it by adding
as a child element of
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/m
Hello,
I'm posting this here instead of Github as I don't know if it is a bug or
my misuse of the VRT format in conjunction with gdal_translate.
When I create a VRT (v.vrt) with a SimpleSource pointing to a simple 20x20
pixels TIFF file and I do:
gdal_translate v.vrt t.tif
I get a black image at
12 matches
Mail list logo
