Re: [gdal-dev] [Geotiff] libgeotiff 1.7.2 release candidate

[Even Rouault via gdal-dev]

oops. Here are the corrected URLs:

https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.tar.gz
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.zip

Le 21/05/2024 à 15:44, Greg Troxel via Geotiff a écrit :

Even Rouault via Geotiff  writes:


do you mean

https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.tar.gz

assuming yes builds and passes tests on NetBSD 10 amd64.
___
Geotiff mailing list
geot...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geotiff


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff with ColorInterp=Palette

[Even Rouault via gdal-dev]

Le 20/02/2024 à 11:15, Elena Ruiz via gdal-dev a écrit :
Hello, I have version 3.6.2 of GDAL and I need to crop an image using 
a contour from a GML file, so far there is no problem.


The problem begins when the original image is a GEOTIFF with 
transparency and it generates a cropped image, the information of both 
images is a little lower.


The color table changes from having 2 values to having 256, this 
causes it to lose transparency although it has the label "Mask Flags: 
PER_DATASET ALPHA" which indicates that it has an alpha channel.


My question is, why does the color table change?, and is there any 
parameter that can be used with gdalwarp or gdal_translate to avoid 
this and keep the image transparent?


Strictly speaking your input image has no transparency, just black & 
white colors. Not sure which one you interpret as transparent?



You could force a 1-bit output image (ie with a color palette of 2 
colors) by adding -co NBITS=1 . But that will likely won't play well 
with -dstalpha.  You'd then want to use instead -dstnodata 0 if black is 
the transparent color or -dstnodata 1 if white is the transparent color



Even

--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff with ColorInterp=Palette

[Elena Ruiz via gdal-dev]

Hello, I have version 3.6.2 of GDAL and I need to crop an image using a contour 
from a GML file, so far there is no problem.

The problem begins when the original image is a GEOTIFF with transparency and 
it generates a cropped image, the information of both images is a little lower.

The color table changes from having 2 values to having 256, this causes it to 
lose transparency although it has the label "Mask Flags: PER_DATASET ALPHA" 
which indicates that it has an alpha channel.

My question is, why does the color table change?, and is there any parameter 
that can be used with gdalwarp or gdal_translate to avoid this and keep the 
image transparent?



I use this command:

gdalwarp.exe -cutline fichero.gml -crop_to_cutline -dstalpha ficheroIN 
ficheroOUT --config GDAL_DATA rutaGDAL


ORIGINAL IMAGE

Driver: GTiff/GeoTIFF

Size is 5616, 3655

…

Metadata:

  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)

  TIFFTAG_XRESOLUTION=300

  TIFFTAG_YRESOLUTION=300

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

…

Band 1 Block=5616x1493 Type=Byte, ColorInterp=Palette

  Image Structure Metadata:

NBITS=1

  Color Table (RGB with 2 entries)

0: 0,0,0,255

1: 255,255,255,255



CROPPED IMAGE

Driver: GTiff/GeoTIFF

Size is 5605, 2689

….

Metadata:

  TIFFTAG_DATETIME=2024:02:09 08:49:12

  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)

  TIFFTAG_SOFTWARE=Microsoft Windows Photo Viewer 10.0.19041.1

  TIFFTAG_XRESOLUTION=300

  TIFFTAG_YRESOLUTION=300

Image Structure Metadata:

  COMPRESSION=LZW

  INTERLEAVE=PIXEL

Corner Coordinates:

….

Band 1 Block=5605x1 Type=Byte, ColorInterp=Palette

  Mask Flags: PER_DATASET ALPHA

  Color Table (RGB with 256 entries)

0: 0,0,0,255

1: 255,255,255,255

2: 0,0,0,255

3: 0,0,0,255

….

  252: 0,0,0,255

  253: 0,0,0,255

  254: 0,0,0,255

  255: 0,0,0,255



I await your response, thank you and regards.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

[thomas bonfort via gdal-dev]

JXL in tiff should support the 2 band case correctly. What is not supported
here is the int16 datatype. Only uint8, uint16 and float32 are supported.

TB

On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev  wrote:

> We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL
> compression.  However for each band the following error message is given
> “ERROR 1: GetJXLDataType:Unsupported combination of SampleFormat and
> BitsPerSample”.
>
>
>
> On GDAL 3.8.3, released 2024/01/04.  JXL v0.9.2
>
>
>
> gdal_translate -ot int16 -co "COMPRESS=JXL" -co "NUM_THREADS=8" -co
> "TILED=YES" -co "SPARSE_OK=YES" -
>
> co "INTERLEAVE=BAND" -co "JXL_LOSSLESS=YES" in.tif out_JXL.tif
>
>
>
> The docs state an encode limitation for GDAL < 3.6 wrt interleave and band
> counts.  We’re not subject to that, unless there’s a bug, but I do wonder
> if we have nonetheless gone off the support path with band interleave with
> 2 bands?
>
>
>
> Jesse
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

[thomas bonfort via gdal-dev]

could you share the output of "gdalinfo in.tif" please?

On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev  wrote:

> We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL
> compression.  However for each band the following error message is given
> “ERROR 1: GetJXLDataType:Unsupported combination of SampleFormat and
> BitsPerSample”.
>
>
>
> On GDAL 3.8.3, released 2024/01/04.  JXL v0.9.2
>
>
>
> gdal_translate -ot int16 -co "COMPRESS=JXL" -co "NUM_THREADS=8" -co
> "TILED=YES" -co "SPARSE_OK=YES" -
>
> co "INTERLEAVE=BAND" -co "JXL_LOSSLESS=YES" in.tif out_JXL.tif
>
>
>
> The docs state an encode limitation for GDAL < 3.6 wrt interleave and band
> counts.  We’re not subject to that, unless there’s a bug, but I do wonder
> if we have nonetheless gone off the support path with band interleave with
> 2 bands?
>
>
>
> Jesse
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

[Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via gdal-dev]

We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL 
compression.  However for each band the following error message is given “ERROR 
1: GetJXLDataType:Unsupported combination of SampleFormat and BitsPerSample”.

On GDAL 3.8.3, released 2024/01/04.  JXL v0.9.2

gdal_translate -ot int16 -co "COMPRESS=JXL" -co "NUM_THREADS=8" -co "TILED=YES" 
-co "SPARSE_OK=YES" -
co "INTERLEAVE=BAND" -co "JXL_LOSSLESS=YES" in.tif out_JXL.tif

The docs state an encode limitation for GDAL < 3.6 wrt interleave and band 
counts.  We’re not subject to that, unless there’s a bug, but I do wonder if we 
have nonetheless gone off the support path with band interleave with 2 bands?

Jesse
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

On Thu, Sep 21, 2023, at 18:05, Even Rouault wrote:
> 
>> Of course, but I'm asking if it's worth calling ReadBlock on multiple 
>> threads (if it always takes a lock, it's not, and I should use RasterIO 
>> instead).
> Not on the same dataset object, otherwise you'll get crashes as no lock is 
> taken
I've filed https://github.com/OSGeo/gdal/issues/8448 for this. Even if 
rejected, it will serve as documentation for other people who want this.___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Even Rouault via gdal-dev]

Of course, but I'm asking if it's worth calling ReadBlock on multiple 
threads (if it always takes a lock, it's not, and I should use 
RasterIO instead).
Not on the same dataset object, otherwise you'll get crashes as no lock 
is taken


(*) I think these can also be implemented at VSI level by wrapping a 
file handle and turning Seek + Read into a PRead (when supported), 
even for drivers that don't explicitly support PRead.


The multi-threaded optimization also works for VSI file systems not 
supported PRead(), but doing what you mention above: doing Seek+Read 
under a lock. This is of course less efficient.


I meant something slightly different here: if a file supports PRead, 
but a driver doesn't (maybe it's using some external library like 
libtiff, which has _tiffReadProc and _tiffSeekProc), threading could 
still be supported with a hack. The driver could ask the library to 
open the same file multiple times, wrapping the same VSI handle, but 
passing in a seekProc that only keeps track of the current offset. So 
the library could seek and read as it pleases, but GDAL would turn 
those into PRead calls. The backing file handle would never see a 
seek, just PRead.


Ah I see what you mean. Having generic multi-threading isn't possible. 
Each driver would have to be modified to be ready to cope with that. 
Besides file handles, there are often other state variables at the 
GDALDataset/GDALRasterBand level.




Laurentiu


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

Hi,

On Thu, Sep 21, 2023, at 17:02, Even Rouault wrote:
> Laurentiu,
> 
>> 
>> GDAL 3.6 added support for multi-threaded reading using PRead, but I 
>> couldn't spot ReadBlock using the same code path.
> If you read one single block at a time, the multi-threaded optimization 
> cannot kick in, since the elementary decoding unit is a block. You must call 
> RasterIO() with a window intersecting several block.
> 
Of course, but I'm asking if it's worth calling ReadBlock on multiple threads 
(if it always takes a lock, it's not, and I should use RasterIO instead).
>> 
>> (*) I think these can also be implemented at VSI level by wrapping a file 
>> handle and turning Seek + Read into a PRead (when supported), even for 
>> drivers that don't explicitly support PRead.
> The multi-threaded optimization also works for VSI file systems not supported 
> PRead(), but doing what you mention above: doing Seek+Read under a lock. This 
> is of course less efficient.
> 
I meant something slightly different here: if a file supports PRead, but a 
driver doesn't (maybe it's using some external library like libtiff, which has 
_tiffReadProc and _tiffSeekProc), threading could still be supported with a 
hack. The driver could ask the library to open the same file multiple times, 
wrapping the same VSI handle, but passing in a seekProc that only keeps track 
of the current offset. So the library could seek and read as it pleases, but 
GDAL would turn those into PRead calls. The backing file handle would never see 
a seek, just PRead.

Laurentiu___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Even Rouault via gdal-dev]

Laurentiu,



GDAL 3.6 added support for multi-threaded reading using PRead, but I 
couldn't spot ReadBlock using the same code path.


If you read one single block at a time, the multi-threaded optimization 
cannot kick in, since the elementary decoding unit is a block. You must 
call RasterIO() with a window intersecting several block.




(*) I think these can also be implemented at VSI level by wrapping a 
file handle and turning Seek + Read into a PRead (when supported), 
even for drivers that don't explicitly support PRead.


The multi-threaded optimization also works for VSI file systems not 
supported PRead(), but doing what you mention above: doing Seek+Read 
under a lock. This is of course less efficient.


Even


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

Hello,

GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't 
spot ReadBlock using the same code path. On the other hand, I didn't see it 
taking a lock either, so I'm a little confused :-). My question is whether 
ReadBlock supports concurrent reads or not (*).

(*) I think these can also be implemented at VSI level by wrapping a file 
handle and turning Seek + Read into a PRead (when supported), even for drivers 
that don't explicitly support PRead.

Thanks,
Laurentiu___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

[Rahkonen Jukka (MML)]

Hi,

I think it is not bad luck but something weird in GDAL 3.3. I tried again with 
version 3.3.1 from OSGeo4W and just like you I got also less pixels into output:

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326_2.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18714P x 10830L.

But this warped image is not at all the same than the one produced with GDAL 
3.4. The image lacks all the legends etc. but not only those. I wonder is the 
TIFF file has been written in some special way on several pages or something.


-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 17.36
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] GeoTIFF gdalwarp puzzle

...And it works fine for me in 3.4.0 as well.  Guess I just got unlucky with 
the GDAL 3.3.x series!

Thanks,
carl

On Fri, Nov 5, 2021 at 8:09 AM Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
Partially answering myself:

I just tried again with GDAL 2.4.4 (2020/01/08) that I have on my system as 
part of MS4W and it works!

I have a way forward now.  I'm still going to build GDAL 3.4.0 and try it there.

Thanks a lot,

carl

On Fri, Nov 5, 2021 at 8:02 AM Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
Thanks for checking, Jukka.

I am using GDAL 3.3.3 and get a smaller range:

d:\gdal-3.3.3\bin64\gdalwarp.exe  -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" 
caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18714P x 10830L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

Is there a bug fix between 3.3.3 and 3.4.0 that could account for this?

Meanwhile, I'll try to get GDAL 3.4.0 going here.  Thanks,

carl

On Fri, Nov 5, 2021 at 7:51 AM Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the file.

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18583P x 12118L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

The map in caribbean_4326.tif is complete.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 16.25
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] GeoTIFF gdalwarp puzzle

Hi,

I'm working with some aviation charts and found one that behaves in a puzzling 
manner.
This page 
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
has two Caribbean VFR charts in GeoTIFF format.

I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I only 
ever get a small area out of the map instead of the whole extent.  Specifically 
this command gives me just a smaller area output GeoTIFF:

gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON

I don't see anything from the debug output that explains this.

The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way, though 
the debug output from the same gdalwarp operation is much longer.

I can't see anything wrong.

I dragged both files into ArcGIS desktop explorer and both are displayed in the 
proper location and in their entirety.

(I actually have a more elaborate workflow that works fine with chart #1 but 
this is the simplest operation I can think of that shows the problem with chart 
#2.)

Thank you very much,
carl


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

[Carl Godkin]

...And it works fine for me in 3.4.0 as well.  Guess I just got unlucky
with the GDAL 3.3.x series!

Thanks,
carl

On Fri, Nov 5, 2021 at 8:09 AM Carl Godkin  wrote:

> Partially answering myself:
>
> I just tried again with GDAL 2.4.4 (2020/01/08) that I have on my system
> as part of MS4W and it works!
>
> I have a way forward now.  I'm still going to build GDAL 3.4.0 and try it
> there.
>
> Thanks a lot,
>
> carl
>
> On Fri, Nov 5, 2021 at 8:02 AM Carl Godkin  wrote:
>
>> Thanks for checking, Jukka.
>>
>> I am using GDAL 3.3.3 and get a smaller range:
>>
>> d:\gdal-3.3.3\bin64\gdalwarp.exe  -t_srs epsg:4326 "Caribbean 2 VFR
>> Chart.tif" caribbean_4326.tif
>> Copying color table from Caribbean 2 VFR Chart.tif to new file.
>> Creating output file that is 18714P x 10830L.
>> Processing Caribbean 2 VFR Chart.tif [1/1] :
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>> Is there a bug fix between 3.3.3 and 3.4.0 that could account for this?
>>
>> Meanwhile, I'll try to get GDAL 3.4.0 going here.  Thanks,
>>
>> carl
>>
>> On Fri, Nov 5, 2021 at 7:51 AM Rahkonen Jukka (MML) <
>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of
>>> the file.
>>>
>>> gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
>>>
>>> Copying color table from Caribbean 2 VFR Chart.tif to new file.
>>>
>>> Creating output file that is 18583P x 12118L.
>>>
>>> Processing Caribbean 2 VFR Chart.tif [1/1] :
>>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>>
>>>
>>>
>>> The map in caribbean_4326.tif is complete.
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> *Lähettäjä:* gdal-dev  *Puolesta *Carl
>>> Godkin
>>> *Lähetetty:* perjantai 5. marraskuuta 2021 16.25
>>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>>> *Aihe:* [gdal-dev] GeoTIFF gdalwarp puzzle
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I'm working with some aviation charts and found one that behaves in a
>>> puzzling manner.
>>>
>>> This page
>>> https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
>>>
>>>
>>> has two Caribbean VFR charts in GeoTIFF format.
>>>
>>>
>>>
>>> I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I
>>> only ever get a small area out of the map instead of the whole extent.
>>> Specifically this command gives me just a smaller area output GeoTIFF:
>>>
>>>
>>>
>>> gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON
>>>
>>>
>>>
>>> I don't see anything from the debug output that explains this.
>>>
>>>
>>>
>>> The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way,
>>> though the debug output from the same gdalwarp operation is much longer.
>>>
>>>
>>>
>>> I can't see anything wrong.
>>>
>>>
>>>
>>> I dragged both files into ArcGIS desktop explorer and both are displayed
>>> in the proper location and in their entirety.
>>>
>>>
>>>
>>> (I actually have a more elaborate workflow that works fine with chart #1
>>> but this is the simplest operation I can think of that shows the problem
>>> with chart #2.)
>>>
>>>
>>>
>>> Thank you very much,
>>>
>>> carl
>>>
>>>
>>>
>>>
>>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

[Carl Godkin]

Partially answering myself:

I just tried again with GDAL 2.4.4 (2020/01/08) that I have on my system as
part of MS4W and it works!

I have a way forward now.  I'm still going to build GDAL 3.4.0 and try it
there.

Thanks a lot,

carl

On Fri, Nov 5, 2021 at 8:02 AM Carl Godkin  wrote:

> Thanks for checking, Jukka.
>
> I am using GDAL 3.3.3 and get a smaller range:
>
> d:\gdal-3.3.3\bin64\gdalwarp.exe  -t_srs epsg:4326 "Caribbean 2 VFR
> Chart.tif" caribbean_4326.tif
> Copying color table from Caribbean 2 VFR Chart.tif to new file.
> Creating output file that is 18714P x 10830L.
> Processing Caribbean 2 VFR Chart.tif [1/1] :
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> Is there a bug fix between 3.3.3 and 3.4.0 that could account for this?
>
> Meanwhile, I'll try to get GDAL 3.4.0 going here.  Thanks,
>
> carl
>
> On Fri, Nov 5, 2021 at 7:51 AM Rahkonen Jukka (MML) <
> jukka.rahko...@maanmittauslaitos.fi> wrote:
>
>> Hi,
>>
>>
>>
>> Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the
>> file.
>>
>> gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
>>
>> Copying color table from Caribbean 2 VFR Chart.tif to new file.
>>
>> Creating output file that is 18583P x 12118L.
>>
>> Processing Caribbean 2 VFR Chart.tif [1/1] :
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>>
>>
>> The map in caribbean_4326.tif is complete.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> *Lähettäjä:* gdal-dev  *Puolesta *Carl
>> Godkin
>> *Lähetetty:* perjantai 5. marraskuuta 2021 16.25
>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>> *Aihe:* [gdal-dev] GeoTIFF gdalwarp puzzle
>>
>>
>>
>> Hi,
>>
>>
>>
>> I'm working with some aviation charts and found one that behaves in a
>> puzzling manner.
>>
>> This page
>> https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
>>
>>
>> has two Caribbean VFR charts in GeoTIFF format.
>>
>>
>>
>> I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I
>> only ever get a small area out of the map instead of the whole extent.
>> Specifically this command gives me just a smaller area output GeoTIFF:
>>
>>
>>
>> gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON
>>
>>
>>
>> I don't see anything from the debug output that explains this.
>>
>>
>>
>> The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way,
>> though the debug output from the same gdalwarp operation is much longer.
>>
>>
>>
>> I can't see anything wrong.
>>
>>
>>
>> I dragged both files into ArcGIS desktop explorer and both are displayed
>> in the proper location and in their entirety.
>>
>>
>>
>> (I actually have a more elaborate workflow that works fine with chart #1
>> but this is the simplest operation I can think of that shows the problem
>> with chart #2.)
>>
>>
>>
>> Thank you very much,
>>
>> carl
>>
>>
>>
>>
>>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

[Carl Godkin]

Thanks for checking, Jukka.

I am using GDAL 3.3.3 and get a smaller range:

d:\gdal-3.3.3\bin64\gdalwarp.exe  -t_srs epsg:4326 "Caribbean 2 VFR
Chart.tif" caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18714P x 10830L.
Processing Caribbean 2 VFR Chart.tif [1/1] :
0...10...20...30...40...50...60...70...80...90...100 - done.

Is there a bug fix between 3.3.3 and 3.4.0 that could account for this?

Meanwhile, I'll try to get GDAL 3.4.0 going here.  Thanks,

carl

On Fri, Nov 5, 2021 at 7:51 AM Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the
> file.
>
> gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
>
> Copying color table from Caribbean 2 VFR Chart.tif to new file.
>
> Creating output file that is 18583P x 12118L.
>
> Processing Caribbean 2 VFR Chart.tif [1/1] :
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
>
>
> The map in caribbean_4326.tif is complete.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Carl
> Godkin
> *Lähetetty:* perjantai 5. marraskuuta 2021 16.25
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] GeoTIFF gdalwarp puzzle
>
>
>
> Hi,
>
>
>
> I'm working with some aviation charts and found one that behaves in a
> puzzling manner.
>
> This page
> https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
>
> has two Caribbean VFR charts in GeoTIFF format.
>
>
>
> I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I
> only ever get a small area out of the map instead of the whole extent.
> Specifically this command gives me just a smaller area output GeoTIFF:
>
>
>
> gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON
>
>
>
> I don't see anything from the debug output that explains this.
>
>
>
> The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way,
> though the debug output from the same gdalwarp operation is much longer.
>
>
>
> I can't see anything wrong.
>
>
>
> I dragged both files into ArcGIS desktop explorer and both are displayed
> in the proper location and in their entirety.
>
>
>
> (I actually have a more elaborate workflow that works fine with chart #1
> but this is the simplest operation I can think of that shows the problem
> with chart #2.)
>
>
>
> Thank you very much,
>
> carl
>
>
>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

[Rahkonen Jukka (MML)]

Hi,

Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the file.

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18583P x 12118L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

The map in caribbean_4326.tif is complete.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 16.25
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GeoTIFF gdalwarp puzzle

Hi,

I'm working with some aviation charts and found one that behaves in a puzzling 
manner.
This page 
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
has two Caribbean VFR charts in GeoTIFF format.

I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I only 
ever get a small area out of the map instead of the whole extent.  Specifically 
this command gives me just a smaller area output GeoTIFF:

gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON

I don't see anything from the debug output that explains this.

The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way, though 
the debug output from the same gdalwarp operation is much longer.

I can't see anything wrong.

I dragged both files into ArcGIS desktop explorer and both are displayed in the 
proper location and in their entirety.

(I actually have a more elaborate workflow that works fine with chart #1 but 
this is the simplest operation I can think of that shows the problem with chart 
#2.)

Thank you very much,
carl


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF gdalwarp puzzle

[Carl Godkin]

Hi,

I'm working with some aviation charts and found one that behaves in a
puzzling manner.
This page
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
has two Caribbean VFR charts in GeoTIFF format.

I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I
only ever get a small area out of the map instead of the whole extent.
Specifically this command gives me just a smaller area output GeoTIFF:

gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON

I don't see anything from the debug output that explains this.

The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way,
though the debug output from the same gdalwarp operation is much longer.

I can't see anything wrong.

I dragged both files into ArcGIS desktop explorer and both are displayed in
the proper location and in their entirety.

(I actually have a more elaborate workflow that works fine with chart #1
but this is the simplest operation I can think of that shows the problem
with chart #2.)

Thank you very much,
carl
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF: connection between CRS WKT and GeoKeys

[Even Rouault]

Le 13/10/2021 à 18:35, Eric Robeck a écrit :
I have a question about which GeoTIFF tags should be used for storing 
CRS information. I have two GeoTIFFs: one original and the same file 
saved as a COG. Then I created gdalinfo and listgeo reports for each 
and compared them for changes.


*gdalinfo*: Aside from the difference in the PROJCRS citation ("WGS 84 
/ UTM zone 6N" vs. "WGS_84_UTM_zone_6N"), the only change is the COG 
and LZW predictor.


*listgeo*: a large number of GeoTags were never populated by the 
original GeoTIFF creators. Other ASCII citation values were replaced 
by the Esri conversion tool.


A number of the listgeo-reported GeoKeys in the COG (e.g. 
GeogGeodeticDatumGeoKey, GeogAngularUnitSizeGeoKey, 
GeogEllipsoidGeoKey, etc.) are missing from the custom-made original 
GeoTIFF. The extra CRS tags were added upon conversion to COG. Those 
parameters are fundamental components of the CRS and are reported in 
the gdalinfo WKT as DATUM/ELLIPSOID, ANGLEUNIT, etc.


However, the WKT reported by gdalinfo is identical in both cases. So 
it had access to the full WKT components even when the corresponding 
GeoKeys were missing in the GeoTIFF.


My questions are:

 1. If the GeoKeys storing that information are missing from the
GeoTIFF, where does GDAL retrieve them from? Does it refer to the
PROJ library to retrieve the EPSG values for the EPSG codes in
ProjectedCSTypeGeoKey, VerticalCSTypeGeoKey, etc.?

Yes, GDAL / libgeotiff uses the EPSG codes of the geokeys that contain 
some to build its CRS object by querying the PROJ database. If you've a 
ProjectedCSTypeGeoKey, then the geokeys describing the linear unit, the 
geographic CRS, datum, etc are useless. When outputing GeoTIFF 1.0, GDAL 
will write a bit more than needed. This has been restricted to the 
minimum set to avoid any contradiction when using GeoTIFF 1.1 output. 
GeoTIFF 1.0 is the default when no vertical information is available. 
GeoTIFF 1.1 when there's one. This can be controlled with the 
GEOTIFF_VERSION creation option.


 1. Some software, following guidance in DGIWG-108 and DGIWG-250, did
not assign a VerticalDatumGeoKey. Prior to release of GeoTIFF 1.1,
the "unknown" value caused problems with vertical projection in
some software, like QT Modeler. Does GDAL now fill in or assume
the missing key based on the VerticalCSTypeGeoKey?

If VerticalCSTypeGeoKey is present and the GeoTIFF version 1.0, GDAL 
will use its rather complex heuristics to try to guess a vertical CRS, 
but will not reoprt it by default unless you define the 
GTIFF_REPORT_COMPD_CS=YES configuration option 
(https://gdal.org/drivers/raster/gtiff.html#configuration-options)


If the file is GeoTIFF 1.1, it will report the vertical information by 
default, when present in the file.


Even

||


Thanks in advance!

Regards,
Eric


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF: connection between CRS WKT and GeoKeys

[Eric Robeck]

I have a question about which GeoTIFF tags should be used for storing CRS
information. I have two GeoTIFFs: one original and the same file saved as a
COG. Then I created gdalinfo and listgeo reports for each and compared them
for changes.

*gdalinfo*: Aside from the difference in the PROJCRS citation ("WGS 84 /
UTM zone 6N" vs. "WGS_84_UTM_zone_6N"), the only change is the COG and LZW
predictor.

*listgeo*: a large number of GeoTags were never populated by the original
GeoTIFF creators. Other ASCII citation values were replaced by the Esri
conversion tool.

A number of the listgeo-reported GeoKeys in the COG (e.g.
GeogGeodeticDatumGeoKey, GeogAngularUnitSizeGeoKey, GeogEllipsoidGeoKey,
etc.) are missing from the custom-made original GeoTIFF. The extra CRS tags
were added upon conversion to COG. Those parameters are fundamental
components of the CRS and are reported in the gdalinfo WKT as
DATUM/ELLIPSOID, ANGLEUNIT, etc.

However, the WKT reported by gdalinfo is identical in both cases. So it had
access to the full WKT components even when the corresponding GeoKeys were
missing in the GeoTIFF.

My questions are:

   1. If the GeoKeys storing that information are missing from the GeoTIFF,
   where does GDAL retrieve them from? Does it refer to the PROJ library to
   retrieve the EPSG values for the EPSG codes in ProjectedCSTypeGeoKey,
   VerticalCSTypeGeoKey, etc.?
   2. Some software, following guidance in DGIWG-108 and DGIWG-250, did not
   assign a VerticalDatumGeoKey. Prior to release of GeoTIFF 1.1, the
   "unknown" value caused problems with vertical projection in some software,
   like QT Modeler. Does GDAL now fill in or assume the missing key based on
   the VerticalCSTypeGeoKey?

Thanks in advance!

Regards,
Eric
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

[jratike80]

Hi,

There is a common belief that problems with images happen only with exactly
that confidential multigigabyte image that user is playing with. That is
uncommon and usually the problem can be repeated with any other image with
similar structure. 

If you have GDAL v. 3.2 you can use
https://gdal.org/programs/gdal_create.html for sharing test data. Usage
example:

gdal_create -outsize 500 500 -burn 255 -burn 0 -burn 0 -if p4433h.tif
create.tif

The command creates a 500x500 pixel sized image that has the same
projection, bit depth etc. than the original "p4433h.tif" but all the pixels
are filled with red (this was a RGB image). Now there is no secrets to be
seen in the image. If the location is secret, assign fake ullr coordinates.
If even SRS is sectet you can change even that.

It is also possible to do quite a lot with python and nobody can say by your
description what goes wrong. Add so much of Python that others can just
copy, paste, and run the code, and together with the test image it produces
the error. Just as with the image, do not show all your code. Simplify it
into minimum to show the error.

-Jukka Rahkonen-



Dustin Sims wrote
> Hey devs,
> 
> I have an issue where writing any GeoTiff from python results in
> 
> ERROR 1: TIFFSetField:Path/To/File: Unknown tag 42113
> 
> This happens regardless of warp or translate (the only two applicable
> tools for my use case)
> 
> However, running this through the CLI tools with the exact same inputs
> results in the NoDataValue being preserved, and no matching error output.
> While I can use subprocess tools to run the CLI tool through python, I
> would very much prefer to use gdal.Warp() and the like.
> 
> I am unable to provide sample data, due to it being confidential. If I use
> gdal.Warp() or gdal.BuildVRT() to convert the input file to VRT, the
> NoData is preserved. Translating that to a GeoTiff  results in the above
> error and NoData is lost. Seems really strange that I am unable to write
> tag 42113, as that is one of the GDAL specific tags. Anyone have any
> advice on what I could do to resolve this?
> 
> GDAL version 3.2.1
> GDAL-python 3.2.1
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

[Dustin Sims]

Hey devs,

I have an issue where writing any GeoTiff from python results in

ERROR 1: TIFFSetField:Path/To/File: Unknown tag 42113

This happens regardless of warp or translate (the only two applicable tools for 
my use case)

However, running this through the CLI tools with the exact same inputs results 
in the NoDataValue being preserved, and no matching error output.
While I can use subprocess tools to run the CLI tool through python, I would 
very much prefer to use gdal.Warp() and the like.

I am unable to provide sample data, due to it being confidential. If I use 
gdal.Warp() or gdal.BuildVRT() to convert the input file to VRT, the NoData is 
preserved. Translating that to a GeoTiff  results in the above error and NoData 
is lost. Seems really strange that I am unable to write tag 42113, as that is 
one of the GDAL specific tags. Anyone have any advice on what I could do to 
resolve this?

GDAL version 3.2.1
GDAL-python 3.2.1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [Geotiff] libgeotiff 1.6.0 release soon

[Even Rouault]

On lundi 20 avril 2020 13:39:50 CEST Sebastiaan Couwenberg wrote:
> On 4/20/20 12:15 PM, Even Rouault wrote:
> > In preparation for the upcoming GDAL 3.1.0 release, I intend to prepare a
> > libgeotiff 1.6.0 release later this week. I believe things are in good
> > shape, but if people want to give it a quick try to master, that's
> > welcome.
> 
> Will there be an RC before the release?

I'll do that.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [Geotiff] libgeotiff 1.6.0 release soon

[Sebastiaan Couwenberg]

On 4/20/20 12:15 PM, Even Rouault wrote:
> In preparation for the upcoming GDAL 3.1.0 release, I intend to prepare a 
> libgeotiff 1.6.0 release later this week. I believe things are in good shape, 
> but 
> if people want to give it a quick try to master, that's welcome.

Will there be an RC before the release?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF: embedd JPEG without recompression

[Tobias Wendorff]

Am Fr, 2.11.2018, 18:40 schrieb Even Rouault:
>
> Yes, this is limited to a single JPEG file as a source (not a VRT of
> several JPEG files for example), and if you use -co COMPRESS=JPEG
> without an explicit -co QUALITY setting. -co TILED=YES is supported.

Yeeks, it also gets "jpeg:sampling-factor" correctly! Good work.
It's even doing it better than ImageMagick!

I now can use GDAL to create TIFFs for printing images on canvas.
JPEG can't handle dimensions (millimeters and DPI) correctly, while
TIFF can. Add this to GDAL's use-cases, please :-)

Thanks, good work!

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF: embedd JPEG without recompression

[Even Rouault]

On vendredi 2 novembre 2018 17:33:07 CET Tobias Wendorff wrote:
> Hi there,
> 
> can "gdal_translate" embedd a JPEG file in TIFF without recompression?

Yes, this is limited to a single JPEG file as a source (not a VRT of several 
JPEG files for example), and if you use -co COMPRESS=JPEG without an explicit 
-co QUALITY setting. -co TILED=YES is supported.

If you add "--debug GTiff", you'll see a "GTiff: Using special copy mode from 
a JPEG dataset" debug message when this direct mode is used.

$ gdal_translatenin.jpg out.tif -co compress=jpeg --debug GTiff
Input file size is 50, 50
GTiff: Using special copy mode from a JPEG dataset

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF: embedd JPEG without recompression

[Tobias Wendorff]

Hi there,

can "gdal_translate" embedd a JPEG file in TIFF without recompression?

Best regards,
Tobias

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF NoData

[Julierme Pinheiro]

Hi all,

Sorry if my question has been discussed here before. I followed 1
Answer/Option 2 of this post
to
convert  an image (GeoTIFF) external pixels RGB(255,255,255) to NoData.

So, I used the following command line using GDAL_TRANSLATE :

gdal_translate -a_nodata 255 -of GTiff
/home/julierme/Desktop/amazonia_sar/amapa/IMG/covmingrad/CSKS4_20161223204711_CSKS4_20170124204700_3_CovMinGrad_rgb.tif
/home/julierme/Desktop/amazonia_sar/amapa/IMG/covmingrad/CSKS4_20161223204711_CSKS4_20170124204700_3_CovMinGrad_rgb_nodata.tif

The reason I am doing this is because I had a boundary/border
RGB(255,225,225) in the image. So, I converted the entire image
(255,255,255) pixels to NoData. Now, here are my two issues:

1 - Even after setting the InputTransparentColor = FF in Geoserver as
mentioned in the post Option2, the image border is not transparent. The
border, got an ALPHA_BAND=0.0 surrounding the image. Instead of an
ALPHA_BAND, I need a NaN value for the border. So, I need to completely
remove the ALPHA_BAND and set the border to NaN.

2 - What could I do to convert to nodata only the RGB(255,255,255) image
external pixels, without affecting the internal ones?

Thank you for your time in advance.

Julierme
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Even Rouault]

Le mercredi 06 juillet 2016 16:17:32, Daniele Romagnoli a écrit :
> Hi Even,
> thanks I'm already using the SPARSE_OK=TRUE to create an empty tiff
> and afterwards warp input files on that with SKIP_NOSOURCE=YES.
> I have already updated the ImageIO-EXT's TIFFImageReader to deal with
> tile/strip with zero byte count.
> 
> Final question:
> Starting from which GDAL version, SPARSE_OK=TRUE and SKIP_NOSOURCE=YES are
> supported?

Woo, a long time. I wasn't probably even born when they were added. 

Digging a bit in history shows that SPARSE_OK was added in 2008 / GDAL 1.6 and 
SKIP_NOSOURCE in 2006...
Returning the nodata value for implicit blocks instead of 0 was added in 1.7.

> 
> Thanks for your feedbacks.
> Cheers,
> Daniele
> 
> 
> On Wed, Jul 6, 2016 at 3:53 PM, Even Rouault 
> 
> wrote:
> > Daniele,
> > 
> > > has this improvement also being backported on previous versions (as an
> > > instance 2.1.x, 2.0.x)?
> > 
> > No, trunk only.
> > 
> > You could as well use the SPARSE_OK=TRUE creation option to avoid
> > writting blocks at all. Provided that your reader knows how to deal with
> > tile/strips with a 0 byte count (GDAL based readers back to the older
> > days are OK)
> > 
> > Even
> > 
> > > Cheers,
> > > Daniele
> > > 
> > > On Tue, May 10, 2016 at 3:29 PM, Even Rouault <
> > 
> > even.roua...@spatialys.com>
> > 
> > > wrote:
> > > > Le mardi 10 mai 2016 09:22:19, jramm a écrit :
> > > > > Hi
> > > > > I have made changes to FillEmptyTiles so that if nodata is set,
> > > > > then
> > 
> > it
> > 
> > > > > will always fill with nodata, otherwise 0.
> > > > > 
> > > > > I have attached the raw diff...I have no idea how to submit a
> > > > > change request/review etc?
> > > > > 
> > > > > fillempty_nodata.diff
> > > > > <
> > 
> > http://osgeo-org.1560.x6.nabble.com/file/n5265514/fillempty_nodata.dif
> > 
> > > > > f
> > > > 
> > > > I've committed in trunk a more complete version of your patch since
> > > > on reflection there was also the case of non power-of-two bit depths
> > > > to handle.
> > > > 
> > > > Patches are better handled as attachments to Trac tickets.
> > > > 
> > > > Even
> > > > 
> > > > --
> > > > Spatialys - Geospatial professional services
> > > > http://www.spatialys.com
> > > > ___
> > > > gdal-dev mailing list
> > > > gdal-dev@lists.osgeo.org
> > > > 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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Daniele Romagnoli]

Hi Even,
thanks I'm already using the SPARSE_OK=TRUE to create an empty tiff
and afterwards warp input files on that with SKIP_NOSOURCE=YES.
I have already updated the ImageIO-EXT's TIFFImageReader to deal with
tile/strip with zero byte count.

Final question:
Starting from which GDAL version, SPARSE_OK=TRUE and SKIP_NOSOURCE=YES are
supported?

Thanks for your feedbacks.
Cheers,
Daniele


On Wed, Jul 6, 2016 at 3:53 PM, Even Rouault 
wrote:

> Daniele,
>
> > has this improvement also being backported on previous versions (as an
> > instance 2.1.x, 2.0.x)?
>
> No, trunk only.
>
> You could as well use the SPARSE_OK=TRUE creation option to avoid writting
> blocks at all. Provided that your reader knows how to deal with tile/strips
> with a 0 byte count (GDAL based readers back to the older days are OK)
>
> Even
>
> >
> > Cheers,
> > Daniele
> >
> > On Tue, May 10, 2016 at 3:29 PM, Even Rouault <
> even.roua...@spatialys.com>
> >
> > wrote:
> > > Le mardi 10 mai 2016 09:22:19, jramm a écrit :
> > > > Hi
> > > > I have made changes to FillEmptyTiles so that if nodata is set, then
> it
> > > > will always fill with nodata, otherwise 0.
> > > >
> > > > I have attached the raw diff...I have no idea how to submit a change
> > > > request/review etc?
> > > >
> > > > fillempty_nodata.diff
> > > > <
> http://osgeo-org.1560.x6.nabble.com/file/n5265514/fillempty_nodata.dif
> > > > f
> > >
> > > I've committed in trunk a more complete version of your patch since on
> > > reflection there was also the case of non power-of-two bit depths to
> > > handle.
> > >
> > > Patches are better handled as attachments to Trac tickets.
> > >
> > > Even
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
> > > ___
> > > gdal-dev mailing list
> > > gdal-dev@lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Even Rouault]

Daniele,

> has this improvement also being backported on previous versions (as an
> instance 2.1.x, 2.0.x)?

No, trunk only.

You could as well use the SPARSE_OK=TRUE creation option to avoid writting 
blocks at all. Provided that your reader knows how to deal with tile/strips 
with a 0 byte count (GDAL based readers back to the older days are OK)

Even

> 
> Cheers,
> Daniele
> 
> On Tue, May 10, 2016 at 3:29 PM, Even Rouault 
> 
> wrote:
> > Le mardi 10 mai 2016 09:22:19, jramm a écrit :
> > > Hi
> > > I have made changes to FillEmptyTiles so that if nodata is set, then it
> > > will always fill with nodata, otherwise 0.
> > > 
> > > I have attached the raw diff...I have no idea how to submit a change
> > > request/review etc?
> > > 
> > > fillempty_nodata.diff
> > >  > > f
> > 
> > I've committed in trunk a more complete version of your patch since on
> > reflection there was also the case of non power-of-two bit depths to
> > handle.
> > 
> > Patches are better handled as attachments to Trac tickets.
> > 
> > Even
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Daniele Romagnoli]

Hi Even,
has this improvement also being backported on previous versions (as an
instance 2.1.x, 2.0.x)?

Cheers,
Daniele

On Tue, May 10, 2016 at 3:29 PM, Even Rouault 
wrote:

> Le mardi 10 mai 2016 09:22:19, jramm a écrit :
> > Hi
> > I have made changes to FillEmptyTiles so that if nodata is set, then it
> > will always fill with nodata, otherwise 0.
> >
> > I have attached the raw diff...I have no idea how to submit a change
> > request/review etc?
> >
> > fillempty_nodata.diff
> >  >
>
> I've committed in trunk a more complete version of your patch since on
> reflection there was also the case of non power-of-two bit depths to
> handle.
>
> Patches are better handled as attachments to Trac tickets.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Even Rouault]

Le mardi 10 mai 2016 09:22:19, jramm a écrit :
> Hi
> I have made changes to FillEmptyTiles so that if nodata is set, then it
> will always fill with nodata, otherwise 0.
> 
> I have attached the raw diff...I have no idea how to submit a change
> request/review etc?
> 
> fillempty_nodata.diff
> 

I've committed in trunk a more complete version of your patch since on 
reflection there was also the case of non power-of-two bit depths to handle.

Patches are better handled as attachments to Trac tickets.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[jramm]

Hi
I have made changes to FillEmptyTiles so that if nodata is set, then it will
always fill with nodata, otherwise 0. 

I have attached the raw diff...I have no idea how to submit a change
request/review etc?

fillempty_nodata.diff
  



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-value-tp5264310p5265514.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Even Rouault]

Le vendredi 06 mai 2016 13:33:36, jramm a écrit :
> NoDataValue is set on a band level and FillEmptyTiles operates at a dataset
> level.
> 
> I've never heard of a geotiff with different nodata per band - is this even
> possible, or would it be reasonable to take the nodatavalue of the 1st band
> and use this to initialise the empty tiles block?

The GDAL_NODATA tag contains a single value, so in GeoTIFF, you can only have 
the same nodata value for all bands. Perhaps this can be overridden in a 
.aux.xml file, but I'm not even sure. So yes using the nodata value of the 
first 
band is reasonable. Actually I see there's the following variables at the 
GTiffDataset level :

boolbNoDataChanged;
int bNoDataSet;
double  dfNoDataValue;

Caution: dfNoDataValue is initialized to - if bNoDataSet is FALSE. But we 
probably want to write zeroes when burning tiles.

> 
> Then there is the problem of the block array being initialised as GBYte:
> 
> GByte *pabyData = (GByte *) VSI_CALLOC_VERBOSE(nBlockBytes,1);
> 
> NoDataValue is always returned as a double, but actual data type may be
> different values...Am I right in thinking TIFFTileSize will return the
> number of bytes in a block for the data type of the tiff file (e.g. so
> block size = nBlockBytes / sizeof(data_type)?

TIFFTileSize() returns a number of bytes whatever the datatype size is.

> 
> Would something like this be a reasonable way to initialise pabyData
> 
> int typeSize;
> switch (eType){
>   case GDT_Byte:
>   typeSize = sizeof(GByte)
>   case GDT_Int16:
>   typeSize = sizeof(short)
> 
>...
> }
> 
> 
> for (int i =0; i < nBlockBytes; i+=typeSize)
> {
> *pabyData = nullValue;
> }

I'd rather use GDALCopyWords() to do datatype conversion & replication.

GDALCopyWords( , GDT_Float64, 0,
   pabyData, eDataType,
   GDALGetDataTypeSizeBytes(eDataType),
   nBlockBytes / GDALGetDataTypeSizeBytes(eDataType) )


> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-va
> lue-tp5264310p5264905.html Sent from the GDAL - Dev mailing list archive at
> Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[jramm]

NoDataValue is set on a band level and FillEmptyTiles operates at a dataset
level. 

I've never heard of a geotiff with different nodata per band - is this even
possible, or would it be reasonable to take the nodatavalue of the 1st band
and use this to initialise the empty tiles block?

Then there is the problem of the block array being initialised as GBYte:

GByte *pabyData = (GByte *) VSI_CALLOC_VERBOSE(nBlockBytes,1);

NoDataValue is always returned as a double, but actual data type may be
different values...Am I right in thinking TIFFTileSize will return the
number of bytes in a block for the data type of the tiff file (e.g. so block
size = nBlockBytes / sizeof(data_type)?

Would something like this be a reasonable way to initialise pabyData

int typeSize;
switch (eType){
  case GDT_Byte:
  typeSize = sizeof(GByte)
  case GDT_Int16:
  typeSize = sizeof(short)

   ...
}


for (int i =0; i < nBlockBytes; i+=typeSize)
{
*pabyData = nullValue;
}



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-value-tp5264310p5264905.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

[Even Rouault]

Le mardi 03 mai 2016 20:23:49, jramm a écrit :
> Hi
> 
> When writing geotiffs, if I dont write blocks they will automatically be
> filled on close by the FillEmptyTiles.
> It appears that this will only fill with zeros - is it possible to make it
> fill with the no data value instead?

You can also avoid the blocks to be written at all with the SPARSE_OK=TRUE 
creation option. On reading, missing blocks will be returned filled with the 
nodata value. But sparse geotiffs are a bit non-standard.

We'd welcome a patch to modify FillEmptyTiles to use the nodata value

> 
> This is potentially a huge time saver when processing a large, fairly
> sparse geotiff using python as relying on gdal to fill in 'null' blocks
> appears far quicker than calling the python write method.
> 
> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-va
> lue-tp5264310.html Sent from the GDAL - Dev mailing list archive at
> Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geotiff FillEmptyTiles with no data value?

[jramm]

Hi

When writing geotiffs, if I dont write blocks they will automatically be
filled on close by the FillEmptyTiles.
It appears that this will only fill with zeros - is it possible to make it
fill with the no data value instead?

This is potentially a huge time saver when processing a large, fairly sparse
geotiff using python as relying on gdal to fill in 'null' blocks appears far
quicker than calling the python write method. 




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-value-tp5264310.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

[Even Rouault]

Le jeudi 14 avril 2016 22:48:23, Christine Waigl a écrit :
> Hi Even,
> 
> Thanks so much for this quick and thorough response. The workaround made it
> possible to fix my code, and I've extended it to multi-band GeoTIFF files
> (my RGB composites) as
> 
> gdal_translate -ot Byte -of vrt -b 1 -b 1 -b 2 -b 3 -scale_4 -scale_1
> -scale_2 -scale_3 infile.tif infile_8bit.vrt
> gdal_translate -b 2 -b 3 -b 4 infile_8bit.vrt infile_8bit.tif

You're likely to hit the bug again with the above. Rather try (basically band 4 
of the VRT is the "junk band" ):

gdal_translate -ot Byte -of vrt -b 1 -b 2 -b 3 -b 3 -scale_4 -scale_1 -scale_2 
-scale_3 infile.tif infile_8bit.vrt
gdal_translate -b 1 -b 2 -b 3 infile_8bit.vrt infile_8bit.tif


> 
> Un grand merci!
> 
> Chris
> 
> 
> On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault 
> 
> wrote:
> > Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit :
> > > Hi all,
> > > 
> > > I have been using the GDAL command line tools to pre-process various
> > 
> > kinds
> > 
> > > of remote sensing imagery datasets in GeoTIFF format. This includes
> > > resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine
> > 
> > bands
> > 
> > > into RBG composites.
> > > 
> > > In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any
> > 
> > more:
> > > gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif
> > > 
> > > ​I usually apply this to the already clipped RGB composites, but
> > > digging deeper, even for single-band images what seems to be happening
> > > is that
> > 
> > the
> > 
> > > -scale option doesn't correctly calculates the source range:
> > >- If I use the command above, or with -scale_1, the whole output
> > >file has a value 0 for each pixel
> > >- If I use the "-b 1 -scale", the whole output file has a value 255
> > >at each pixel
> > >- If I use "-scale src_min src_max" with a manually inserted src_min
> > 
> > and
> > 
> > >src_max, I get a reasonable result (though not necessarily identical
> > 
> > to
> > 
> > > the GDAL result with automatically calculated min and max.
> > > 
> > > 
> > > What is driving me absolutely bonkers, though, is that *occasionally*
> > > the command "-b 1 -scale" DOES produce a correct 8-bit file. It's not
> > > reproducible, though: if I delete all 8bit files and re-run the script
> > 
> > over
> > 
> > > a whole set of 16 bit files, a whole different file may be resampled
> > > correctly.
> > > 
> > > With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my
> > > machine) seems to be working at the moment, but my main system is
> > 
> > currently
> > 
> > > at 11.4, and I have a reason not to upgrade right away. Is there a way
> > > to make it work with 11.4? I could run gdalinfo first and extract min
> > > and
> > 
> > max
> > 
> > > from the stats, and then feed this into gdal_translate, but I'd like to
> > > avoid this path if possible. A test file (a file subsetted with
> > 
> > > "gdal_translate -projwin... " from a whole Landsat 8 band) is here:
> > http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.ti
> > f
> > 
> > > (3.8 MB).
> > 
> > Christine,
> > 
> > Thanks for the report. Random issues are often a sign of uninitialized
> > memory and running through Valgrind confirmed it.
> > And it confirms that the issues exists in all versions starting with
> > 1.11, so the fact
> > that it runs with 2.0.2 is just luck.
> > 
> > A workaround is to do the following. Be sure to put -scale_2 *before*
> > -scale_1. And be sure to use -b 1 in the second
> > gdal_translate as the band 2 scale/offset in the VRT might be junk.
> > 
> > $ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte
> > LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt
> > $ gdal_translate -b 1 out.vrt out.tif
> > 
> > Fixed per https://trac.osgeo.org/gdal/ticket/6455 .
> > 
> > Even
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

[Christine Waigl]

Hi Even,

Thanks so much for this quick and thorough response. The workaround made it
possible to fix my code, and I've extended it to multi-band GeoTIFF files
(my RGB composites) as

gdal_translate -ot Byte -of vrt -b 1 -b 1 -b 2 -b 3 -scale_4 -scale_1
-scale_2 -scale_3 infile.tif infile_8bit.vrt
gdal_translate -b 2 -b 3 -b 4 infile_8bit.vrt infile_8bit.tif

Un grand merci!

Chris


On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault 
wrote:

> Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit :
> > Hi all,
> >
> > I have been using the GDAL command line tools to pre-process various
> kinds
> > of remote sensing imagery datasets in GeoTIFF format. This includes
> > resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine
> bands
> > into RBG composites.
> >
> > In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any
> more:
> >
> > gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif
> >
> > ​I usually apply this to the already clipped RGB composites, but digging
> > deeper, even for single-band images what seems to be happening is that
> the
> > -scale option doesn't correctly calculates the source range:
> >
> >
> >- If I use the command above, or with -scale_1, the whole output file
> >has a value 0 for each pixel
> >- If I use the "-b 1 -scale", the whole output file has a value 255 at
> >each pixel
> >- If I use "-scale src_min src_max" with a manually inserted src_min
> and
> >src_max, I get a reasonable result (though not necessarily identical
> to
> > the GDAL result with automatically calculated min and max.
> >
> >
> > What is driving me absolutely bonkers, though, is that *occasionally* the
> > command "-b 1 -scale" DOES produce a correct 8-bit file. It's not
> > reproducible, though: if I delete all 8bit files and re-run the script
> over
> > a whole set of 16 bit files, a whole different file may be resampled
> > correctly.
> >
> > With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my
> > machine) seems to be working at the moment, but my main system is
> currently
> > at 11.4, and I have a reason not to upgrade right away. Is there a way to
> > make it work with 11.4? I could run gdalinfo first and extract min and
> max
> > from the stats, and then feed this into gdal_translate, but I'd like to
> > avoid this path if possible. A test file (a file subsetted with
> > "gdal_translate -projwin... " from a whole Landsat 8 band) is here:
> >
> http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif
> > (3.8 MB).
>
> Christine,
>
> Thanks for the report. Random issues are often a sign of uninitialized
> memory and running through Valgrind confirmed it.
> And it confirms that the issues exists in all versions starting with 1.11,
> so the fact
> that it runs with 2.0.2 is just luck.
>
> A workaround is to do the following. Be sure to put -scale_2 *before*
> -scale_1. And be sure to use -b 1 in the second
> gdal_translate as the band 2 scale/offset in the VRT might be junk.
>
> $ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte
> LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt
> $ gdal_translate -b 1 out.vrt out.tif
>
> Fixed per https://trac.osgeo.org/gdal/ticket/6455 .
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>



-- 
Christine (Chris) Waigl - cwa...@alaska.edu -  +1-907-474-5483 - Skype:
cwaigl_work
Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

[Even Rouault]

Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit :
> Hi all,
> 
> I have been using the GDAL command line tools to pre-process various kinds
> of remote sensing imagery datasets in GeoTIFF format. This includes
> resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine bands
> into RBG composites.
> 
> In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any more:
> 
> gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif
> 
> ​I usually apply this to the already clipped RGB composites, but digging
> deeper, even for single-band images what seems to be happening is that the
> -scale option doesn't correctly calculates the source range:
> 
> 
>- If I use the command above, or with -scale_1, the whole output file
>has a value 0 for each pixel
>- If I use the "-b 1 -scale", the whole output file has a value 255 at
>each pixel
>- If I use "-scale src_min src_max" with a manually inserted src_min and
>src_max, I get a reasonable result (though not necessarily identical to
> the GDAL result with automatically calculated min and max.
> 
> 
> What is driving me absolutely bonkers, though, is that *occasionally* the
> command "-b 1 -scale" DOES produce a correct 8-bit file. It's not
> reproducible, though: if I delete all 8bit files and re-run the script over
> a whole set of 16 bit files, a whole different file may be resampled
> correctly.
> 
> With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my
> machine) seems to be working at the moment, but my main system is currently
> at 11.4, and I have a reason not to upgrade right away. Is there a way to
> make it work with 11.4? I could run gdalinfo first and extract min and max
> from the stats, and then feed this into gdal_translate, but I'd like to
> avoid this path if possible. A test file (a file subsetted with
> "gdal_translate -projwin... " from a whole Landsat 8 band) is here:
> http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif
> (3.8 MB).

Christine,

Thanks for the report. Random issues are often a sign of uninitialized memory 
and running through Valgrind confirmed it.
And it confirms that the issues exists in all versions starting with 1.11, so 
the fact
that it runs with 2.0.2 is just luck.

A workaround is to do the following. Be sure to put -scale_2 *before* -scale_1. 
And be sure to use -b 1 in the second
gdal_translate as the band 2 scale/offset in the VRT might be junk.

$ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte 
LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt
$ gdal_translate -b 1 out.vrt out.tif

Fixed per https://trac.osgeo.org/gdal/ticket/6455 .

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

[Christine Waigl]

Hi all,

I have been using the GDAL command line tools to pre-process various kinds
of remote sensing imagery datasets in GeoTIFF format. This includes
resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine bands
into RBG composites.

In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any more:

gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif

​I usually apply this to the already clipped RGB composites, but digging
deeper, even for single-band images what seems to be happening is that the
-scale option doesn't correctly calculates the source range:


   - If I use the command above, or with -scale_1, the whole output file
   has a value 0 for each pixel
   - If I use the "-b 1 -scale", the whole output file has a value 255 at
   each pixel
   - If I use "-scale src_min src_max" with a manually inserted src_min and
   src_max, I get a reasonable result (though not necessarily identical to the
   GDAL result with automatically calculated min and max.


What is driving me absolutely bonkers, though, is that *occasionally* the
command "-b 1 -scale" DOES produce a correct 8-bit file. It's not
reproducible, though: if I delete all 8bit files and re-run the script over
a whole set of 16 bit files, a whole different file may be resampled
correctly.

With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my
machine) seems to be working at the moment, but my main system is currently
at 11.4, and I have a reason not to upgrade right away. Is there a way to
make it work with 11.4? I could run gdalinfo first and extract min and max
from the stats, and then feed this into gdal_translate, but I'd like to
avoid this path if possible. A test file (a file subsetted with "gdal_translate
-projwin... " from a whole Landsat 8 band) is here:
http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif
(3.8 MB).

Thanks for your help,

Chris


-- 
Christine (Chris) Waigl - cwa...@alaska.edu -  +1-907-474-5483 - Skype:
cwaigl_work
Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF with non-meter linear unit in SRS

[Even Rouault]

Hi,

I've pushed in trunk per https://trac.osgeo.org/gdal/ticket/6210 a fix to 
hopefully address issues when reading GeoTIFF files whose SRS uses non-meter 
linear units (such as us-foot). I'd appreciate if people could confirm it 
doesn't break existing use cases, and hopefully fix cases that didn't work 
before.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geotiff client side

[xavier lhomme]

Hi

  WCS has the ability to return a coverage as a GeoTiff file. Then if you
want to display or process row data from this file in a Javascript web
client, you need to have to ability to decode the GeoTiff part of this
file.

 I found a Tiff.js library compiled with Emscripten. I succeed to display a
GeoTiff with this library as a Tiff file. But I still need to decode the
GeoTiff tag and create the PCSToImage / ImageToPCS functions.
  Two solutions :
   compile GeoTiff with emscripten or rewrite some part of the GeoTiff
function in javascript.

Another solution should be to ask the server to return the parameter from
the image. Is there a way to do this without sending the full image to the
server ?


Best regards

xavier lhomme
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff client side

[Peter Baumann]

Hi Xavier,

there is a couple of options with WCS 2.

- you can request another format which is easier to handle by the client, such 
as PNG (builtin browser support).


- you can send a separate DescibeCoverage request and get an XML structure 
containing all metadata.


- you can direct the server (if it supports this - data formats are at its 
discretion) to deliver a multipart MIME document (same mechanism as email + 
attachment). Its first part will be the coverage description in XML, the second 
part the (TIFF or PNG or ...) image.To this end, use this request syntax 
(presented in GET/KVP and TIFF, for POST/XML see the protocol binding specs):

http://.../wcs?REQUEST=GetCoverage  ... 
FORMAT=image/tiff  MEDIATYPE=multipart/related

HTH,
Peter



On 10/03/2014 09:48 AM, xavier lhomme wrote:

Hi

  WCS has the ability to return a coverage as a GeoTiff file. Then if you want 
to display or process row data from this file in a Javascript web client, you 
need to have to ability to decode the GeoTiff part of this file.


 I found a Tiff.js library compiled with Emscripten. I succeed to display a 
GeoTiff with this library as a Tiff file. But I still need to decode the 
GeoTiff tag and create the PCSToImage / ImageToPCS functions.

  Two solutions :
   compile GeoTiff with emscripten or rewrite some part of the GeoTiff 
function in javascript.
Another solution should be to ask the server to return the parameter from the 
image. Is there a way to do this without sending the full image to the server ?



Best regards

xavier lhomme


--
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baum...@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baum...@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis 
dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat 
quisquam non sibi parata. (mail disclaimer, AD 1083)


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff nodata handling

[Jukka Rahkonen]

Even Rouault even.rouault at mines-paris.org writes:

 This is a rather tricky area indeed.
 
 A few facts :
 - The concept of nodata value in GDAL is something per band, which leave 
 multi-band processing of nodata values subject to interpretation.
 - The TIFFTAG_GDAL_NODATA extension tag in TIFF only holds one nodata value 
 for all bands.
 - In gdalwarp utility, the warping option UNIFIED_SRC_NODATA is set to YES, 
 which means that a pixel is considered to be transparent if all bands hit 
 their respective nodata value (what you want here).
 - In gdaladdo, similar behaviour will be found if the dataset has a 
 NODATA_VALUES metadata item set to 0 0 0 for example, which makes an 
 implicit mask band of type GDALNoDataValuesMaskBand to be generated and 
 honoured. This metadata item is only set by the PNG driver for now. With VRT, 
 the metadata item could be also set for other datasets.
 
 I guess QGIS only look band per band. A reliable way of solving this would be 
 to generate a RGBA dataset instead.

Just a word from my own experience: typical same-for-all-bands nodata values
 0 0 0 and 255 255 255 tend to burn holes into aerial and satellite images
within water bodies (black, more common) or on dry, light soils or
reflective areas like tin roofs (white, not as common). Something like pure
blue 0 0 255 occurs never in natural images and therefore would suit
perfectly as a nodata value in theory. I had once a whole bunch of such
images before I learned that many programs could not handle the transparency
and I had to reprocess them to 0 0 0. 

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geotiff nodata handling

[Andrea Aime]

Hi,
I'm trying to wrap my head around how gdal handles nodata values.
In an image with this gdalinfo exceprt:

Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  NoData Value=0
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  NoData Value=0
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  NoData Value=0

and using software based on gdal (e.g. qgis), it seems that a pixel is
considered
nodata if any of the three pixel bands are zero (even just one).

I could swear I saw some gdal specific way to embed metadata
saying if all three bands are zero, then the pixel is nodata
(pull pixel as opposed band per band treatment), but I cannot
find it anymore.

Did I imagine it? If existing, do you have a feeling of how well
supported that is in common software?

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff nodata handling

[Even Rouault]

Le mercredi 18 juin 2014 18:35:49, Andrea Aime a écrit :
 Hi,
 I'm trying to wrap my head around how gdal handles nodata values.
 In an image with this gdalinfo exceprt:
 
 Band 1 Block=512x512 Type=Byte, ColorInterp=Red
   NoData Value=0
 Band 2 Block=512x512 Type=Byte, ColorInterp=Green
   NoData Value=0
 Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
   NoData Value=0
 
 and using software based on gdal (e.g. qgis), it seems that a pixel is
 considered
 nodata if any of the three pixel bands are zero (even just one).
 
 I could swear I saw some gdal specific way to embed metadata
 saying if all three bands are zero, then the pixel is nodata
 (pull pixel as opposed band per band treatment), but I cannot
 find it anymore.
 
 Did I imagine it? If existing, do you have a feeling of how well
 supported that is in common software?

This is a rather tricky area indeed.

A few facts :
- The concept of nodata value in GDAL is something per band, which leave 
multi-band processing of nodata values subject to interpretation.
- The TIFFTAG_GDAL_NODATA extension tag in TIFF only holds one nodata value 
for all bands.
- In gdalwarp utility, the warping option UNIFIED_SRC_NODATA is set to YES, 
which means that a pixel is considered to be transparent if all bands hit 
their respective nodata value (what you want here).
- In gdaladdo, similar behaviour will be found if the dataset has a 
NODATA_VALUES metadata item set to 0 0 0 for example, which makes an 
implicit mask band of type GDALNoDataValuesMaskBand to be generated and 
honoured. This metadata item is only set by the PNG driver for now. With VRT, 
the metadata item could be also set for other datasets.

I guess QGIS only look band per band. A reliable way of solving this would be 
to generate a RGBA dataset instead.

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff crashing qgis

[Jukka Rahkonen]

David Strip gdal at stripfamily.net writes:

 At the moment I'm at a loss as to where to start looking for the problem.
 Any suggestions are most welcome.

Send us links to the images you have created with GDAL and which make
troubles with QGIS. Perhaps someone finds what is wrong in these images.
Next step would be to think how it is possible to make GDAL to write out
such unfriendly files.

-Jukka Rahkonen-





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Trent Piepho]

On Nov 10, 2013 1:44 AM, Even Rouault even.roua...@mines-paris.org
wrote:

 Le dimanche 10 novembre 2013 00:14:42, Trent Piepho a écrit :
  I've found that unless you call SetGeoTransform() and give an affine
  transform, most apps, including listgeo and gdalsrsinfo, aren't
  entirely happy with the georeferencing.  GDAL has a function that
  computes a transform from GCPs, but it needs to be part of the GDAL
  code for the dataset driver.  GDAL doesn't automatically do it when a
  user of GDAL wants an affine transform from a dataset.

 True. This is (I think) a design decision, as generally GDAL tries to
expose
 information as close as possible to what is in the dataset. GCPs alone
don't
 provide an unambiguous way of transforming image pixel coordinates into
real-
 world coordinates. You have to specify which extrapolation method you
want to
 use : polynomial at which order, thin plate spline, ..

From what I've seen many apps just want to translate between pixel,line and
geographic coordinates.  The method to do this appears to be to get the SRS
from the dataset, use one of it's methods to transform between geographic
coordinates and projected coordinates, then get the geotransform
coefficients and preform the affine transform with them.

With no geotransform, this doesn't work.  Instead one is supposed toI
don't know.  I don't see any OGR or dataset function that will do the
coordinate transform.  I've looked at other apps, and none of them can
handle this.   So you end up with the only way to georeference a dataset,
and have anything work, is to use a affine transform.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Norman Goldstein]

Frank and Trent,

I have created a proper GeoTIFF file with the code
listed, below.  There is still one oddity:
The code sets the   line/sample -- x/y   affine transformation
using an array of 6 doubles.  The code contains a conditional
compilation that chooses between two different arrays of
6 doubles.

The #if 1 array produces a full listgeo dump.
The #else listgeo dump is missing the corner coordinates.

The difference between the two arrays is
-- The false northing for #if 1 is  0.001 .
-- The false northing for #else  is  0

Is this a quirk of GDAL?  of listeo?  Or, should map x,y
always be set up to take on only positive values?


/// full source code ///
#include iostream
#include ogr_spatialref.h
#include gdal_priv.h

int main( int argc, char* argv[] )
{
  using namespace std;

  GDALAllRegister();
  GDALDriverManager* dmgr = GetGDALDriverManager();

  GDALDriver* drv =
dmgr-GetDriverByName( GTiff );

  if( nullptr == drv )
  {
cerr  Error from GetDriverByName  endl;
return -3;
  }

  GDALDataset* dataset = drv-Create( dem.tif,
  300,
  200,
  1, // Num bands
  GDT_Float32,
  nullptr );
  if( nullptr == dataset )
  {
cerr  Error from Create  endl;
return -4;
  }

  OGRSpatialReference oSRS;
  oSRS.SetProjCS( NoWhere );
  oSRS.SetWellKnownGeogCS( WGS84 );
  oSRS.SetEquirectangular( 0.0,// Centre lat
   0.0,// Centre lon
   0.0,   // False Easting
   0.0 ); // False Northing

  char* wkt = nullptr;

  if( OGRERR_NONE != oSRS.exportToWkt( wkt ) )
  {
cerr  Error from exportToWkt  endl;
return -5;
  }

  cout  WKT=   wkt  endl;

#if 1
  double coeffs[] = { 0.0, 1.0, 0.0,
  0.001, 0.0, -1.0 };
#else
  double coeffs[] = { 0.0, 1.0, 0.0,
  0.0, 0.0, -1.0 };
#endif

  if( CE_None != dataset-SetGeoTransform( coeffs ) )
  {
cerr  Error from SetGeoTransform  endl;
return -6;
  }

  if( CE_None != dataset-SetProjection( wkt ) )
  {
cerr  Error from SetProjection  endl;
return -7;
  }

  OGRFree( wkt );
  wkt = nullptr;

  GDALClose( dataset );
  dataset = nullptr;
}// main
///

# full listgeo dump ###
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (2,3):
 000
 00.0010
  ModelPixelScaleTag (1,3):
 110
  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,8): NoWhere
  GeographicTypeGeoKey (Short,1): GCS_WGS_84
  GeogCitationGeoKey (Ascii,7): WGS 84
  GeogAngularUnitsGeoKey (Short,1): Angular_Degree
  GeogSemiMajorAxisGeoKey (Double,1): 6378137
  GeogInvFlatteningGeoKey (Double,1): 298.257224
  ProjectedCSTypeGeoKey (Short,1): User-Defined
  ProjectionGeoKey (Short,1): User-Defined
  ProjCoordTransGeoKey (Short,1): CT_Equirectangular
  ProjLinearUnitsGeoKey (Short,1): Linear_Meter
  ProjStdParallel1GeoKey (Double,1): 0
  ProjFalseEastingGeoKey (Double,1): 0
  ProjFalseNorthingGeoKey (Double,1): 0
  ProjCenterLongGeoKey (Double,1): 0
  ProjCenterLatGeoKey (Double,1): 0
  End_Of_Keys.
   End_Of_Geotiff.

Projection Method: CT_Equirectangular
   ProjCenterLatGeoKey: 0.00 (  0d 0' 0.00N)
   ProjCenterLongGeoKey: 0.00 (  0d 0' 0.00E)
   ProjFalseEastingGeoKey: 0.00 m
   ProjFalseNorthingGeoKey: 0.00 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00E)
Projection Linear Units: 9001/metre (1.00m)

Corner Coordinates:
Upper Left(   0.000,   0.001)  (  0d 0' 0.00E,  0d 0' 0.00N)
Lower Left(   0.000,-199.999)  (  0d 0' 0.00E,  0d 0' 6.47S)
Upper Right   ( 300.000,   0.001)  (  0d 0' 9.70E,  0d 0' 0.00N)
Lower Right   ( 300.000,-199.999)  (  0d 0' 9.70E,  0d 0' 6.47S)
Center( 150.000, -99.999)  (  0d 0' 4.85E,  0d 0' 3.23S)



On 11/09/2013 03:14 PM, Trent Piepho wrote:

On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein norm...@telus.net wrote:

Things are better, now, but not quite there for me.
Still not able to transform pixel/line to PCS space.
(the listgeo dump is, below)

I think the problem is that there is no definition of the

ModelPixelScaleTag

It seems that this tag, together with the ModelTiepointTag,
is how an affine transformation is inferred.  Or by directly
setting

ModelTransformationTag

which I could do with GDALDataset's SetGeoTransform()
method (for defining 2D affine 

Re: [gdal-dev] geotiff projection not showing up

[Even Rouault]

Le lundi 11 novembre 2013 20:46:47, Norman Goldstein a écrit :
 Frank and Trent,
 
 I have created a proper GeoTIFF file with the code
 listed, below.  There is still one oddity:
 The code sets the   line/sample -- x/y   affine transformation
 using an array of 6 doubles.  The code contains a conditional
 compilation that chooses between two different arrays of
 6 doubles.
 
 The #if 1 array produces a full listgeo dump.
 The #else listgeo dump is missing the corner coordinates.
 
 The difference between the two arrays is
 -- The false northing for #if 1 is  0.001 .
 -- The false northing for #else  is  0
 
 Is this a quirk of GDAL?  of listeo?  Or, should map x,y
 always be set up to take on only positive values?

The GDAL GTiff driver considers that the  {0.0, 1.0, 0.0, 0.0, 0.0, -1.0} 
geotransform as indicating that the image is not georeferenced (identity 
geotransform). This is not something that you are likely to use in real-world 
situations.

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Even Rouault]

Le dimanche 10 novembre 2013 00:14:42, Trent Piepho a écrit :
 On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein norm...@telus.net wrote:
  Things are better, now, but not quite there for me.
  Still not able to transform pixel/line to PCS space.
  (the listgeo dump is, below)
  
  I think the problem is that there is no definition of the
  
  ModelPixelScaleTag
  
  It seems that this tag, together with the ModelTiepointTag,
  is how an affine transformation is inferred.  Or by directly
  setting
  
  ModelTransformationTag
  
  which I could do with GDALDataset's SetGeoTransform()
  method (for defining 2D affine transformations).
 
 I've found that unless you call SetGeoTransform() and give an affine
 transform, most apps, including listgeo and gdalsrsinfo, aren't
 entirely happy with the georeferencing.  GDAL has a function that
 computes a transform from GCPs, but it needs to be part of the GDAL
 code for the dataset driver.  GDAL doesn't automatically do it when a
 user of GDAL wants an affine transform from a dataset.

True. This is (I think) a design decision, as generally GDAL tries to expose 
information as close as possible to what is in the dataset. GCPs alone don't 
provide an unambiguous way of transforming image pixel coordinates into real-
world coordinates. You have to specify which extrapolation method you want to 
use : polynomial at which order, thin plate spline, .. 

Of course with 3 points, you can (but not necessarily must) compute an affine 
transform in an unambiguous way, but in that case you'd rather define the 6 
coefficient geotransform directly.

And I've worked with a mapping authority that forbids from implicitly using 
the tiepoints from a GeoTIFF to compute a geotransform.

Depending on the cases, GDAL drivers might choose to compute an approximate 
geotransform from the GCPs, but GDAL core will not make that behind their 
back.

 
 It seems like most code that tries to find corner coordinates and/or
 the pixel size of a raster expects an affine transform plus a
 projection.  If there are a set of GCPs, then that code won't work.
 The information may well be there, like your three GCP points, but the
 GDAL user needs totally different code make use of it.  It's the same
 reason most of NOAA's nautical charts don't work with apps that use
 GDAL or GDAL created GeoTIFFs.  I've just started looking at the GDAL
 code, but it doesn't seem like GDAL abstracts this enough to have
 broad compatibility.
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Norman Goldstein]

Frank,

Things are better, now, but not quite there for me.
Still not able to transform pixel/line to PCS space.
(the listgeo dump is, below)

I think the problem is that there is no definition of the

ModelPixelScaleTag

It seems that this tag, together with the ModelTiepointTag,
is how an affine transformation is inferred.  Or by directly
setting

ModelTransformationTag

which I could do with GDALDataset's SetGeoTransform()
method (for defining 2D affine transformations).

The GTiffDataset class is hidden from users of GDAL,
being defined in the cpp file frmts/gtiff/geotiff.cpp .
Is there a way to directly set the tags of a GeoTIFF
GDAL Dataset?  Or, would this break GDAL's useful
ability of uniformly dealing with the many different
dataset formats?




I changed the call to SetGCPs, as you suggested:

dataset-SetGCPs( 3,
  gcps,
  wkt )

where wkt is the equirectangular projection defined
below, in an earlier email.  Here is the listgeo dump:

// listgeo dump /
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (6,3):
 0249  0
 000
 399  249  0
 1000 00
 000
 02000 0
  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
  GTCitationGeoKey (Ascii,8): NoWhere
  GeographicTypeGeoKey (Short,1): GCS_WGS_84
  GeogCitationGeoKey (Ascii,7): WGS 84
  GeogAngularUnitsGeoKey (Short,1): Angular_Degree
  GeogSemiMajorAxisGeoKey (Double,1): 6378137
  GeogInvFlatteningGeoKey (Double,1): 298.257224
  ProjectedCSTypeGeoKey (Short,1): User-Defined
  ProjectionGeoKey (Short,1): User-Defined
  ProjCoordTransGeoKey (Short,1): CT_Equirectangular
  ProjLinearUnitsGeoKey (Short,1): Linear_Meter
  ProjStdParallel1GeoKey (Double,1): 0
  ProjFalseEastingGeoKey (Double,1): 0
  ProjFalseNorthingGeoKey (Double,1): 0
  ProjCenterLongGeoKey (Double,1): 0
  ProjCenterLatGeoKey (Double,1): 0
  End_Of_Keys.
   End_Of_Geotiff.

Projection Method: CT_Equirectangular
   ProjCenterLatGeoKey: 0.00 (  0d 0' 0.00N)
   ProjCenterLongGeoKey: 0.00 (  0d 0' 0.00E)
   ProjFalseEastingGeoKey: 0.00 m
   ProjFalseNorthingGeoKey: 0.00 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00E)
Projection Linear Units: 9001/metre (1.00m)

Corner Coordinates:
 ... unable to transform points between pixel/line and PCS space


This is much better, but, still missing the pixel/line -- PCS
transformation (as noted, above).


On 11/07/2013 07:32 AM, Frank Warmerdam wrote:

Norman,

My apologies.  The GCP projection is actually supposed to be passed as 
the third value in the SetGCPs call - where you have passed the string 
Richmond.  Instead pass the whole WKT strings for the coordinate system.


Best regards,
Frank


On Wed, Nov 6, 2013 at 4:00 PM, Norman Goldstein norm...@telus.net 
mailto:norm...@telus.net wrote:


Frank,

I am using GDAL
Version : 1.9.2

so maybe that is why I do not see the method SetGCPProjection().

I think you have convinced me, though, to calculate the 6
coefficients directly,
and then call SetGeoTransform().  Will let you guys know how this
works out
for me.

Thank you,
Norm



On 11/06/2013 01:51 PM, Frank Warmerdam wrote:

Norman,

I believe you want to call SetGCPProjection() instead of
SetProjection() when using GCPs instead of an affine transform.

Best regards,
Frank



On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein
norm...@telus.net mailto:norm...@telus.net wrote:

I have created a geotiff file using the GTiff driver, and
have successfully set options for it to be a strips file with
no compression.  Also, successfully called the functions

dataset-SetMetadataItem( AREA_OR_POINT,
Point,
 nullptr ) )

and

dataset-SetGCPs( 3,
   gcps,
   Richmond )

Here is the listgeo dump:

# listgeo dump ##
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (6,3):
 0249  0
 000
 399  249  0
 1000 00
 0   

Re: [gdal-dev] geotiff projection not showing up

[Trent Piepho]

On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein norm...@telus.net wrote:
 Things are better, now, but not quite there for me.
 Still not able to transform pixel/line to PCS space.
 (the listgeo dump is, below)

 I think the problem is that there is no definition of the

 ModelPixelScaleTag

 It seems that this tag, together with the ModelTiepointTag,
 is how an affine transformation is inferred.  Or by directly
 setting

 ModelTransformationTag

 which I could do with GDALDataset's SetGeoTransform()
 method (for defining 2D affine transformations).

I've found that unless you call SetGeoTransform() and give an affine
transform, most apps, including listgeo and gdalsrsinfo, aren't
entirely happy with the georeferencing.  GDAL has a function that
computes a transform from GCPs, but it needs to be part of the GDAL
code for the dataset driver.  GDAL doesn't automatically do it when a
user of GDAL wants an affine transform from a dataset.

It seems like most code that tries to find corner coordinates and/or
the pixel size of a raster expects an affine transform plus a
projection.  If there are a set of GCPs, then that code won't work.
The information may well be there, like your three GCP points, but the
GDAL user needs totally different code make use of it.  It's the same
reason most of NOAA's nautical charts don't work with apps that use
GDAL or GDAL created GeoTIFFs.  I've just started looking at the GDAL
code, but it doesn't seem like GDAL abstracts this enough to have
broad compatibility.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Frank Warmerdam]

Norman,

My apologies.  The GCP projection is actually supposed to be passed as the
third value in the SetGCPs call - where you have passed the string
Richmond.  Instead pass the whole WKT strings for the coordinate system.

Best regards,
Frank


On Wed, Nov 6, 2013 at 4:00 PM, Norman Goldstein norm...@telus.net wrote:

  Frank,

 I am using GDAL
 Version : 1.9.2

 so maybe that is why I do not see the method SetGCPProjection().

 I think you have convinced me, though, to calculate the 6 coefficients
 directly,
 and then call SetGeoTransform().  Will let you guys know how this works out
 for me.

 Thank you,
 Norm



 On 11/06/2013 01:51 PM, Frank Warmerdam wrote:

 Norman,

  I believe you want to call SetGCPProjection() instead of SetProjection()
 when using GCPs instead of an affine transform.

  Best regards,
 Frank



 On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.netwrote:

 I have created a geotiff file using the GTiff driver, and have
 successfully set options for it to be a strips file with no compression.
  Also, successfully called the functions

 dataset-SetMetadataItem( AREA_OR_POINT,
 Point,
  nullptr ) )

 and

 dataset-SetGCPs( 3,
gcps,
Richmond )

 Here is the listgeo dump:

 # listgeo dump ##
 Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
   ModelTiepointTag (6,3):
  0249  0
  000
  399  249  0
  1000 00
  000
  02000 0
   End_Of_Tags.
Keyed_Information:
   GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
   End_Of_Keys.
End_Of_Geotiff.


 Corner Coordinates:
  ... unable to transform points between pixel/line and PCS space
 #

 I also set the reference system using the following code:

 /// c++ code 
   OGRSpatialReference oSRS;
   oSRS.SetProjCS( NoWhere );
   oSRS.SetWellKnownGeogCS( WGS84 );
   oSRS.SetEquirectangular( 0.0,// Centre lat
0.0,// Centre lon
0.0,   // False Easting
0.0 ); // False Northing

   char* wkt = nullptr;

   if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
   {
  error...
   }

   if( CE_Failure == dataset-SetProjection( wkt ) )
   {
error...
   }
 ///

 So, why is listgeo not able to transform points between pixel/line and
 PCS space?

 I am happy to upload a full working example if needed.

 Thank you.












 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




  --

 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam,
 warmer...@pobox.com
 light and sound - activate the windows | http://pobox.com/~warmerdam
 and watch the world go round - Rush| Geospatial Software Developer



 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] geotiff projection not showing up

[Norman Goldstein]

I have created a geotiff file using the GTiff driver, and have 
successfully set options for it to be a strips file with no 
compression.  Also, successfully called the functions


dataset-SetMetadataItem( AREA_OR_POINT,
Point,
 nullptr ) )

and

dataset-SetGCPs( 3,
   gcps,
   Richmond )

Here is the listgeo dump:

# listgeo dump ##
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (6,3):
 0249  0
 000
 399  249  0
 1000 00
 000
 02000 0
  End_Of_Tags.
   Keyed_Information:
  GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
  End_Of_Keys.
   End_Of_Geotiff.


Corner Coordinates:
 ... unable to transform points between pixel/line and PCS space
#

I also set the reference system using the following code:

/// c++ code 
  OGRSpatialReference oSRS;
  oSRS.SetProjCS( NoWhere );
  oSRS.SetWellKnownGeogCS( WGS84 );
  oSRS.SetEquirectangular( 0.0,// Centre lat
   0.0,// Centre lon
   0.0,   // False Easting
   0.0 ); // False Northing

  char* wkt = nullptr;

  if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
  {
 error...
  }

  if( CE_Failure == dataset-SetProjection( wkt ) )
  {
   error...
  }
///

So, why is listgeo not able to transform points between pixel/line and 
PCS space?


I am happy to upload a full working example if needed.

Thank you.













smime.p7s
Description: S/MIME Cryptographic Signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Frank Warmerdam]

Norman,

I believe you want to call SetGCPProjection() instead of SetProjection()
when using GCPs instead of an affine transform.

Best regards,
Frank



On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.net wrote:

 I have created a geotiff file using the GTiff driver, and have
 successfully set options for it to be a strips file with no compression.
  Also, successfully called the functions

 dataset-SetMetadataItem( AREA_OR_POINT,
 Point,
  nullptr ) )

 and

 dataset-SetGCPs( 3,
gcps,
Richmond )

 Here is the listgeo dump:

 # listgeo dump ##
 Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
   ModelTiepointTag (6,3):
  0249  0
  000
  399  249  0
  1000 00
  000
  02000 0
   End_Of_Tags.
Keyed_Information:
   GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
   End_Of_Keys.
End_Of_Geotiff.


 Corner Coordinates:
  ... unable to transform points between pixel/line and PCS space
 #

 I also set the reference system using the following code:

 /// c++ code 
   OGRSpatialReference oSRS;
   oSRS.SetProjCS( NoWhere );
   oSRS.SetWellKnownGeogCS( WGS84 );
   oSRS.SetEquirectangular( 0.0,// Centre lat
0.0,// Centre lon
0.0,   // False Easting
0.0 ); // False Northing

   char* wkt = nullptr;

   if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
   {
  error...
   }

   if( CE_Failure == dataset-SetProjection( wkt ) )
   {
error...
   }
 ///

 So, why is listgeo not able to transform points between pixel/line and PCS
 space?

 I am happy to upload a full working example if needed.

 Thank you.












 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff projection not showing up

[Norman Goldstein]

Frank,

I am using GDAL
Version : 1.9.2

so maybe that is why I do not see the method SetGCPProjection().

I think you have convinced me, though, to calculate the 6 coefficients 
directly,

and then call SetGeoTransform().  Will let you guys know how this works out
for me.

Thank you,
Norm


On 11/06/2013 01:51 PM, Frank Warmerdam wrote:

Norman,

I believe you want to call SetGCPProjection() instead of 
SetProjection() when using GCPs instead of an affine transform.


Best regards,
Frank



On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.net 
mailto:norm...@telus.net wrote:


I have created a geotiff file using the GTiff driver, and have
successfully set options for it to be a strips file with no
compression.  Also, successfully called the functions

dataset-SetMetadataItem( AREA_OR_POINT,
Point,
 nullptr ) )

and

dataset-SetGCPs( 3,
   gcps,
   Richmond )

Here is the listgeo dump:

# listgeo dump ##
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (6,3):
 0249  0
 000
 399  249  0
 1000 00
 000
 02000 0
  End_Of_Tags.
   Keyed_Information:
  GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
  End_Of_Keys.
   End_Of_Geotiff.


Corner Coordinates:
 ... unable to transform points between pixel/line and PCS space
#

I also set the reference system using the following code:

/// c++ code 
  OGRSpatialReference oSRS;
  oSRS.SetProjCS( NoWhere );
  oSRS.SetWellKnownGeogCS( WGS84 );
  oSRS.SetEquirectangular( 0.0,// Centre lat
   0.0,// Centre lon
   0.0,   // False Easting
   0.0 ); // False Northing

  char* wkt = nullptr;

  if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
  {
 error...
  }

  if( CE_Failure == dataset-SetProjection( wkt ) )
  {
   error...
  }
///

So, why is listgeo not able to transform points between pixel/line
and PCS space?

I am happy to upload a full working example if needed.

Thank you.












___
gdal-dev mailing list
gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev




--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, 
warmer...@pobox.com mailto:warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam 
http://pobox.com/%7Ewarmerdam

and watch the world go round - Rush| Geospatial Software Developer




smime.p7s
Description: S/MIME Cryptographic Signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

[CABO]

Hi

When batch processing GeoTIFF files, I tend to get this problem a bit too often:

Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code
ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes)
ERROR 1: TIFFReadEncodedStrip() failed.

band 1: IReadBlock failed at X offset 0, Y offset 11
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 11

The strip, scanline and offsets vary. It normally happens when I process from 
clients (computers) with the files located on servers (on local network), and I 
can reprocess a file again without getting the error, or possible an error with 
a different strip, scanline or offset. This special case is caused by 
gdaldem.exe and the error is reported by gdal_translate.exe using GDAL 1.9, but 
I have experienced this error using GDAL 1.9.2 and I think I saw it using GDAL 
1.10 also.

I have two issues here:

1.   Why the problem is happening to begin with?

2.   Why does the Warning and/or Error not trigger ERRORLEVEL 1?

The first bullet I think can be very difficult to debug, so I seek experiences 
here. The second bullet is really frustrating, because I have to look through 
all my clients looking for output similar to the message above - and then 
reprocess all crashed files again.

One solution I have seen somewhere is to not compressing the files, but this 
results in quite an increase in disk space usage - way too high for me.


Kind regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

[Even Rouault]

Casper,

I'm not sure to have understood if you have this problem while reading or
generating compressed files. Could you provide a way (that is to say provide
both the input data and the command line used) of reproducing this ?

Best regards,

Even


 Hi

 When batch processing GeoTIFF files, I tend to get this problem a bit too
 often:

 Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code
 ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes)
 ERROR 1: TIFFReadEncodedStrip() failed.

 band 1: IReadBlock failed at X offset 0, Y offset 11
 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 11

 The strip, scanline and offsets vary. It normally happens when I process from
 clients (computers) with the files located on servers (on local network), and
 I can reprocess a file again without getting the error, or possible an error
 with a different strip, scanline or offset. This special case is caused by
 gdaldem.exe and the error is reported by gdal_translate.exe using GDAL 1.9,
 but I have experienced this error using GDAL 1.9.2 and I think I saw it using
 GDAL 1.10 also.

 I have two issues here:

 1.   Why the problem is happening to begin with?

 2.   Why does the Warning and/or Error not trigger ERRORLEVEL 1?

 The first bullet I think can be very difficult to debug, so I seek
 experiences here. The second bullet is really frustrating, because I have to
 look through all my clients looking for output similar to the message above -
 and then reprocess all crashed files again.

 One solution I have seen somewhere is to not compressing the files, but this
 results in quite an increase in disk space usage - way too high for me.


 Kind regards, Casper



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

[CABO]

Hi Even.

I cannot reproduce the error, it just occurs when I'm batch processing and not 
necessarily at the same place/file. That's why I asked for experience. 
However, when I get the error again, I can provide the corrupted file and then 
its possible to see that ex. Gdal_translate doesn't set ERRORLEVEL 1 or similar 
even though the process cannot continue.

Kind regards, Casper


-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: 11. juli 2013 15:40
To: Casper Børgesen (CABO)
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

Casper,

I'm not sure to have understood if you have this problem while reading or 
generating compressed files. Could you provide a way (that is to say provide 
both the input data and the command line used) of reproducing this ?

Best regards,

Even


 Hi

 When batch processing GeoTIFF files, I tend to get this problem a bit 
 too
 often:

 Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code 
 ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes) 
 ERROR 1: TIFFReadEncodedStrip() failed.

 band 1: IReadBlock failed at X offset 0, Y offset 11 ERROR 1: 
 GetBlockRef failed at X block offset 0, Y block offset 11

 The strip, scanline and offsets vary. It normally happens when I 
 process from clients (computers) with the files located on servers (on 
 local network), and I can reprocess a file again without getting the 
 error, or possible an error with a different strip, scanline or 
 offset. This special case is caused by gdaldem.exe and the error is 
 reported by gdal_translate.exe using GDAL 1.9, but I have experienced 
 this error using GDAL 1.9.2 and I think I saw it using GDAL 1.10 also.

 I have two issues here:

 1.   Why the problem is happening to begin with?

 2.   Why does the Warning and/or Error not trigger ERRORLEVEL 1?

 The first bullet I think can be very difficult to debug, so I seek 
 experiences here. The second bullet is really frustrating, because I 
 have to look through all my clients looking for output similar to the 
 message above - and then reprocess all crashed files again.

 One solution I have seen somewhere is to not compressing the files, 
 but this results in quite an increase in disk space usage - way too high for 
 me.


 Kind regards, Casper



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

[Even Rouault]

Le jeudi 11 juillet 2013 15:56:56, Casper Børgesen (CABO) a écrit :
 Hi Even.
 
 I cannot reproduce the error, it just occurs when I'm batch processing and
 not necessarily at the same place/file. That's why I asked for experience.
 However, when I get the error again, I can provide the corrupted file and
 then its possible to see that ex. Gdal_translate doesn't set ERRORLEVEL 1
 or similar even though the process cannot continue.

Normally it should return an error, but if the error happens during the 
closing of the dataset (writes might be deferred), then it would go unnoticed. 
That's potentially what happens in your case, but difficult to know without 
closer investigation.

 
 Kind regards, Casper
 
 
 -Original Message-
 From: Even Rouault [mailto:even.roua...@mines-paris.org]
 Sent: 11. juli 2013 15:40
 To: Casper Børgesen (CABO)
 Cc: gdal-dev@lists.osgeo.org
 Subject: Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors
 
 Casper,
 
 I'm not sure to have understood if you have this problem while reading or
 generating compressed files. Could you provide a way (that is to say
 provide both the input data and the command line used) of reproducing this
 ?
 
 Best regards,
 
 Even
 
  Hi
  
  When batch processing GeoTIFF files, I tend to get this problem a bit
  too
  often:
  
  Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code
  ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes)
  ERROR 1: TIFFReadEncodedStrip() failed.
  
  band 1: IReadBlock failed at X offset 0, Y offset 11 ERROR 1:
  GetBlockRef failed at X block offset 0, Y block offset 11
  
  The strip, scanline and offsets vary. It normally happens when I
  process from clients (computers) with the files located on servers (on
  local network), and I can reprocess a file again without getting the
  error, or possible an error with a different strip, scanline or
  offset. This special case is caused by gdaldem.exe and the error is
  reported by gdal_translate.exe using GDAL 1.9, but I have experienced
  this error using GDAL 1.9.2 and I think I saw it using GDAL 1.10 also.
  
  I have two issues here:
  
  1.   Why the problem is happening to begin with?
  
  2.   Why does the Warning and/or Error not trigger ERRORLEVEL 1?
  
  The first bullet I think can be very difficult to debug, so I seek
  experiences here. The second bullet is really frustrating, because I
  have to look through all my clients looking for output similar to the
  message above - and then reprocess all crashed files again.
  
  One solution I have seen somewhere is to not compressing the files,
  but this results in quite an increase in disk space usage - way too high
  for me.
  
  
  Kind regards, Casper

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF with LZW compression Overviews error

[Fabian Schindler]

Frank,


I'm assuming you mean gdaladdo is run on y.tif, the output of gdalwarp, right?

Yes, sorry, that's what I meant.

I tried the steps with a manufactured input file of the same size and
did not encounter the problem on my system.  The most likely important
difference is that I am not using libtiff 3.9.4 - I'm using libtiff
4.0.x (trunk).  Is there a reason you are using the old style libtiff?
  Perhaps just because it is what is packaged?  I imagine that is the
problem.
Yes I'm using the packaged version of libtiff. I guess I'll have to try 
the 4.0.x version and report my experiences.


Thanks!
Fabian
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF with LZW compression Overviews error

[Fabian Schindler]

Dear devs,

I'm experiencing strange errors when I try to add overviews to specific 
GeoTIFF files with internal tiling and LZW compression. This error shows 
only on some (about 3-5%) of the input files.


This is how I process the file:

$gdal_translate -gcp 0 0 19.09 49.22 -gcp 100 0 20.1 49.11 -gcp 100 401 19.27 
45.89 -gcp 100 802 18.42 42.34 -gcp 100 1203 17.6 38.79 -gcp 100 1605 17.41 
37.96 -gcp 0 1605 16.58 38.07 -gcp 0 1203 16.76 38.91 -gcp 0 802 17.53 42.45 
-gcp 0 401 18.33 46.0 -of GTIFF -a_srs EPSG:4326 -co compress=LZW -co tiled=YES 
x.jpg x.tif

$gdalwarp -t_srs EPSG:4326 -co tiled=YES -co compress=LZW x.tif y.tif

$gdaladdo c.tif 2 4 8 16 32

0...10...20...30...40...50...60...70...80...90...Warning 1: c.tif:LZWDecode: 
Strip -1 not terminated with EOI code

ERROR 1: c.tif:LZWDecode: Not enough data at scanline 0 (short 46008 bytes)

ERROR 1: TIFFReadEncodedTile() failed.

ERROR 1: IReadBlock failed at X offset 0, Y offset 2

ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 2

100 - done.

Any ideas/help on that?

Thanks in advance,
Fabian


FYI: I'm on a CentOS box with GDAL 1.9.1, released 2012/05/15, and 
libgeotiff 1.4.0-1.el6, and libtiff 3.9.4-6.el6_3.


A gdalinfo of the file shows:

Driver: GTiff/GeoTIFF

Files: x.tif

Size is 1497, 4965

Coordinate System is:

GEOGCS[WGS 84,

DATUM[WGS_1984,

SPHEROID[WGS 84,6378137,298.257223563,

AUTHORITY[EPSG,7030]],

AUTHORITY[EPSG,6326]],

PRIMEM[Greenwich,0],

UNIT[degree,0.0174532925199433],

AUTHORITY[EPSG,4326]]

Origin = (9.291424276853256,49.550154279390341)

Pixel Size = (0.007350754725447,-0.007350754725447)

Metadata:

  AREA_OR_POINT=Area

Image Structure Metadata:

  COMPRESSION=LZW

  INTERLEAVE=PIXEL

Corner Coordinates:

Upper Left  (   9.2914243,  49.5501543) (  9d17'29.13E, 49d33' 0.56N)

Lower Left  (   9.2914243,  13.0536571) (  9d17'29.13E, 13d 3'13.17N)

Upper Right (  20.2955041,  49.5501543) ( 20d17'43.81E, 49d33' 0.56N)

Lower Right (  20.2955041,  13.0536571) ( 20d17'43.81E, 13d 3'13.17N)

Center  (  14.7934642,  31.3019057) ( 14d47'36.47E, 31d18' 6.86N)

Band 1 Block=256x256 Type=Byte, ColorInterp=Red

  Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156

Band 2 Block=256x256 Type=Byte, ColorInterp=Green

  Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156

Band 3 Block=256x256 Type=Byte, ColorInterp=Blue

  Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF with LZW compression Overviews error

[Frank Warmerdam]

Fabian,

I'm assuming you mean gdaladdo is run on y.tif, the output of gdalwarp, right?

I tried the steps with a manufactured input file of the same size and
did not encounter the problem on my system.  The most likely important
difference is that I am not using libtiff 3.9.4 - I'm using libtiff
4.0.x (trunk).  Is there a reason you are using the old style libtiff?
 Perhaps just because it is what is packaged?  I imagine that is the
problem.

Best regards,
Frank



On Wed, Feb 13, 2013 at 9:01 AM, Fabian Schindler
fabian.schind...@eox.at wrote:
 Dear devs,

 I'm experiencing strange errors when I try to add overviews to specific
 GeoTIFF files with internal tiling and LZW compression. This error shows
 only on some (about 3-5%) of the input files.

 This is how I process the file:

 $gdal_translate -gcp 0 0 19.09 49.22 -gcp 100 0 20.1 49.11 -gcp 100 401
 19.27 45.89 -gcp 100 802 18.42 42.34 -gcp 100 1203 17.6 38.79 -gcp 100 1605
 17.41 37.96 -gcp 0 1605 16.58 38.07 -gcp 0 1203 16.76 38.91 -gcp 0 802 17.53
 42.45 -gcp 0 401 18.33 46.0 -of GTIFF -a_srs EPSG:4326 -co compress=LZW -co
 tiled=YES x.jpg x.tif

 $gdalwarp -t_srs EPSG:4326 -co tiled=YES -co compress=LZW x.tif y.tif

 $gdaladdo c.tif 2 4 8 16 32

 0...10...20...30...40...50...60...70...80...90...Warning 1: c.tif:LZWDecode:
 Strip -1 not terminated with EOI code

 ERROR 1: c.tif:LZWDecode: Not enough data at scanline 0 (short 46008 bytes)

 ERROR 1: TIFFReadEncodedTile() failed.

 ERROR 1: IReadBlock failed at X offset 0, Y offset 2

 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 2

 100 - done.

 Any ideas/help on that?

 Thanks in advance,
 Fabian


 FYI: I'm on a CentOS box with GDAL 1.9.1, released 2012/05/15, and
 libgeotiff 1.4.0-1.el6, and libtiff 3.9.4-6.el6_3.

 A gdalinfo of the file shows:

 Driver: GTiff/GeoTIFF

 Files: x.tif

 Size is 1497, 4965

 Coordinate System is:

 GEOGCS[WGS 84,

 DATUM[WGS_1984,

 SPHEROID[WGS 84,6378137,298.257223563,

 AUTHORITY[EPSG,7030]],

 AUTHORITY[EPSG,6326]],

 PRIMEM[Greenwich,0],

 UNIT[degree,0.0174532925199433],

 AUTHORITY[EPSG,4326]]

 Origin = (9.291424276853256,49.550154279390341)

 Pixel Size = (0.007350754725447,-0.007350754725447)

 Metadata:

   AREA_OR_POINT=Area

 Image Structure Metadata:

   COMPRESSION=LZW

   INTERLEAVE=PIXEL

 Corner Coordinates:

 Upper Left  (   9.2914243,  49.5501543) (  9d17'29.13E, 49d33' 0.56N)

 Lower Left  (   9.2914243,  13.0536571) (  9d17'29.13E, 13d 3'13.17N)

 Upper Right (  20.2955041,  49.5501543) ( 20d17'43.81E, 49d33' 0.56N)

 Lower Right (  20.2955041,  13.0536571) ( 20d17'43.81E, 13d 3'13.17N)

 Center  (  14.7934642,  31.3019057) ( 14d47'36.47E, 31d18' 6.86N)

 Band 1 Block=256x256 Type=Byte, ColorInterp=Red

   Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156

 Band 2 Block=256x256 Type=Byte, ColorInterp=Green

   Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156

 Band 3 Block=256x256 Type=Byte, ColorInterp=Blue

   Overviews: 749x2483, 375x1242, 188x621, 94x311, 47x156



 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

[reinaldo]

Ivan,

Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey
for SIRGAS2000 EPSG: 31983?

I get Unknown-31983 with gdal utility programs.

Thanks,

 Reinaldo Escada Chohfi
 Sócio Gerente
 GeoDesign Internacional
 www.geodesign.com.br (http://www.geodesign.com.br)
 Tel./Fax: (12) 3153-5115
 Inteligência e Tecnologia Espacial de Ponta

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

[Ivan Lucena]

Have you look at [http://spatialreference.org/ref/epsg/31983/] ?


  ---Original Message---
  From: reina...@geodesign.com.br
  To: Ivan Lucena ivan.luc...@princeton-ma.us, gdal-dev 
 gdal-dev@lists.osgeo.org
  Subject: GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983
  Sent: Dec 21 '12 09:49
  
  Ivan,
  
  Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey
  for SIRGAS2000 EPSG: 31983?
  
  I get Unknown-31983 with gdal utility programs.
  
  Thanks,
  
  
  
  
  Reinaldo Escada Chohfi
  Sócio Gerente
  GeoDesign Internacional
  [LINK: http://www.geodesign.com.br] www.geodesign.com.br
  Tel./Fax: (12) 3153-5115
  
  Inteligência e Tecnologia Espacial de Ponta
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

[Jean-Claude Repetto]

On 21/12/2012 15:49, reina...@geodesign.com.br wrote:
 Ivan,
 
 Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey
 for SIRGAS2000 EPSG: 31983?
 
 I get Unknown-31983 with gdal utility programs.
 
 Thanks,

GDAL knows this system :

$ epsg_tr.py 31983
PROJCS[SIRGAS 2000 / UTM zone 23S,
GEOGCS[SIRGAS 2000,
DATUM[Sistema_de_Referencia_Geocentrico_para_las_AmericaS_2000,
SPHEROID[GRS 1980,6378137,298.257222101,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6674]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4674]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,0],
PARAMETER[central_meridian,-45],
PARAMETER[scale_factor,0.9996],
PARAMETER[false_easting,50],
PARAMETER[false_northing,1000],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AXIS[Easting,EAST],
AXIS[Northing,NORTH],
AUTHORITY[EPSG,31983]]
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] geotiff

[Neelima Emmani]

Hi

Can anyone tell me how to display geotiff image in a dotspatial map using c#.

With Regards,
Neelima Emmani

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff

[Chaitanya kumar CH]

Neelima,

Please refer to the DotSpatial docs at
http://dotspatial.codeplex.com/documentation

On Thu, Sep 27, 2012 at 5:26 PM, Neelima Emmani 
neelima.emm...@iictechnologies.com wrote:

  Hi

 Can anyone tell me how to display geotiff image in a dotspatial map using
 c#.

 With Regards,
 Neelima Emmani


 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff

[Neelima Emmani]

Hi
We tried to open raster file as in suggested document . But unfortunately our 
application is not accepting any file path in  the raster.open() method. Can 
you please tell me if I am missing any dlls. In addition to gdal_csharp , we 
also added a reference to  DotSpatial.Data.Rasters.GdalExtension.

Suggested in doc -
Raster r = new Raster();
r.Open(@[Your Folder]\Ex3\Data\DEM\Elevation.bgd);

Practical in my application -
Raster r = new Raster();
r.Open();


With Regards,
Neelima Emmani


From: Chaitanya kumar CH [chaitanya...@gmail.com]
Sent: Friday, September 28, 2012 8:33 AM
To: Neelima Emmani
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] geotiff

Neelima,

Please refer to the DotSpatial docs at 
http://dotspatial.codeplex.com/documentation

On Thu, Sep 27, 2012 at 5:26 PM, Neelima Emmani 
neelima.emm...@iictechnologies.commailto:neelima.emm...@iictechnologies.com 
wrote:
Hi

Can anyone tell me how to display geotiff image in a dotspatial map using c#.

With Regards,
Neelima Emmani


___
gdal-dev mailing list
gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] geoTiff to tiles

[len lee]

I am working with 2gb large geotiff image.I need convert the large geoTiff
to tiles (about 250x250 pixels) with c++ language;

i dont wanna read the whole geotiff file since it is gonna be real slow ..
i want to get the tiles according to geographic position and

i am not sure exactly how to do it or what sort of utilities i should use
within gdal;

I'm neither an expert on GeoTIFFs nor GDAL, and I greatly appreciate the
assistance!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Julien Malik]

Hello,

As it seems like the gdal 1.8 debian package is not out yet, maybe there 
is still some time left to tackle this issue for the next gdal debian 
package.


To sum up the current situation when reading TIFF files with gdal :
- this program : 
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx 
segfaults on Debian when linked with -lgeotiff -lgdal but not when 
linked with -lgdal -lgeotiff. It runs fine on Ubuntu
- this program : 
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx segfaults 
on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs fine when 
geotiff comes before gdal.


For now, we managed to provide binary packages for the Orfeo Toolbox 
applications on Ubuntu by ensuring geotiff comes before gdal in the link 
list (see https://launchpad.net/~otb). This works because we manage the 
build from begining to end.


But this is a showstopper for our efforts to provide QGis plugins based 
on Orfeo Toolbox : even with the (fragile) solution we ended up with 
(ensuring the order geotiff-gdal in all our link commands), our qgis 
plugins crash as soon as they read a TIFF file on Ubuntu.

So we are stuck and cannot release binaries of those plugins.


What can we do to help find a solution (what kind of modification to the 
gdal debian package would you agree to make to solve this issue) ?

Do you have pointers on those versioned symbols you were referring to ?
Are you still against the redefinition of the internal tiff/geotiff 
symbols or is this an option for you (for libtiff, there is already a 
working solution in the InsightToolkit) ? It seems to be the safest 
solution to me.
Are we still the only people on Earth linking programs with both gdal 
and geotiff ;) ?



Regards,
Julien



Le 29/11/2010 17:08, Julien Malik a écrit :

Hello Even,

Thank you for your answer.

Le 29/11/2010 15:51, Even Rouault a écrit :

Julien,

To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they 
cannot use
those symbols (if they only link to libgdal). The advantage is that 
it speed-ups

the loading of the library and the resolving of its symbols.
However, it doesn't do what we could expect : in the case the 
application links
with several libraries that define the same symbol (exported or not), 
it has no
influence on how the symbols are resolved by the dynamic linker. So 
depending on

the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol
resolver will choose either the one from GDAL or the one from 
libgeotiff.
OK, I see your point. It works at link time, but not at load time... 
Too bad !


By the way, are you sure that --with-hide-internal-symbols actually 
worsens the
situation ? I'd have bet you'd got the same/similar issues with a 
build that

doesn't use --with-hide-internal-symbols.

No I'm not sure, I didn't test.
So in fact the problem does not come really from 
hide-internal-symbols, but from the simple fact that geotiff is 
included in gdal with a different .



I tried recently to use some trickery based on #define for the 
internal libtiff.
The internal libtiff would have lines (in tif_config.h or in a 
specific header
file imported by it) which would redefine each symbol like #define 
TIFFGetField
GDAL_TIFFGetField. This was easily done with a simple script that 
parsed the
output of nm/objdump -T on libtiff. It mostly worked but I couldn't 
get to work
it completely without modifying the libtiff files, due to their use 
of #define

mechanisms inside libtiff in a few places (in tif_swab.c and
tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the 
libtiff files
as they are directly imported from upstream libtiff. So that effort 
is mostly

stalled for now.

This is the procedure I know as mangling.
I know Insight Toolkit does that (http://www.itk.org) for the internal 
libtiff version, but there are probably some modifications in the 
libtiff code.

If this is not an option for you, then I think we're stuck.


  As far as using ld versionned symbols as Francesco Lovergine
suggested, I've no experience with that mechanism. Perhaps you could 
investigate

on that side.


I don't know about it neither, but I can imagine what versioned 
symbols can mean.
But it does not solve my problem (I want to use the packaged version 
of gdal in Debian and Ubuntu...)



Thanks,
Julien


Even


Hello,

I'm reviving an already known problem about the gdal packages for
Ubuntu/Debian, related to the use of the hide-internal-symbols 
configure

option.

To sum it up, we get into troubles with the gdal packages since we also
use the geotiff API.

Until recently, we knew only about a problem with Debian. It had been
reported for example :
- http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733

A similar issue 

Re: [gdal-dev] geotiff conflict

[Even Rouault]

Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
 Hello,
 
 As it seems like the gdal 1.8 debian package is not out yet, maybe there
 is still some time left to tackle this issue for the next gdal debian
 package.
 
 To sum up the current situation when reading TIFF files with gdal :
 - this program :
 http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx
 segfaults on Debian when linked with -lgeotiff -lgdal but not when
 linked with -lgdal -lgeotiff. It runs fine on Ubuntu
 - this program :
 http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx
 segfaults on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs
 fine when geotiff comes before gdal.
 
 For now, we managed to provide binary packages for the Orfeo Toolbox
 applications on Ubuntu by ensuring geotiff comes before gdal in the link
 list (see https://launchpad.net/~otb). This works because we manage the
 build from begining to end.
 
 But this is a showstopper for our efforts to provide QGis plugins based
 on Orfeo Toolbox : even with the (fragile) solution we ended up with
 (ensuring the order geotiff-gdal in all our link commands), our qgis
 plugins crash as soon as they read a TIFF file on Ubuntu.
 So we are stuck and cannot release binaries of those plugins.

Stupid question (that won't solve the root cause of the problem): why do you 
need direct access to libtiff and libgeotiff ? Can't you do what you need to do 
with the GDAL GTiff driver ?

 
 
 What can we do to help find a solution (what kind of modification to the
 gdal debian package would you agree to make to solve this issue) ?

I'm not sure the solution is really in the debian packaging...

There are indeed very few (safe and easy) options :
- build the GDAL package to link with system/external libtiff and libgeotiff. 
But then you loose bigtiff support
- or make libtiff 4.X the system libtiff version (as in debian experimental)

 Do you have pointers on those versioned symbols you were referring to ?

Not better that what you can find with a search with your favorite search 
engine...

 Are you still against the redefinition of the internal tiff/geotiff
 symbols or is this an option for you (for libtiff, there is already a
 working solution in the InsightToolkit) ? It seems to be the safest
 solution to me.

I haven't watched what InsightToolkit does. Do you have some info ?

If you can come with a solution that doesn't involve modifying the source code 
of libtiff/libgeotiff after it is imported in GDAL source tree, that might be 
worth considering it.

Otherwise if you have a minimum invasive patch that could be upstreamed to the 
libtiff and libgeotiff projects, and conditionnaly enabled with some #ifdef 
that 
could be turned on when included in GDAL, that could perhaps be a viable 
solution. Provided that libtiff/libgeotiff mainteners are OK with that.

 Are we still the only people on Earth linking programs with both gdal
 and geotiff ;) ?

Eh eh, I'd say yes, just so that it becomes a motivation for you to come 
with patch(es) ;-) That's how FOSS evolves...

Best regards,

Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Francesco P. Lovergine]

On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:
  What can we do to help find a solution (what kind of modification to the
  gdal debian package would you agree to make to solve this issue) ?
 
 I'm not sure the solution is really in the debian packaging...
 
 There are indeed very few (safe and easy) options :
 - build the GDAL package to link with system/external libtiff and libgeotiff. 
 But then you loose bigtiff support
 - or make libtiff 4.X the system libtiff version (as in debian experimental)
 
  Do you have pointers on those versioned symbols you were referring to ?
 

Here we go:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268

of course this is a possibile solution to avoid symbol collision among
different libraries. It is not a os-independent solution even, so I would
consider it to solve problems in Debian, not a general (upstream) solution.
This is exactly what I'm going to provide in 1.8/experimental for next
library transition.

-- 
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[MALIK Julien]

Hi Even,


Quoting Even Rouault even.roua...@mines-paris.org:


Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :

Hello,

As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.

To sum up the current situation when reading TIFF files with gdal :
- this program :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx
segfaults on Debian when linked with -lgeotiff -lgdal but not when
linked with -lgdal -lgeotiff. It runs fine on Ubuntu
- this program :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx
segfaults on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs
fine when geotiff comes before gdal.

For now, we managed to provide binary packages for the Orfeo Toolbox
applications on Ubuntu by ensuring geotiff comes before gdal in the link
list (see https://launchpad.net/~otb). This works because we manage the
build from begining to end.

But this is a showstopper for our efforts to provide QGis plugins based
on Orfeo Toolbox : even with the (fragile) solution we ended up with
(ensuring the order geotiff-gdal in all our link commands), our qgis
plugins crash as soon as they read a TIFF file on Ubuntu.
So we are stuck and cannot release binaries of those plugins.


Stupid question (that won't solve the root cause of the problem): why do you
need direct access to libtiff and libgeotiff ? Can't you do what you  
need to do

with the GDAL GTiff driver ?



All this comes from the fact that Orfeo Toolbox has ossim as one of  
its main dependency, and ossim handles TIFF via libgeotiff and not via  
gdal.

For example :
http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossimGeoTiff.cpp
which makes extensive use of the geotiff API.
Other TIFF/GeoTIFF related files are :
imaging/ossimTiffOverviewBuilder.cpp
imaging/ossimTiffWriter.cpp
imaging/ossimTiffTileSource.cpp





What can we do to help find a solution (what kind of modification to the
gdal debian package would you agree to make to solve this issue) ?


I'm not sure the solution is really in the debian packaging...

There are indeed very few (safe and easy) options :
- build the GDAL package to link with system/external libtiff and libgeotiff.
But then you loose bigtiff support


I'm not sure this is an option. Any GIS/remote sensing user dealing  
with TIFF files want bigtiff support I think.



- or make libtiff 4.X the system libtiff version (as in debian experimental)


OK. What prevents from it ? Is it API/ABI incompatible with previous  
versions ?
For example, could libtiff 4.X be packaged in ubuntugis repository and  
not break other packages ?






Do you have pointers on those versioned symbols you were referring to ?


Not better that what you can find with a search with your favorite search
engine...


Are you still against the redefinition of the internal tiff/geotiff
symbols or is this an option for you (for libtiff, there is already a
working solution in the InsightToolkit) ? It seems to be the safest
solution to me.


I haven't watched what InsightToolkit does. Do you have some info ?

If you can come with a solution that doesn't involve modifying the  
source code

of libtiff/libgeotiff after it is imported in GDAL source tree, that might be
worth considering it.


Sadly, I think it involves modification of libtiff sources.




Otherwise if you have a minimum invasive patch that could be  
upstreamed to the
libtiff and libgeotiff projects, and conditionnaly enabled with some  
#ifdef that

could be turned on when included in GDAL, that could perhaps be a viable
solution. Provided that libtiff/libgeotiff mainteners are OK with that.


This crazy idea came to my mind also : a configure option which would  
allow prefixing all symbols exported by libtiff and libgeotiff.
But this means 2 projects to modify. Surely harder to achieve than  
other solution.





Are we still the only people on Earth linking programs with both gdal
and geotiff ;) ?


Eh eh, I'd say yes, just so that it becomes a motivation for you to come
with patch(es) ;-) That's how FOSS evolves...

Best regards,

Even




Thanks a lot for your comments,
Julien






This message was sent using IMP, the Internet Messaging Program.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Even Rouault]

 All this comes from the fact that Orfeo Toolbox has ossim as one of
 its main dependency, and ossim handles TIFF via libgeotiff and not via
 gdal.
 For example :
 http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossi
 mGeoTiff.cpp which makes extensive use of the geotiff API.
 Other TIFF/GeoTIFF related files are :
 imaging/ossimTiffOverviewBuilder.cpp
 imaging/ossimTiffWriter.cpp
 imaging/ossimTiffTileSource.cpp

ok, I guess it is their native tiff reader/writer.

  - or make libtiff 4.X the system libtiff version (as in debian
  experimental)
 
 OK. What prevents from it ? Is it API/ABI incompatible with previous
 versions ?
 For example, could libtiff 4.X be packaged in ubuntugis repository and
 not break other packages ?

No, libtiff 3.X and 4.X are not ABI compatible, and have also a few API 
differences (but that are small enough so that the GDAL GTiff driver can be 
built against both)

 This crazy idea came to my mind also : a configure option which would
 allow prefixing all symbols exported by libtiff and libgeotiff.
 But this means 2 projects to modify. Surely harder to achieve than
 other solution.

The whole question is how to implement such a configuration option.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[MALIK Julien]

Quoting Francesco P. Lovergine fran...@debian.org:


On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:

 What can we do to help find a solution (what kind of modification to the
 gdal debian package would you agree to make to solve this issue) ?

I'm not sure the solution is really in the debian packaging...

There are indeed very few (safe and easy) options :
- build the GDAL package to link with system/external libtiff and  
libgeotiff.

But then you loose bigtiff support
- or make libtiff 4.X the system libtiff version (as in debian experimental)

 Do you have pointers on those versioned symbols you were referring to ?



Here we go:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268

of course this is a possibile solution to avoid symbol collision among
different libraries. It is not a os-independent solution even, so I would
consider it to solve problems in Debian, not a general (upstream) solution.
This is exactly what I'm going to provide in 1.8/experimental for next
library transition.


Oh GREAT !
So I guess the issue will be closed soon. Very, very good news for us  
OrfeoToolbox users.


Thanks so much for considering this !



--
Francesco P. Lovergine







This message was sent using IMP, the Internet Messaging Program.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Francesco P. Lovergine]

On Tue, Apr 26, 2011 at 09:39:21PM +0200, MALIK Julien wrote:
 
 Here we go:
 
 http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268
 
 of course this is a possibile solution to avoid symbol collision among
 different libraries. It is not a os-independent solution even, so I would
 consider it to solve problems in Debian, not a general (upstream) solution.
 This is exactly what I'm going to provide in 1.8/experimental for next
 library transition.
 
 Oh GREAT !
 So I guess the issue will be closed soon. Very, very good news for
 us OrfeoToolbox users.
 
 Thanks so much for considering this !
 

Note that it will sacrify binary compatibility against casual builds.
You will need to build against the Debian version of GDAL, not third
parties builds. 

-- 
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff and the 4th band

[Nicolas Mayer]

Hello

I have a problem with the geotiff (GTiff) driver.

I create a 4-bands raster image in a c++ program. The fourth band was
considered as an alpha band in the geotiff image (actually, it is near
infrared : NIR)

$ gdalinfo new_geotiff.tif
Driver: GTiff/GeoTIFF
Files: new__geotiff.tif
Size is 100, 100
(...)
Band 1 Block=100x20 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=100x20 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=100x20 Type=Byte, ColorInterp=Alpha

How to remove the Color interpretation 'alpha' and the mask flags ?

I want to have :

Band 1 Block=100x20 Type=Byte, ColorInterp=Red
Band 2 Block=100x20 Type=Byte, ColorInterp=Green
Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

I already tryed :
pDS-GetRasterBand(4)-SetColorInterpretation(GCI_Undefined );

I tryed too to set the creation option : ALPHA to NO.


Thanks in advance for any help.

Nicky
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Even Rouault]

Selon Nicolas Mayer nmayer31...@gmail.com:

Retry by setting the PHOTOMETRIC creation option to MINISBLACK. Otherwise, by
default, without specifying it, GDAL assumes that the PHOTOMETRIC is RGB and
that the 4th band is an alpha band.

You should get :
Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

There's no way in the TIFF format to really specify the color interpretation of
each band. The way GDAL builds the color interpretation when reading a TIFF file
is a combination of the value of the PHOTOMETRIC and EXTRASAMPLES tag.

 Hello

 I have a problem with the geotiff (GTiff) driver.

 I create a 4-bands raster image in a c++ program. The fourth band was
 considered as an alpha band in the geotiff image (actually, it is near
 infrared : NIR)

 $ gdalinfo new_geotiff.tif
 Driver: GTiff/GeoTIFF
 Files: new__geotiff.tif
 Size is 100, 100
 (...)
 Band 1 Block=100x20 Type=Byte, ColorInterp=Red
   Mask Flags: PER_DATASET ALPHA
 Band 2 Block=100x20 Type=Byte, ColorInterp=Green
   Mask Flags: PER_DATASET ALPHA
 Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
   Mask Flags: PER_DATASET ALPHA
 Band 4 Block=100x20 Type=Byte, ColorInterp=Alpha

 How to remove the Color interpretation 'alpha' and the mask flags ?

 I want to have :

 Band 1 Block=100x20 Type=Byte, ColorInterp=Red
 Band 2 Block=100x20 Type=Byte, ColorInterp=Green
 Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
 Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

 I already tryed :
 pDS-GetRasterBand(4)-SetColorInterpretation(GCI_Undefined );

 I tryed too to set the creation option : ALPHA to NO.


 Thanks in advance for any help.

 Nicky



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Nicolas Mayer]

Even, thank you very much for answering me so quicly

With the PHOTOMETRIC creation option to MINISBLACK, I get now :
Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

Does this option change anything in the metadatas or in the headers of the
written file ?

But I try to make the same thing as an exemple file I have, which has this
interpretation whith gdalinfo (GDAL 1.7.3) :

Metadata:
  TIFFTAG_IMAGEDESCRIPTION=B3 B2 B1 B4
  TIFFTAG_DATETIME=20050824 18:08:22
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (0.0,0.0)
Lower Left  (0.0, 3000.0)
Upper Right ( 3000.0,0.0)
Lower Right ( 3000.0, 3000.0)
Center  ( 1500.0, 1500.0)
Band 1 Block=3000x500 Type=Byte, ColorInterp=Red
Band 2 Block=3000x500 Type=Byte, ColorInterp=Green
Band 3 Block=3000x500 Type=Byte, ColorInterp=Blue
Band 4 Block=3000x500 Type=Byte, ColorInterp=Undefined

My goal is to have an RGB-Undefined color interpretation.
Have you any idea of the creation option (or driver option ?) to set to have
the same color interpretations ?

Thank you in advance

Nicky



2011/4/18 Even Rouault even.roua...@mines-paris.org

 Selon Nicolas Mayer nmayer31...@gmail.com:

 Retry by setting the PHOTOMETRIC creation option to MINISBLACK. Otherwise,
 by
 default, without specifying it, GDAL assumes that the PHOTOMETRIC is RGB
 and
 that the 4th band is an alpha band.

 You should get :
 Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
 Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
 Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
 Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

 There's no way in the TIFF format to really specify the color
 interpretation of
 each band. The way GDAL builds the color interpretation when reading a TIFF
 file
 is a combination of the value of the PHOTOMETRIC and EXTRASAMPLES tag.

  Hello
 
  I have a problem with the geotiff (GTiff) driver.
 
  I create a 4-bands raster image in a c++ program. The fourth band was
  considered as an alpha band in the geotiff image (actually, it is near
  infrared : NIR)
 
  $ gdalinfo new_geotiff.tif
  Driver: GTiff/GeoTIFF
  Files: new__geotiff.tif
  Size is 100, 100
  (...)
  Band 1 Block=100x20 Type=Byte, ColorInterp=Red
Mask Flags: PER_DATASET ALPHA
  Band 2 Block=100x20 Type=Byte, ColorInterp=Green
Mask Flags: PER_DATASET ALPHA
  Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
Mask Flags: PER_DATASET ALPHA
  Band 4 Block=100x20 Type=Byte, ColorInterp=Alpha
 
  How to remove the Color interpretation 'alpha' and the mask flags ?
 
  I want to have :
 
  Band 1 Block=100x20 Type=Byte, ColorInterp=Red
  Band 2 Block=100x20 Type=Byte, ColorInterp=Green
  Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
  Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
 
  I already tryed :
  pDS-GetRasterBand(4)-SetColorInterpretation(GCI_Undefined );
 
  I tryed too to set the creation option : ALPHA to NO.
 
 
  Thanks in advance for any help.
 
  Nicky
 



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Even Rouault]

Selon Nicolas Mayer nmayer31...@gmail.com:

 Even, thank you very much for answering me so quicly

 With the PHOTOMETRIC creation option to MINISBLACK, I get now :
 Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
 Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
 Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
 Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined

 Does this option change anything in the metadatas or in the headers of the
 written file ?

Yes of course, otherwise how would you explain you get a difference ;-) ? This
change the value of the PHOTOMETRIC tiff tag in TIFF file.


 But I try to make the same thing as an exemple file I have, which has this
 interpretation whith gdalinfo (GDAL 1.7.3) :

 Metadata:
   TIFFTAG_IMAGEDESCRIPTION=B3 B2 B1 B4
   TIFFTAG_DATETIME=20050824 18:08:22
   AREA_OR_POINT=Point
 Image Structure Metadata:
   INTERLEAVE=BAND
 Corner Coordinates:
 Upper Left  (0.0,0.0)
 Lower Left  (0.0, 3000.0)
 Upper Right ( 3000.0,0.0)
 Lower Right ( 3000.0, 3000.0)
 Center  ( 1500.0, 1500.0)
 Band 1 Block=3000x500 Type=Byte, ColorInterp=Red
 Band 2 Block=3000x500 Type=Byte, ColorInterp=Green
 Band 3 Block=3000x500 Type=Byte, ColorInterp=Blue
 Band 4 Block=3000x500 Type=Byte, ColorInterp=Undefined

 My goal is to have an RGB-Undefined color interpretation.
 Have you any idea of the creation option (or driver option ?) to set to have
 the same color interpretations ?

Actually after looking more precisely at the code and a bit of testing, I see
you can obtain the behaviour you wish by specifying both PHOTOMETRIC=RGB and
ALPHA=NO. (ALPHA=NO only will not be sufficient)


 Thank you in advance

 Nicky



 2011/4/18 Even Rouault even.roua...@mines-paris.org

  Selon Nicolas Mayer nmayer31...@gmail.com:
 
  Retry by setting the PHOTOMETRIC creation option to MINISBLACK. Otherwise,
  by
  default, without specifying it, GDAL assumes that the PHOTOMETRIC is RGB
  and
  that the 4th band is an alpha band.
 
  You should get :
  Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
  Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
  Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
  Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
 
  There's no way in the TIFF format to really specify the color
  interpretation of
  each band. The way GDAL builds the color interpretation when reading a TIFF
  file
  is a combination of the value of the PHOTOMETRIC and EXTRASAMPLES tag.
 
   Hello
  
   I have a problem with the geotiff (GTiff) driver.
  
   I create a 4-bands raster image in a c++ program. The fourth band was
   considered as an alpha band in the geotiff image (actually, it is near
   infrared : NIR)
  
   $ gdalinfo new_geotiff.tif
   Driver: GTiff/GeoTIFF
   Files: new__geotiff.tif
   Size is 100, 100
   (...)
   Band 1 Block=100x20 Type=Byte, ColorInterp=Red
 Mask Flags: PER_DATASET ALPHA
   Band 2 Block=100x20 Type=Byte, ColorInterp=Green
 Mask Flags: PER_DATASET ALPHA
   Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
 Mask Flags: PER_DATASET ALPHA
   Band 4 Block=100x20 Type=Byte, ColorInterp=Alpha
  
   How to remove the Color interpretation 'alpha' and the mask flags ?
  
   I want to have :
  
   Band 1 Block=100x20 Type=Byte, ColorInterp=Red
   Band 2 Block=100x20 Type=Byte, ColorInterp=Green
   Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
   Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
  
   I already tryed :
   pDS-GetRasterBand(4)-SetColorInterpretation(GCI_Undefined );
  
   I tryed too to set the creation option : ALPHA to NO.
  
  
   Thanks in advance for any help.
  
   Nicky
  
 
 
 



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Nicolas Mayer]

Even, Thank you very much !

With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain the
same behaviour I whish.

Can you explain me where you found this answer ? (to help me to become more
autonomous with GDAL)

Thank you again

Nicky



2011/4/18 Even Rouault even.roua...@mines-paris.org

 Selon Nicolas Mayer nmayer31...@gmail.com:

  Even, thank you very much for answering me so quicly
 
  With the PHOTOMETRIC creation option to MINISBLACK, I get now :
  Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
  Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
  Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
  Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
 
  Does this option change anything in the metadatas or in the headers of
 the
  written file ?

 Yes of course, otherwise how would you explain you get a difference ;-) ?
 This
 change the value of the PHOTOMETRIC tiff tag in TIFF file.

 
  But I try to make the same thing as an exemple file I have, which has
 this
  interpretation whith gdalinfo (GDAL 1.7.3) :
 
  Metadata:
TIFFTAG_IMAGEDESCRIPTION=B3 B2 B1 B4
TIFFTAG_DATETIME=20050824 18:08:22
AREA_OR_POINT=Point
  Image Structure Metadata:
INTERLEAVE=BAND
  Corner Coordinates:
  Upper Left  (0.0,0.0)
  Lower Left  (0.0, 3000.0)
  Upper Right ( 3000.0,0.0)
  Lower Right ( 3000.0, 3000.0)
  Center  ( 1500.0, 1500.0)
  Band 1 Block=3000x500 Type=Byte, ColorInterp=Red
  Band 2 Block=3000x500 Type=Byte, ColorInterp=Green
  Band 3 Block=3000x500 Type=Byte, ColorInterp=Blue
  Band 4 Block=3000x500 Type=Byte, ColorInterp=Undefined
 
  My goal is to have an RGB-Undefined color interpretation.
  Have you any idea of the creation option (or driver option ?) to set to
 have
  the same color interpretations ?

 Actually after looking more precisely at the code and a bit of testing, I
 see
 you can obtain the behaviour you wish by specifying both PHOTOMETRIC=RGB
 and
 ALPHA=NO. (ALPHA=NO only will not be sufficient)

 
  Thank you in advance
 
  Nicky
 
 
 
  2011/4/18 Even Rouault even.roua...@mines-paris.org
 
   Selon Nicolas Mayer nmayer31...@gmail.com:
  
   Retry by setting the PHOTOMETRIC creation option to MINISBLACK.
 Otherwise,
   by
   default, without specifying it, GDAL assumes that the PHOTOMETRIC is
 RGB
   and
   that the 4th band is an alpha band.
  
   You should get :
   Band 1 Block=100x20 Type=Byte, ColorInterp=Gray
   Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined
   Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined
   Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
  
   There's no way in the TIFF format to really specify the color
   interpretation of
   each band. The way GDAL builds the color interpretation when reading a
 TIFF
   file
   is a combination of the value of the PHOTOMETRIC and EXTRASAMPLES tag.
  
Hello
   
I have a problem with the geotiff (GTiff) driver.
   
I create a 4-bands raster image in a c++ program. The fourth band was
considered as an alpha band in the geotiff image (actually, it is
 near
infrared : NIR)
   
$ gdalinfo new_geotiff.tif
Driver: GTiff/GeoTIFF
Files: new__geotiff.tif
Size is 100, 100
(...)
Band 1 Block=100x20 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=100x20 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=100x20 Type=Byte, ColorInterp=Alpha
   
How to remove the Color interpretation 'alpha' and the mask flags ?
   
I want to have :
   
Band 1 Block=100x20 Type=Byte, ColorInterp=Red
Band 2 Block=100x20 Type=Byte, ColorInterp=Green
Band 3 Block=100x20 Type=Byte, ColorInterp=Blue
Band 4 Block=100x20 Type=Byte, ColorInterp=Undefined
   
I already tryed :
pDS-GetRasterBand(4)-SetColorInterpretation(GCI_Undefined );
   
I tryed too to set the creation option : ALPHA to NO.
   
   
Thanks in advance for any help.
   
Nicky
   
  
  
  
 



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Even Rouault]

Selon Nicolas Mayer nmayer31...@gmail.com:

 Even, Thank you very much !

 With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain the
 same behaviour I whish.

 Can you explain me where you found this answer ? (to help me to become more
 autonomous with GDAL)


Well, for an advanced question like this... by looking directly at the logic
exposed in the source code : between the lines 6809 and 6960 of
http://trac.osgeo.org/gdal/export/22203/trunk/gdal/frmts/gtiff/geotiff.cpp
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff and the 4th band

[Nicolas Mayer]

OK. Thank you very much.
Nicky


2011/4/18 Even Rouault even.roua...@mines-paris.org

 Selon Nicolas Mayer nmayer31...@gmail.com:

  Even, Thank you very much !
 
  With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain
 the
  same behaviour I whish.
 
  Can you explain me where you found this answer ? (to help me to become
 more
  autonomous with GDAL)
 

 Well, for an advanced question like this... by looking directly at the
 logic
 exposed in the source code : between the lines 6809 and 6960 of
 http://trac.osgeo.org/gdal/export/22203/trunk/gdal/frmts/gtiff/geotiff.cpp

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF to Shapefile

[Emilio de Torres Fernández]

Hello,

I have GeoTIFF files and need to get a shapefile with the contour of
each one. The aim of this conversion is to display on a world map the
areas which I have satellite images using a WMS service with MapServer.

What free tool can I use?

Best regards.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF to Shapefile

[Daniele Romagnoli]

Hi Emilio,
I think you could use the gdaltindex tool:
http://www.gdal.org/gdaltindex.html

Hope this helps.
Regards,
Daniele

2011/3/24 Emilio de Torres Fernández emilio.detor...@fueca.es

 Hello,

 I have GeoTIFF files and need to get a shapefile with the contour of
 each one. The aim of this conversion is to display on a world map the
 areas which I have satellite images using a WMS service with MapServer.

 What free tool can I use?

 Best regards.

 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
---
Ing. Daniele Romagnoli
GeoSolutions S.A.S.
Software Engineer

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:   +39 328 0559267

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://it.linkedin.com/in/danieleromagnoli


---
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] geotiff conflict

[Julien Malik]

Hello,

I'm reviving an already known problem about the gdal packages for 
Ubuntu/Debian, related to the use of the hide-internal-symbols configure 
option.


To sum it up, we get into troubles with the gdal packages since we also 
use the geotiff API.


Until recently, we knew only about a problem with Debian. It had been 
reported for example :

- http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733

A similar issue now appears on Ubuntu.
Attached are two little tests showing up the problem, with an associated 
CMakeLists.

test.cxx uses the geotiff and tiff API.
test2.cxx is the test program reported in the debian bug tracker

both programs are simple executable taking one tiff file as input.

test.cxx produces segfault when the link line has gdal before geotiff, 
and runs ok in the other cases (tiff does not seem involved).
The segfault appears in the TIFFGetField call, probably because the 
TIFF* returned by XTIFFOpen comes from the gdal internal geotiff 
implementation and not the system geotiff lib, thus returning an 
incompatible pointer.


test2.cxx does not segfault (though it does on Debian systems when gdal 
is before geotiff).


I see the Ubuntu problems on at least two systems :
- Ubuntu 10.04 with official packages (gdal 1.6.3)
- Ubuntu 10.10 with gdal package from UbuntuGIS-unstable

There seems to be a bug with the hide-internal-symbols which, well..., 
does not really hide internal symbols.
Is there a known solution to these problems (apart from hand-made gdal 
recompilation which is not a solution for our end-users) ?

Has the mangling of the internal tiff/geotiff libs already been studied ?


Best regards,
Julien




gdalgeotiff.tar.gz
Description: GNU Zip compressed data
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Even Rouault]

Julien,

To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they cannot use
those symbols (if they only link to libgdal). The advantage is that it speed-ups
the loading of the library and the resolving of its symbols.

However, it doesn't do what we could expect : in the case the application links
with several libraries that define the same symbol (exported or not), it has no
influence on how the symbols are resolved by the dynamic linker. So depending on
the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol
resolver will choose either the one from GDAL or the one from libgeotiff.

By the way, are you sure that --with-hide-internal-symbols actually worsens the
situation ? I'd have bet you'd got the same/similar issues with a build that
doesn't use --with-hide-internal-symbols.

I tried recently to use some trickery based on #define for the internal libtiff.
The internal libtiff would have lines (in tif_config.h or in a specific header
file imported by it) which would redefine each symbol like #define TIFFGetField
GDAL_TIFFGetField. This was easily done with a simple script that parsed the
output of nm/objdump -T on libtiff. It mostly worked but I couldn't get to work
it completely without modifying the libtiff files, due to their use of #define
mechanisms inside libtiff in a few places (in tif_swab.c and
tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the libtiff files
as they are directly imported from upstream libtiff. So that effort is mostly
stalled for now. As far as using ld versionned symbols as Francesco Lovergine
suggested, I've no experience with that mechanism. Perhaps you could investigate
on that side.

Even

 Hello,

 I'm reviving an already known problem about the gdal packages for
 Ubuntu/Debian, related to the use of the hide-internal-symbols configure
 option.

 To sum it up, we get into troubles with the gdal packages since we also
 use the geotiff API.

 Until recently, we knew only about a problem with Debian. It had been
 reported for example :
 - http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733

 A similar issue now appears on Ubuntu.
 Attached are two little tests showing up the problem, with an associated
 CMakeLists.
 test.cxx uses the geotiff and tiff API.
 test2.cxx is the test program reported in the debian bug tracker

 both programs are simple executable taking one tiff file as input.

 test.cxx produces segfault when the link line has gdal before geotiff,
 and runs ok in the other cases (tiff does not seem involved).
 The segfault appears in the TIFFGetField call, probably because the
 TIFF* returned by XTIFFOpen comes from the gdal internal geotiff
 implementation and not the system geotiff lib, thus returning an
 incompatible pointer.

 test2.cxx does not segfault (though it does on Debian systems when gdal
 is before geotiff).

 I see the Ubuntu problems on at least two systems :
 - Ubuntu 10.04 with official packages (gdal 1.6.3)
 - Ubuntu 10.10 with gdal package from UbuntuGIS-unstable

 There seems to be a bug with the hide-internal-symbols which, well...,
 does not really hide internal symbols.
 Is there a known solution to these problems (apart from hand-made gdal
 recompilation which is not a solution for our end-users) ?
 Has the mangling of the internal tiff/geotiff libs already been studied ?


 Best regards,
 Julien





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff conflict

[Julien Michel]

Even,

I am working with Julien on the same project, and you are right about 
the --hide-internal-symbols option : if symbols are not hidden, we 
recognize that gdal exposes tiff symbols and we manage to deal with this 
case by forcing all tiff access to use gdal internal tiff library (we 
have to include the headers in gdal sources in order to be sure to have 
headers corresponding to symbols, it would be great to have these 
headers installed by gdal, but this is another question). And the case 
were gdal links with the system tiff/geotiff is working as well (but 
without bigtiff support).


The problem is that we are trying to build debian/ubuntu packages, and 
to do it we need to link with the system gdal , which is compiled with 
--hide-internal-symbols, so we are kind of stuck here ...


I am surprised that this issue has not been reported before, we are for 
sure not the only project using both gdal and geotiff  ? My bet is that 
we are doing something wrong somewhere, but for now we did not come up 
with it. Any idea would be very helpful ...


Regards,

Julien

Le 29/11/2010 15:51, Even Rouault a écrit :

Julien,

To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they cannot use
those symbols (if they only link to libgdal). The advantage is that it speed-ups
the loading of the library and the resolving of its symbols.

However, it doesn't do what we could expect : in the case the application links
with several libraries that define the same symbol (exported or not), it has no
influence on how the symbols are resolved by the dynamic linker. So depending on
the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol
resolver will choose either the one from GDAL or the one from libgeotiff.

By the way, are you sure that --with-hide-internal-symbols actually worsens the
situation ? I'd have bet you'd got the same/similar issues with a build that
doesn't use --with-hide-internal-symbols.

I tried recently to use some trickery based on #define for the internal libtiff.
The internal libtiff would have lines (in tif_config.h or in a specific header
file imported by it) which would redefine each symbol like #define TIFFGetField
GDAL_TIFFGetField. This was easily done with a simple script that parsed the
output of nm/objdump -T on libtiff. It mostly worked but I couldn't get to work
it completely without modifying the libtiff files, due to their use of #define
mechanisms inside libtiff in a few places (in tif_swab.c and
tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the libtiff files
as they are directly imported from upstream libtiff. So that effort is mostly
stalled for now. As far as using ld versionned symbols as Francesco Lovergine
suggested, I've no experience with that mechanism. Perhaps you could investigate
on that side.

Even

   

Hello,

I'm reviving an already known problem about the gdal packages for
Ubuntu/Debian, related to the use of the hide-internal-symbols configure
option.

To sum it up, we get into troubles with the gdal packages since we also
use the geotiff API.

Until recently, we knew only about a problem with Debian. It had been
reported for example :
- http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733

A similar issue now appears on Ubuntu.
Attached are two little tests showing up the problem, with an associated
CMakeLists.
test.cxx uses the geotiff and tiff API.
test2.cxx is the test program reported in the debian bug tracker

both programs are simple executable taking one tiff file as input.

test.cxx produces segfault when the link line has gdal before geotiff,
and runs ok in the other cases (tiff does not seem involved).
The segfault appears in the TIFFGetField call, probably because the
TIFF* returned by XTIFFOpen comes from the gdal internal geotiff
implementation and not the system geotiff lib, thus returning an
incompatible pointer.

test2.cxx does not segfault (though it does on Debian systems when gdal
is before geotiff).

I see the Ubuntu problems on at least two systems :
- Ubuntu 10.04 with official packages (gdal 1.6.3)
- Ubuntu 10.10 with gdal package from UbuntuGIS-unstable

There seems to be a bug with the hide-internal-symbols which, well...,
does not really hide internal symbols.
Is there a known solution to these problems (apart from hand-made gdal
recompilation which is not a solution for our end-users) ?
Has the mangling of the internal tiff/geotiff libs already been studied ?


Best regards,
Julien



 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

   



--
Julien MICHEL

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org

Re: [gdal-dev] geotiff conflict

[Julien Malik]

Hello Even,

Thank you for your answer.

Le 29/11/2010 15:51, Even Rouault a écrit :

Julien,

To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they cannot use
those symbols (if they only link to libgdal). The advantage is that it speed-ups
the loading of the library and the resolving of its symbols.
However, it doesn't do what we could expect : in the case the application links
with several libraries that define the same symbol (exported or not), it has no
influence on how the symbols are resolved by the dynamic linker. So depending on
the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol
resolver will choose either the one from GDAL or the one from libgeotiff.
OK, I see your point. It works at link time, but not at load time... 
Too bad !



By the way, are you sure that --with-hide-internal-symbols actually worsens the
situation ? I'd have bet you'd got the same/similar issues with a build that
doesn't use --with-hide-internal-symbols.

No I'm not sure, I didn't test.
So in fact the problem does not come really from hide-internal-symbols, 
but from the simple fact that geotiff is included in gdal with a different .




I tried recently to use some trickery based on #define for the internal libtiff.
The internal libtiff would have lines (in tif_config.h or in a specific header
file imported by it) which would redefine each symbol like #define TIFFGetField
GDAL_TIFFGetField. This was easily done with a simple script that parsed the
output of nm/objdump -T on libtiff. It mostly worked but I couldn't get to work
it completely without modifying the libtiff files, due to their use of #define
mechanisms inside libtiff in a few places (in tif_swab.c and
tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the libtiff files
as they are directly imported from upstream libtiff. So that effort is mostly
stalled for now.

This is the procedure I know as mangling.
I know Insight Toolkit does that (http://www.itk.org) for the internal 
libtiff version, but there are probably some modifications in the 
libtiff code.

If this is not an option for you, then I think we're stuck.


  As far as using ld versionned symbols as Francesco Lovergine
suggested, I've no experience with that mechanism. Perhaps you could investigate
on that side.


I don't know about it neither, but I can imagine what versioned 
symbols can mean.
But it does not solve my problem (I want to use the packaged version of 
gdal in Debian and Ubuntu...)



Thanks,
Julien


Even


Hello,

I'm reviving an already known problem about the gdal packages for
Ubuntu/Debian, related to the use of the hide-internal-symbols configure
option.

To sum it up, we get into troubles with the gdal packages since we also
use the geotiff API.

Until recently, we knew only about a problem with Debian. It had been
reported for example :
- http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733

A similar issue now appears on Ubuntu.
Attached are two little tests showing up the problem, with an associated
CMakeLists.
test.cxx uses the geotiff and tiff API.
test2.cxx is the test program reported in the debian bug tracker

both programs are simple executable taking one tiff file as input.

test.cxx produces segfault when the link line has gdal before geotiff,
and runs ok in the other cases (tiff does not seem involved).
The segfault appears in the TIFFGetField call, probably because the
TIFF* returned by XTIFFOpen comes from the gdal internal geotiff
implementation and not the system geotiff lib, thus returning an
incompatible pointer.

test2.cxx does not segfault (though it does on Debian systems when gdal
is before geotiff).

I see the Ubuntu problems on at least two systems :
- Ubuntu 10.04 with official packages (gdal 1.6.3)
- Ubuntu 10.10 with gdal package from UbuntuGIS-unstable

There seems to be a bug with the hide-internal-symbols which, well...,
does not really hide internal symbols.
Is there a known solution to these problems (apart from hand-made gdal
recompilation which is not a solution for our end-users) ?
Has the mangling of the internal tiff/geotiff libs already been studied ?


Best regards,
Julien




___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geotiff with bands of different type

[Martin Raspaud]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I'm using gdal/python and I would like to create geotiffs using one band of
bytes and one of float32s...

Is this even possible ?

Thanks,
Martin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMYPxfAAoJEBdvyODiyJI4k1kH/0JQBE/wSlR3yDLP/OljCMsE
YgLEji5Hs6u2dtaDu/uIsxViKsLfIX4wZIp0VA5o2QhdW/Y+oBq9s5kKTEbLrsNd
kWl80/qTVX7xyOcV36hcbtPDbRxnxdIbnWSZi36U+aFLh4D0Sm+n8JX+++SglZ3W
TcCdgDG9PYCQE1bcFfNOB82kOdFKFDuDR16rZFV/eSpUZLgAHfoYmZC6SJhQOjaa
GhpdcMPyn8un1Hu/5pT50tq9Dm11oDF3gRAQUQo3cjhn6+frfjimjXhMzDTZZm7T
V23Dq5Ok/qLq2JjWXhjiNJnAWDKCSZI6K+zD4OAW1Oo28+ElaDS3VsGr2twN/Zk=
=9RL2
-END PGP SIGNATURE-
attachment: martin_raspaud.vcf___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff with bands of different type

[Chaitanya kumar CH]

Martin,

Yes, it is possible.
You can specify the data type in GDALDataset::AddBand()

On Tue, Aug 10, 2010 at 12:44 PM, Martin Raspaud martin.rasp...@smhi.sewrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all,

 I'm using gdal/python and I would like to create geotiffs using one band of
 bytes and one of float32s...

 Is this even possible ?

 Thanks,
 Martin
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff with bands of different type

[Martin Raspaud]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chaitanya kumar CH skrev:
 Martin,
 
 I'm sorry. I just found out that GDALDataset::AddBand() is not supported
 by most format drivers.  GeoTiff format driver doesn't support it. 
 Also, having different data types for bands may confuse some applications.
 
 If you are trying to create a mask band, refer to
 http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask
 
 FYI, 1.5 branch is no longer supported.

Hi,

Ok, here is a little description of what I try to achieve:
We have a satellite image in black and white, which show IR brightness
temperatures. The data is scaled between 0 and 255 for viewing, and this is
packed in a geotiff file

Now some users would like to have the true value of the brightness temperature
embedded in the file also.

But unfortunately it doesn't seem possible to do with geotiff...

Thanks for your help.

Martin

PS: we are about to switch to gdal 1.6.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMYS3oAAoJEBdvyODiyJI4NkUH/0i2jLP1qiHSMNmu9Al0Bmev
UoezlTLUuRLPS0fZj9kaJ0mLygcP3w8uBFNCvCivlYE2feBJYZSPv5+pVt9T5LdY
mRUauJ2383ugdWWJ/ceCZKuI2wpCQjBUBtKf+Qicj6Lpk4qqUZattvBkfbWs8yKe
1jT9ZNMJB5bbOFKLmYNaHkbzc+DgzI1FM0fvT9U6vWuoARKL3S/0+Nn+fgVNrSuq
i4WA+y+ThhZ0VviekljB/lhstAYMsWjq8erlMzdiIqMH8vTc4NcwKbSZTDWf5ctw
YYN3/UF63TnkYSdijGVg0YenQPzD2gJJF3N21czA6uHVLCYwnsQMhsz16D1Mhwk=
=9XSz
-END PGP SIGNATURE-
attachment: martin_raspaud.vcf___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTiff null values

[Filippo Corò]

Hi List,

I'm running tests with GDAL 1.7 and python  for achieving a function for  
the sum of GeoTIFF file. I found some difficulty in handling null values.
I wanted to know if you can assign a specific value (like 99) to null when  
I call the Open function.


The code is as follows:

# Open the image 1
primoDs=gdal.Open('eros.tif', GA_ReadOnly)

primoBand=primoDs.GetRasterBand(1)

If I use the following function:

noval=primoBand.GetNoDataValue()
print noval

I get:

0.0 with null value:

Is there any statement at this stage allow me to decide what value to  
assign to null, when I call gdal.open?


Thanks in Advance

Filippo Corò


--
Creato con il rivoluzionario client e-mail di Opera:  
http://www.opera.com/mail/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTiff null values

[Chaitanya kumar CH]

Filippo,

Please note that those values are called nodata values.

Nodata value is assigned a specific value during the creation of the raster
and all the pixels where data is unavailable are assigned that value.
Using the python interface, you can find the specified value with
GetNoDataValue(). You can compare it with None to check if a value is set.

if band.GetNoDataValue() != None:
print band.GetNoDataValue()
else:
print 'nodata not set'

You cannot reset all the nodata pixels of a raster band directly. You can
create a VRT file to do this. The VRT driver can translate the nodata value
from the underlying dataset to the value you specify with
NoDataValue99/NoDataValue. http://www.gdal.org/gdal_vrttut.html

On Fri, Jul 30, 2010 at 11:44 AM, Filippo Corò filippo.c...@alice.itwrote:


 Hi List,

 I'm running tests with GDAL 1.7 and python  for achieving a function for
 the sum of GeoTIFF file. I found some difficulty in handling null values.
 I wanted to know if you can assign a specific value (like 99) to null when
 I call the Open function.

 The code is as follows:

 # Open the image 1
 primoDs=gdal.Open('eros.tif', GA_ReadOnly)

 primoBand=primoDs.GetRasterBand(1)

 If I use the following function:

 noval=primoBand.GetNoDataValue()
 print noval

 I get:

 0.0 with null value:

 Is there any statement at this stage allow me to decide what value to
 assign to null, when I call gdal.open?

 Thanks in Advance

 Filippo Corò


 --
 Creato con il rivoluzionario client e-mail di Opera:
 http://www.opera.com/mail/
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff AREA_OR_POINT

[Michael Sumner]

 Am I correct in interpreting this post to mean that the pixel-is-area and 
 pixel-is-point tiffs are read the exact same way by GDAL, with the only 
 difference being in the value of the AREA_OR_POINT metadata key? Should 
 viewers then be looking for the AREA_OR_POINT key in addition to the 
 georeferencing information, and shift the display to center the top-left 
 pixel on (0,0) if it's set to Point?

That's my understanding, it's just a metadata tag there for use if you
need it. I would say that viewers should only modify their behaviour
from Area if they have the distinction for centre point vs. cell based
views.

I've seen it used to set  centre-based TIN-like renderings, vs.
cell-based image renderings - but there's nothing in the GDAL raster
storage model that prevents you taking on either interpretation AFAIK,
though the default is cell-based.

(There can be a problem interpreting more flexible array formats like
NetCDF, that can store irregularly spaced coordinate vectors for, say,
the centres of cells on the X axis - and there's rarely any metadata
(in the file) to say explicitly that it's centre- not corner-based.  )

Cheers, Mike.

On Tue, Jun 29, 2010 at 8:12 AM, Gillian WALTER
gwal...@mdacorporation.com wrote:
 Hi,

 I'm trying to wrap my head around Geotiff's AREA_OR_POINT=Area versus
 AREA_OR_POINT=Point, and how that translates into GDAL.  I've  read the
 PixelIsPoint Raster Space and PixelIsArea Raster Space sections of the
 geotiff spec, and tried to find previous posts on the topic with very
 limited success (
 http://osgeo-org.1803224.n2.nabble.com/GRASS-Problem-importing-geotiff-with-r-in-gdal-td1879130.html
 ).  Am I correct in interpreting this post to mean that the pixel-is-area
 and pixel-is-point tiffs are read the exact same way by GDAL, with the only
 difference being in the value of the AREA_OR_POINT metadata key?  Should
 viewers then be looking for the AREA_OR_POINT key in addition to the
 georeferencing information, and shift the display to center the top-left
 pixel on (0,0) if it's set to Point?

 Thanks,

 Gillian Walter
 Software Developer
 Geospatial Services Inc.
 57 Auriga Drive - Suite 201
 Ottawa, ON K2E 8B2
 Telephone:  (613) 727-1087 #245
 Facsimile:  (613) 727-5853
 Email:  gwal...@mdacorporation.com

 This e-mail and any attachments are intended solely for the use of the
 intended recipient(s) and may contain legally privileged, proprietary and/or
 confidential information.  Any use, disclosure, dissemination, distribution
 or copying of this e-mail and any attachments for any purposes that have not
 been specifically authorized by the sender is strictly prohibited.  If you
 are not the intended recipient, please immediately notify the sender by
 reply e-mail and permanently delete all copies and attachments.  The entire
 content of this e-mail is for information purposes only and should not be
 relied upon by the recipient in any way unless otherwise confirmed in
 writing by way of letter or facsimile.


 ___
 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

Re: [gdal-dev] Geotiff AREA_OR_POINT

[Joaquim Luis]

On 28-06-2010 23:21, Michael Sumner wrote:

Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffsare 
read the exact same way by GDAL, with the only difference being in the value of theAREA_OR_POINT 
metadata key? Should viewers then be looking forthe AREA_OR_POINT key in addition to 
the georeferencing information, and shift thedisplay to center the top-left pixel on (0,0) if 
it's set to Point?
 

That's my understanding, it's just a metadata tag there for use if you
need it. I would say that viewers should only modify their behaviour
from Area if they have the distinction for centre point vs. cell based
views.

I've seen it used to set  centre-based TIN-like renderings, vs.
cell-based image renderings - but there's nothing in the GDAL raster
storage model that prevents you taking on either interpretation AFAIK,
though the default is cell-based.
   




(There can be a problem interpreting more flexible array formats like
NetCDF, that can store irregularly spaced coordinate vectors for, say,
the centres of cells on the X axis - and there's rarely any metadata
(in the file) to say explicitly that it's centre- not corner-based.  )

Cheers, Mike.
   



netCDF grids created by GMT have always (~20 years) made that 
distinction and store that information.


Joaquim

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotiff AREA_OR_POINT

[Michael Sumner]

Thanks for the heads up, I've not used GMT versions of NetCDF much, or
recently. The vast majority of NetCDF I've had to work with do not
make this explicit, and this is about the most detailed discussion
I've seen:

http://www.mail-archive.com/cf-metad...@cgd.ucar.edu/msg00566.html

Cheers, Mike.

On Tue, Jun 29, 2010 at 8:33 AM, Joaquim Luis jl...@ualg.pt wrote:
 netCDF grids created by GMT have always (~20 years) made that distinction
 and store that information.

 Joaquim


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev