Re: [gdal-dev] Motion: Approve GDAL/OGR 1.11.1RC1 for release

[Even Rouault]

Le dimanche 28 septembre 2014 14:19:39, Even Rouault a écrit :
> Hi,
> 
> No issue has been specifically reported on RC1 so far (*), so I invite PSC
> members to vote on this motion after doing your own testing and validation.
> Input from everyone else who can test it is also very welcome.
> 
> (*) Robert Coup raised to me that the 1.11 branch still contains the OGR
> WCTS code that has the security issues explained in
> http://lists.osgeo.org/pipermail/gdal-dev/2014-September/040084.html .
> Perhaps we can let it as such and add a notice in
> http://trac.osgeo.org/gdal/wiki/Release/1.11.1-News ?
> 
> ---
> 
> Motion: The GDAL/OGR 1.11.1RC1 package is promoted as the
> final GDAL/OGR 1.11.1 release.

I declare this motion as passed with +1 from TamasS, JukkaR, HowardB and me, 
and +0 from DanielM

I'm going to rename the RC to final and the release announcement will follow 
shortly.

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] GDAL/OGR 1.11.1 released

[Even Rouault]

Hi,

On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.11.1 bug fix release.  This
release contains more than 80 bug fixes since the April 1.11.0 release.

The source is available at:

  http://download.osgeo.org/gdal/1.11.1/gdal-1.11.1.tar.xz
  http://download.osgeo.org/gdal/1.11.1/gdal-1.11.1.tar.gz
  http://download.osgeo.org/gdal/1.11.1/gdal.zip

Details on the the fixes in this release, and a security announcement, are 
available at:
  http://trac.osgeo.org/gdal/wiki/Release/1.11.1-News

Best regards,

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] Importing completely MITAB into GDAL source tree ?

[Even Rouault]

Hi,

As some of you know, the OGR MapInfo driver heavily depends on the source code 
of the MITAB library. Over the years, people have contributed fixes and 
improvements through GDAL. Not all those changes have made their way in the 
official MITAB repository that sits at https://github.com/mapgears/mitab and 
which has not evolved a lot in comparison to its copy in OGR.
Maintaining 2 copies and synchronizing them is a time consuming and error-
prone process.
On the other hand, there are still people that depend on the standalone MITAB 
library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm 
wondering if it wouldn't be more efficient to import those specific remaining 
parts (standalone build scripts, C API and utilities) into the GDAL source 
tree (probably a ogr/ogrsf_frmts/mitab/build and ogr/ogrsf_frmts/mitab/apps)
That way both projects would share the same code in a very obvious way, while 
keeping their specificities.

Thoughts ?

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] Binary Predicates in SQLite SQL dialect

[Andre Vautour]

On 2014-09-30 17:08, Even Rouault wrote:

Le mardi 30 septembre 2014 20:20:14, Andre Vautour a écrit :

Hi all,

I am trying to use a geometry binary predicate (ST_Intersects) in
ExecuteSQL() with the SQLite dialect and keep getting back an
"ST_Intersect function does not exist" error back from SQLite.

GDAL is built with SpatiaLite (HAVE_SPATIALITE is defined), but I
believe the problem is that SpatiaLite is built without GEOS in our
case, so those predicate functions end-up not being available in
SpatiaLite. The end result is that OGRSQLiteRegisterSQLFunctions does
not add the OGR-based predicate functions as SpatiaLite is present, but
SpatiaLite does not contain the predicate functions.

I would build SpatiaLite with GEOS support, but unfortunately its LGPL
licensing is too restrictive for our application. So, would it make
sense to change the logic in OGRSQLiteRegisterSQLFunctions to account
for the case of SpatiaLite being built without GEOS?

Andre,

That makes sense. I guess that can only be checked at runtime though, probably
by issuing a ST_Intersects() and checking the error code.

I'd note that the spatial predicates in OGR geometry are also based on GEOS.
Except OGRGeometry::Intersects() that has a simplified implementation based on
bounding box intersection when GEOS is not available.

Some time ago, I had a look at boost geometry (
http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/index.html  ). That
could be used as an alternative backend to GEOS for most predicates and
functions returning geometries, and the boost licence is a modified X/MIT.
In that case, I might lean towards implementing the binary predicates as 
SQLite functions at our level given that we have a proprietary 
implementation of ISO 19107.


In order to do so, I'd need to have a way to add functions to the 
created sqlite3 object. Assuming we cache the sqlite data source between 
SQL executions, one option would be to enable the loadable extensions on 
the created sqlite3 object like is done in 
sqlite\test_load_virtual_ogr.c using sqlite3_enable_load_extension(). I 
could then call ExcuteSQL() with "SELECT load_extension(...)". Another 
option would be to expose a callback that would allow an application to 
add functions to an SQLite database when it is created, that is, expose 
something similar to OGR2SQLITEModule::SetHandleSQLFunctions().


Yet another option would be to allow for an extension point by 
introducing something like an OverlayStrategy and having the default be 
the GEOSOverlayStrategy. That would allow for the boost::geometry 
extension point you were talking about, and allow applications that have 
their own geometry library like us to use their in house implementation 
for predicates and overlays.


Would you guys be willing to take one of those options?

Thanks again,
André


Even



--
*André Vautour*, B.Sc.
Application Developer
CARIS 
115 Waggoners Lane
Fredericton, New Brunswick
CanadaE3B 2L4
Tel: +1.506.458.8533 Fax: +1.506.459.3849
www.caris.com 

*Connect with CARIS*
Twitter  LinkedIn 
 FaceBook 
 
YouTube 


Download your free copy of CARIS Easy View today!
www.caris.com/easyview 

_
This email and any files transmitted with it are confidential and 
intended only for the addressee(s). If you are not the intended 
recipient(s) please notify us by email reply. You should not use, 
disclose, distribute or copy this communication if received in error.


Any views or opinions expressed in this email are solely those of the 
author and do not necessarily represent those of the company. No binding 
contract will result from this email until such time as a written 
document is signed on behalf of the company.


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

Re: [gdal-dev] Binary Predicates in SQLite SQL dialect

[Even Rouault]

Le mercredi 01 octobre 2014 14:49:27, vous avez écrit :
> On 2014-09-30 17:08, Even Rouault wrote:
> > Le mardi 30 septembre 2014 20:20:14, Andre Vautour a écrit :
> >> Hi all,
> >> 
> >> I am trying to use a geometry binary predicate (ST_Intersects) in
> >> ExecuteSQL() with the SQLite dialect and keep getting back an
> >> "ST_Intersect function does not exist" error back from SQLite.
> >> 
> >> GDAL is built with SpatiaLite (HAVE_SPATIALITE is defined), but I
> >> believe the problem is that SpatiaLite is built without GEOS in our
> >> case, so those predicate functions end-up not being available in
> >> SpatiaLite. The end result is that OGRSQLiteRegisterSQLFunctions does
> >> not add the OGR-based predicate functions as SpatiaLite is present, but
> >> SpatiaLite does not contain the predicate functions.
> >> 
> >> I would build SpatiaLite with GEOS support, but unfortunately its LGPL
> >> licensing is too restrictive for our application. So, would it make
> >> sense to change the logic in OGRSQLiteRegisterSQLFunctions to account
> >> for the case of SpatiaLite being built without GEOS?
> > 
> > Andre,
> > 
> > That makes sense. I guess that can only be checked at runtime though,
> > probably by issuing a ST_Intersects() and checking the error code.
> > 
> > I'd note that the spatial predicates in OGR geometry are also based on
> > GEOS. Except OGRGeometry::Intersects() that has a simplified
> > implementation based on bounding box intersection when GEOS is not
> > available.
> > 
> > Some time ago, I had a look at boost geometry (
> > http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/index.html 
> > ). That could be used as an alternative backend to GEOS for most
> > predicates and functions returning geometries, and the boost licence is
> > a modified X/MIT.
> 
> In that case, I might lean towards implementing the binary predicates as
> SQLite functions at our level given that we have a proprietary
> implementation of ISO 19107.
> 
> In order to do so, I'd need to have a way to add functions to the
> created sqlite3 object. Assuming we cache the sqlite data source between
> SQL executions, one option would be to enable the loadable extensions on
> the created sqlite3 object like is done in
> sqlite\test_load_virtual_ogr.c using sqlite3_enable_load_extension(). I
> could then call ExcuteSQL() with "SELECT load_extension(...)". Another
> option would be to expose a callback that would allow an application to
> add functions to an SQLite database when it is created, that is, expose
> something similar to OGR2SQLITEModule::SetHandleSQLFunctions().
> 
> Yet another option would be to allow for an extension point by
> introducing something like an OverlayStrategy and having the default be
> the GEOSOverlayStrategy. That would allow for the boost::geometry
> extension point you were talking about, and allow applications that have
> their own geometry library like us to use their in house implementation
> for predicates and overlays.
> 
> Would you guys be willing to take one of those options?

André,

The latter one looks the more appealing to me.

That would likely be a C++ interface IGeometryBackend with pure virtual 
methods like
   bool Intersects(OGRGeometry*, OGRGeometry*);
   OGRGeometry* Intersection(OGRGeometry*, OGRGeometry*);

And potentially GEOS prepared geometry could fit with :
   bool SupportsPreparedGeometry()
   bool SupportsPreparedGeometryInersection()
   GeometryBackendPreparedGeometry* Prepare(OGRGeometry*)
   void DeletePreparedGeometry(GeometryBackendPreparedGeometry*)
   bool Intersects(GeometryBackendPreparedGeometry*, OGRGeometry*)

And there would be OGRInstallGeometryBackend(IGeometryBackend*).

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] Importing completely MITAB into GDAL source tree ?

[Uffe Kousgaard]

As the one, who have requested this, I obviously think it is a great 
idea, since both https://github.com/mapgears/mitab and 
http://mitab.maptools.org/ are "dead".


Including the forum at yahoo:
https://groups.yahoo.com/neo/groups/mitab/info

We currently maintain our own older code based upon 1.7.0, which 
includes the first 2 fixes here:

http://trac.osgeo.org/gdal/ticket/5256
http://trac.osgeo.org/gdal/ticket/5676

And now I have just added this one (no fix for that one):
http://trac.osgeo.org/gdal/ticket/5677

We use MITAB C API and nothing else. That is the DLL version.
Compiled for both win32 and win64.

Regards
Uffe Kousgaard


Even Rouault wrote:

Hi,

As some of you know, the OGR MapInfo driver heavily depends on the source code 
of the MITAB library. Over the years, people have contributed fixes and 
improvements through GDAL. Not all those changes have made their way in the 
official MITAB repository that sits at https://github.com/mapgears/mitab and 
which has not evolved a lot in comparison to its copy in OGR.

Maintaining 2 copies and synchronizing them is a time consuming and error-
prone process.
On the other hand, there are still people that depend on the standalone MITAB 
library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm 
wondering if it wouldn't be more efficient to import those specific remaining 
parts (standalone build scripts, C API and utilities) into the GDAL source 
tree (probably a ogr/ogrsf_frmts/mitab/build and ogr/ogrsf_frmts/mitab/apps)
That way both projects would share the same code in a very obvious way, while 
keeping their specificities.


Thoughts ?

Even

  

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

[gdal-dev] LZW Compression on geotiffs

[Newcomb, Doug]

Hi,
I have a 4 band uncompressed geotiff ( NAIP data for North Carolina, USA)
that is 193 MB
I've been going over the compression options for gdal_translate  geotiffs
and I note the following:
gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that is
194MB in size
gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is 232MB
in size
gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file that is
177MB in size

Of the above  Lossless compression options for geotiff, it seems that
DEFLATE is the only one actually compressing.

I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with ./configure
--with-libz   --with-png  --with-libtiff=internal
 --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg
--with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
--with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
--with-podofo --with-spatialite --with-netcdf

Is this expected behavior?

Doug
-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Importing completely MITAB into GDAL source tree ?

[Bo Victor Thomsen]

A very big +1 from me (As an occasional user of MiTab and a very small 
contributor to MiTab)


Regards
Bo Victor Thomsen
AestasGIS
Denmark

Den 01-10-2014 14:07, Even Rouault skrev:

Hi,

As some of you know, the OGR MapInfo driver heavily depends on the source code
of the MITAB library. Over the years, people have contributed fixes and
improvements through GDAL. Not all those changes have made their way in the
official MITAB repository that sits at https://github.com/mapgears/mitab and
which has not evolved a lot in comparison to its copy in OGR.
Maintaining 2 copies and synchronizing them is a time consuming and error-
prone process.
On the other hand, there are still people that depend on the standalone MITAB
library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm
wondering if it wouldn't be more efficient to import those specific remaining
parts (standalone build scripts, C API and utilities) into the GDAL source
tree (probably a ogr/ogrsf_frmts/mitab/build and ogr/ogrsf_frmts/mitab/apps)
That way both projects would share the same code in a very obvious way, while
keeping their specificities.

Thoughts ?

Even



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

Re: [gdal-dev] LZW Compression on geotiffs

[Even Rouault]

Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
> Hi,
> I have a 4 band uncompressed geotiff ( NAIP data for North Carolina, USA)
> that is 193 MB
> I've been going over the compression options for gdal_translate  geotiffs
> and I note the following:
> gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that is
> 194MB in size
> gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is 232MB
> in size
> gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file that is
> 177MB in size
> 
> Of the above  Lossless compression options for geotiff, it seems that
> DEFLATE is the only one actually compressing.
> 
> I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with ./configure
> --with-libz   --with-png  --with-libtiff=internal
>  --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg
> --with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
> --with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
> --with-podofo --with-spatialite --with-netcdf
> 
> Is this expected behavior?

Doug,

Not completely surprising that lossless methods don't work well with 
aerial/satellite imagery.
You may also want to test with -co TILED=YES .

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] LZW Compression on geotiffs

[Newcomb, Doug]

Well,
I went back and compiled with 1.11.1 with the external geotiff library and
got the same result for LZW, tiling made no difference in size .

As an interesting sideline, I noticed that I had not been compiling with
LZMA compression  previously and compiled gdal 1.11.1 with LZMA.  I ran:


gdal_translate -of “GTIFF” -co “COMPRESS=LZMA” on the original file and got
a file of  149MB in size.

 I noticed that LZMA compression is not listed as one of the compression
options for the GeoTIFF format in the online documentation.  Has that
capability been available long?

Doug

On Wed, Oct 1, 2014 at 9:45 AM, Even Rouault 
wrote:

> Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
> > Hi,
> > I have a 4 band uncompressed geotiff ( NAIP data for North Carolina, USA)
> > that is 193 MB
> > I've been going over the compression options for gdal_translate  geotiffs
> > and I note the following:
> > gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that
> is
> > 194MB in size
> > gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is
> 232MB
> > in size
> > gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file that is
> > 177MB in size
> >
> > Of the above  Lossless compression options for geotiff, it seems that
> > DEFLATE is the only one actually compressing.
> >
> > I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with
> ./configure
> > --with-libz   --with-png  --with-libtiff=internal
> >  --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg
> > --with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
> > --with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
> > --with-podofo --with-spatialite --with-netcdf
> >
> > Is this expected behavior?
>
> Doug,
>
> Not completely surprising that lossless methods don't work well with
> aerial/satellite imagery.
> You may also want to test with -co TILED=YES .
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] LZW Compression on geotiffs

[Even Rouault]

Le mercredi 01 octobre 2014 16:26:15, Newcomb, Doug a écrit :
> Well,
> I went back and compiled with 1.11.1 with the external geotiff library and
> got the same result for LZW, tiling made no difference in size .
> 
> As an interesting sideline, I noticed that I had not been compiling with
> LZMA compression  previously and compiled gdal 1.11.1 with LZMA.  I ran:
> 
> 
> gdal_translate -of “GTIFF” -co “COMPRESS=LZMA” on the original file and got
> a file of  149MB in size.
> 
>  I noticed that LZMA compression is not listed as one of the compression
> options for the GeoTIFF format in the online documentation.  Has that
> capability been available long?

GDAL 1.8.0. Should likely be documented. Caution: GeoTIFF LZMA compression is 
something that is far from being standard. Probably only GDAL LZMA-enabled 
builds with internal libtiff (or with external libtiff 4.0.X built against 
liblzma) will be able to deal with that.

If that's an option for you, you could try lossless JPEG2000 compression. See 
http://www.gdal.org/frmt_jp2openjpeg.html and the "Lossless compression" 
paragraph.

> 
> Doug
> 
> On Wed, Oct 1, 2014 at 9:45 AM, Even Rouault 
> 
> wrote:
> > Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
> > > Hi,
> > > I have a 4 band uncompressed geotiff ( NAIP data for North Carolina,
> > > USA) that is 193 MB
> > > I've been going over the compression options for gdal_translate 
> > > geotiffs and I note the following:
> > > gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that
> > 
> > is
> > 
> > > 194MB in size
> > > gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is
> > 
> > 232MB
> > 
> > > in size
> > > gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file that
> > > is 177MB in size
> > > 
> > > Of the above  Lossless compression options for geotiff, it seems that
> > > DEFLATE is the only one actually compressing.
> > > 
> > > I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with
> > 
> > ./configure
> > 
> > > --with-libz   --with-png  --with-libtiff=internal
> > > 
> > >  --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg
> > > 
> > > --with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
> > > --with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
> > > --with-podofo --with-spatialite --with-netcdf
> > > 
> > > Is this expected behavior?
> > 
> > Doug,
> > 
> > Not completely surprising that lossless methods don't work well with
> > aerial/satellite imagery.
> > You may also want to test with -co TILED=YES .
> > 
> > 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] Importing completely MITAB into GDAL source tree ?

[Tamas Szekeres]

+1 from me.

2014-10-01 14:07 GMT+02:00 Even Rouault :

> Hi,
>
> As some of you know, the OGR MapInfo driver heavily depends on the source
> code
> of the MITAB library. Over the years, people have contributed fixes and
> improvements through GDAL. Not all those changes have made their way in the
> official MITAB repository that sits at https://github.com/mapgears/mitab
> and
> which has not evolved a lot in comparison to its copy in OGR.
> Maintaining 2 copies and synchronizing them is a time consuming and error-
> prone process.
> On the other hand, there are still people that depend on the standalone
> MITAB
> library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm
> wondering if it wouldn't be more efficient to import those specific
> remaining
> parts (standalone build scripts, C API and utilities) into the GDAL source
> tree (probably a ogr/ogrsf_frmts/mitab/build and
> ogr/ogrsf_frmts/mitab/apps)
> That way both projects would share the same code in a very obvious way,
> while
> keeping their specificities.
>
> Thoughts ?
>
> 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] LZW Compression on geotiffs

[David Strip]

I was sufficiently intrigued by this result that I tried on some 3-band
aerial data I had handy. My data is from over Phila, PA. Here are the
results for various compression/tiling combinations. It's quite
different from yours

  93,784,427 out_none.tif

 73,241,943 out_deflate.tif
 59,786,628 out_deflate_tiled.tif
 
 93,191,345 out_lzw.tif
 78,036,699 out_lzw_tiled.tif

 94,516,744 out_pack.tif
 94,552,019 out_pack_tiled.tif

As Even noted, it's not surprising that some compression methods, esp.
packbits which is a very simple compression, would not have much effect,
and in fact actually increased file size. More surprising would be that
LZW and deflate don't save space. In my case, tiling made a big difference.

On 10/1/2014 8:32 AM, Even Rouault wrote:
> Le mercredi 01 octobre 2014 16:26:15, Newcomb, Doug a écrit :
>> Well,
>> I went back and compiled with 1.11.1 with the external geotiff library and
>> got the same result for LZW, tiling made no difference in size .
>>
>> As an interesting sideline, I noticed that I had not been compiling with
>> LZMA compression  previously and compiled gdal 1.11.1 with LZMA.  I ran:
>>
>>
>> gdal_translate -of “GTIFF” -co “COMPRESS=LZMA” on the original file and got
>> a file of  149MB in size.
>>
>>  I noticed that LZMA compression is not listed as one of the compression
>> options for the GeoTIFF format in the online documentation.  Has that
>> capability been available long?
> GDAL 1.8.0. Should likely be documented. Caution: GeoTIFF LZMA compression is 
> something that is far from being standard. Probably only GDAL LZMA-enabled 
> builds with internal libtiff (or with external libtiff 4.0.X built against 
> liblzma) will be able to deal with that.
>
> If that's an option for you, you could try lossless JPEG2000 compression. See 
> http://www.gdal.org/frmt_jp2openjpeg.html and the "Lossless compression" 
> paragraph.
>
>> Doug
>>
>> On Wed, Oct 1, 2014 at 9:45 AM, Even Rouault 
>>
>> wrote:
>>> Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
 Hi,
 I have a 4 band uncompressed geotiff ( NAIP data for North Carolina,
 USA) that is 193 MB
 I've been going over the compression options for gdal_translate 
 geotiffs and I note the following:
 gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that
>>> is
>>>
 194MB in size
 gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is
>>> 232MB
>>>
 in size
 gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file that
 is 177MB in size

 Of the above  Lossless compression options for geotiff, it seems that
 DEFLATE is the only one actually compressing.

 I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with
>>> ./configure
>>>
 --with-libz   --with-png  --with-libtiff=internal

  --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg

 --with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
 --with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
 --with-podofo --with-spatialite --with-netcdf

 Is this expected behavior?
>>> Doug,
>>>
>>> Not completely surprising that lossless methods don't work well with
>>> aerial/satellite imagery.
>>> You may also want to test with -co TILED=YES .
>>>
>>> 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] LZW Compression on geotiffs

[Newcomb, Doug]

Thanks! I have been also working with JPEG2000 compression with both he
jasper and openjpeg libraries.  For some reason, the openjpeg library
didn't seem to work with 4 band imagery ( Error 6:  Unable to export files
with 4 bands) , but the jasper library did.

Doug

On Wed, Oct 1, 2014 at 10:32 AM, Even Rouault 
wrote:

> Le mercredi 01 octobre 2014 16:26:15, Newcomb, Doug a écrit :
> > Well,
> > I went back and compiled with 1.11.1 with the external geotiff library
> and
> > got the same result for LZW, tiling made no difference in size .
> >
> > As an interesting sideline, I noticed that I had not been compiling with
> > LZMA compression  previously and compiled gdal 1.11.1 with LZMA.  I ran:
> >
> >
> > gdal_translate -of “GTIFF” -co “COMPRESS=LZMA” on the original file and
> got
> > a file of  149MB in size.
> >
> >  I noticed that LZMA compression is not listed as one of the compression
> > options for the GeoTIFF format in the online documentation.  Has that
> > capability been available long?
>
> GDAL 1.8.0. Should likely be documented. Caution: GeoTIFF LZMA compression
> is
> something that is far from being standard. Probably only GDAL LZMA-enabled
> builds with internal libtiff (or with external libtiff 4.0.X built against
> liblzma) will be able to deal with that.
>
> If that's an option for you, you could try lossless JPEG2000 compression.
> See
> http://www.gdal.org/frmt_jp2openjpeg.html and the "Lossless compression"
> paragraph.
>
> >
> > Doug
> >
> > On Wed, Oct 1, 2014 at 9:45 AM, Even Rouault  >
> >
> > wrote:
> > > Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
> > > > Hi,
> > > > I have a 4 band uncompressed geotiff ( NAIP data for North Carolina,
> > > > USA) that is 193 MB
> > > > I've been going over the compression options for gdal_translate
> > > > geotiffs and I note the following:
> > > > gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file
> that
> > >
> > > is
> > >
> > > > 194MB in size
> > > > gdal_translate -of “GTIFF” -co “COMPRESS=LZW” gives me a file that is
> > >
> > > 232MB
> > >
> > > > in size
> > > > gdal_translate -of “GTIFF” -co “COMPRESS=DEFLATE” gives me a file
> that
> > > > is 177MB in size
> > > >
> > > > Of the above  Lossless compression options for geotiff, it seems that
> > > > DEFLATE is the only one actually compressing.
> > > >
> > > > I'm running gdal 1.11.0 on Ubuntu 12.04.3 64 bit compiled with
> > >
> > > ./configure
> > >
> > > > --with-libz   --with-png  --with-libtiff=internal
> > > >
> > > >  --with-geotiff=internal   --with-jpeg=internal   --with-openjpeg
> > > >
> > > > --with-pg=/usr/local/pgsql/bin/pg_config --with-ogr --with-xerces
> > > > --with-geos --with-hdf4 --with-hdf5 --with-poppler=/usr/local/lib
> > > > --with-podofo --with-spatialite --with-netcdf
> > > >
> > > > Is this expected behavior?
> > >
> > > Doug,
> > >
> > > Not completely surprising that lossless methods don't work well with
> > > aerial/satellite imagery.
> > > You may also want to test with -co TILED=YES .
> > >
> > > Even
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] LZW Compression on geotiffs

[Stephen Roecker]

I've also been toying with the compression settings lately and thought
I would mention my experience. I'm not sure if this is known behavior,
but when subsequently using the compressed rasters with 'gdaldem' I
got some strange results when the raster was greater than 4GB (i.e.
BIGTIFF). The resulting rasters were either corrupt, way way larger than
they should have been, or I terminated before they completed due to
the extreme length of time (> 2 hours) they took to process. When I
used an uncompressed BIGTIFF raster with gdaldem, the results were as
expected. This was all using gdal 11.0, and the following BIGTIFF
compression settings, -co "TILED=YES" -co "BIGTIFF=YES" -co
"COMPRESS=DEFLATE".

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

Re: [gdal-dev] LZW Compression on geotiffs

[Even Rouault]

Le mercredi 01 octobre 2014 19:21:39, Stephen Roecker a écrit :
> I've also been toying with the compression settings lately and thought
> I would mention my experience. I'm not sure if this is known behavior,
> but when subsequently using the compressed rasters with 'gdaldem' I
> got some strange results when the raster was greater than 4GB (i.e.
> BIGTIFF). The resulting rasters were either corrupt, way way larger than
> they should have been, or I terminated before they completed due to
> the extreme length of time (> 2 hours) they took to process. When I
> used an uncompressed BIGTIFF raster with gdaldem, the results were as
> expected. This was all using gdal 11.0, and the following BIGTIFF
> compression settings, -co "TILED=YES" -co "BIGTIFF=YES" -co
> "COMPRESS=DEFLATE".

Stephen,

That it might be long or result in larger than expected file is not completely 
unsurprising. With formats like geotiff, the gdaldem utility fills the output 
raster line by line. So when creating a tiled compress geotiff, partial blocks 
may be read and written several times. Each time a compressed block is written 
and larger than its previous size it gets written at the end of the TIFF, and 
the previous space occupied is lost. That you get corruption is more 
surprising though.
But there was another code path in gdaldem, used for formats like PNG, that 
can also be used for GTiff. It is a bit slower when applied in the general 
case, but it is definitely needed in the use case you mentionned (tiled 
compressed geotiff). Fixed now by http://trac.osgeo.org/gdal/ticket/5678

In the meantime, outputing to uncompressed file and then gdal_translat'ing to 
compressed tiled file is the best option.

Even


> 
> Stephen
> ___
> 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] Importing completely MITAB into GDAL source tree ?

[Daniel Morissette]

Hi Even, all,

Thank you for bringing this up, FWIW I am supportive of solving the 
MITAB situation and will do my best to help do this in the best interest 
of all users.


Instead of just forking the source, should we talk instead about 
migrating the ownership/direction of the MITAB project under the GDAL 
umbrella? Would the GDAL PSC be interested in that? That would help 
address the perception that MITAB is "dead" and make it easier for 
people like you to contribute to it since there would be only one MITAB, 
the one maintained by the GDAL team.


Note that if we are to move MITAB under the GDAL umbrella, we'd need to 
keep in mind that this involves more than just copying the source under 
the GDAL source tree as you suggest here. The standalone version of 
MITAB contains a subset of the CPL and OGR files, which is just the bare 
minimum for MITAB to work. If you move the official MITAB source under 
the GDAL source tree, this separation will be lost and it will become 
impossible to build MITAB as a standalone lib independent of GDAL/OGR.


All this to say that just moving the source as you suggest is probably 
not enough to get real benefits, that would just formalize the fork 
between MITAB and GDAL without helping the users that need a standalone 
MITAB.


I think the MITAB situation is a bit similar to that of shapelib and 
libgeotiff which are extensively used by GDAL, but that also need to 
exist by themselves for the application developers that want direct 
access to a single format in a lightweight lib.


Who maintains and releases shapelib and libgeotiff today? I believe it's 
Frank. Would it make sense to also officially bring those two under the 
GDAL umbrella at the same time and solve the "when will you publish a 
new libgeotiff release?" question that I seem to hear every once in a 
while over beers at FOSS4G or code sprints.


That would be a bit like what we did when MapCache and TinyOWS joined 
MapServer project. The long term goal was to facilitate their 
integration with the MapServer core, and in the short term to increase 
the bus number of those projects and ensure their long term viability.


Daniel


On 14-10-01 8:07 AM, Even Rouault wrote:

Hi,

As some of you know, the OGR MapInfo driver heavily depends on the source code
of the MITAB library. Over the years, people have contributed fixes and
improvements through GDAL. Not all those changes have made their way in the
official MITAB repository that sits at https://github.com/mapgears/mitab and
which has not evolved a lot in comparison to its copy in OGR.
Maintaining 2 copies and synchronizing them is a time consuming and error-
prone process.
On the other hand, there are still people that depend on the standalone MITAB
library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm
wondering if it wouldn't be more efficient to import those specific remaining
parts (standalone build scripts, C API and utilities) into the GDAL source
tree (probably a ogr/ogrsf_frmts/mitab/build and ogr/ogrsf_frmts/mitab/apps)
That way both projects would share the same code in a very obvious way, while
keeping their specificities.

Thoughts ?

Even




--
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] LZW Compression on geotiffs

[Jukka Rahkonen]

Even Rouault  spatialys.com> writes:


> 
> If that's an option for you, you could try lossless JPEG2000 compression. See 
> http://www.gdal.org/frmt_jp2openjpeg.html and the "Lossless compression" 
> paragraph.


My numbers for the most simple compressions without tiling:

Original RGB  424 MB
LZW "compressed"  474 MB
Deflate   380 MB
Lossless JP2  197 MB

For comparison:
Tiff as zipped347 MB
Tiff into png 263 MB
If I have understood right both zip and png are using deflate algorithm so
there might be some place for improving deflate compression in GDAL.

-Jukka Rahkonen-

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

Re: [gdal-dev] Importing completely MITAB into GDAL source tree ?

[Even Rouault]

Daniel,

thanks for your thoughts.

> Thank you for bringing this up, FWIW I am supportive of solving the
> MITAB situation and will do my best to help do this in the best interest
> of all users.
> 
> Instead of just forking the source, should we talk instead about
> migrating the ownership/direction of the MITAB project under the GDAL
> umbrella? Would the GDAL PSC be interested in that? 

In such a mode, I guess MITAB releases would be synchronized with GDAL ones, 
as that would be the same source tarball.

> That would help
> address the perception that MITAB is "dead" and make it easier for
> people like you to contribute to it since there would be only one MITAB,
> the one maintained by the GDAL team.
> 
> Note that if we are to move MITAB under the GDAL umbrella, we'd need to
> keep in mind that this involves more than just copying the source under
> the GDAL source tree as you suggest here. The standalone version of
> MITAB contains a subset of the CPL and OGR files, which is just the bare
> minimum for MITAB to work. 

Yes I'm aware of that. I tried not so long ago to sync the CPL and OGR core 
version of MITAB with the ones of GDAL trunk in a branch of my MITAB fork : 
https://github.com/rouault/mitab/commit/9e62e99a11c1163460fd9530c494e35262561b24

> If you move the official MITAB source under
> the GDAL source tree, this separation will be lost and it will become
> impossible to build MITAB as a standalone lib independent of GDAL/OGR.

My idea was actually to have build scripts in let's say 
ogr/ogrsf_frmts/mitab/build that would still generate an independant mitab lib 
with as few as possible CPL/OGR files in it. That should be doable hopefully.

There are somewhat similar, although probably more simple, similar cases in 
the GDAL source tree. Some drivers, like OGR DGN, GDAL HFA,etc... have specific 
build targets to build debug utilities (although I suspect most must be broken 
due to the changes done over the year), or small library to deal just with the 
format.

> 
> All this to say that just moving the source as you suggest is probably
> not enough to get real benefits, that would just formalize the fork
> between MITAB and GDAL without helping the users that need a standalone
> MITAB.
> 
> I think the MITAB situation is a bit similar to that of shapelib and
> libgeotiff which are extensively used by GDAL, but that also need to
> exist by themselves for the application developers that want direct
> access to a single format in a lightweight lib.
> 
> Who maintains and releases shapelib and libgeotiff today? I believe it's
> Frank. Would it make sense to also officially bring those two under the
> GDAL umbrella at the same time and solve the "when will you publish a
> new libgeotiff release?" question that I seem to hear every once in a
> while over beers at FOSS4G or code sprints.

That's Frank's call, but indeed regarding shapelib last release was in april 
2012, and the OGR version has got a few improvements since.

Regarding libgeotiff, Frank and Howard have championned a RC during the code 
sprint at FOSS4G, that should be released tomorrow according to 
http://lists.maptools.org/pipermail/geotiff/2014-September/000774.html

> 
> That would be a bit like what we did when MapCache and TinyOWS joined
> MapServer project.

The situation is a bit different since MapCache and TinyOWS, as far as I know, 
don't share (currently) code with MapServer, and have actually their own git 
repositories (even if hosted under the same account at github)

> The long term goal was to facilitate their
> integration with the MapServer core, and in the short term to increase
> the bus number of those projects and ensure their long term viability.
> 

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] LZW Compression on geotiffs

[David Strip]

  
  
On 10/1/2014 12:02 PM, Jukka Rahkonen
  wrote:


  For comparison:
Tiff as zipped347 MB
Tiff into png 263 MB
If I have understood right both zip and png are using deflate algorithm so
there might be some place for improving deflate compression in GDAL.


I was curious how png could achieve such  better compression if it
is using the same deflate algorithm. I wouldn't think different
implementations would account for so much improvement. It turns out
the png compression uses a "filtering" step ahead of compression.
This is explained here.
The filter is similar to a differential pulse code modulation, in
which the pixel is represented as the difference from the pixels to
the left, left upper diagonal, and above. This typically reduces the
magnitude of the value to something close to zero, making the
encoding more efficient.

David
  

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

Re: [gdal-dev] LZW Compression on geotiffs

[Even Rouault]

Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :
> On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:
> 
> For comparison:
> Tiff as zipped347 MB
> Tiff into png 263 MB
> If I have understood right both zip and png are using deflate algorithm so
> there might be some place for improving deflate compression in GDAL.
> 
>  I was curious how png could achieve such  better compression if it is
> using the same deflate algorithm. I wouldn't think different
> implementations would account for so much improvement. It turns out the
> png compression uses a "filtering" step ahead of compression. This is
> explained here. The filter is similar to a differential pulse code
> modulation, in which the pixel is represented as the difference from the
> pixels to the left, left upper diagonal, and above. This typically reduces
> the magnitude of the value to something close to zero, making the encoding
> more efficient.

True, a way to improve things might be to specify -co PREDICTOR=2. Should 
apply to both LZW and DEFLATE.
This is one of the filter that might be used by PNG, except that PNG has 
different filters, so it will eventually beat TIFF deflate.

> 
>  David

-- 
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] Motion: Commit access for Jukka Rahkonen

[Even Rouault]

Le lundi 29 septembre 2014 21:11:05, Even Rouault a écrit :
> Motion: Extend GDAL/OGR commit access to Jukka Rahkonen
> ---

I declare this motion passed with support from FrankW, TamasS, DanielM, 
HowardB and myself.

Jukka, I have added your OSGeo Trac account (jratike80) as member of GDAL SVN. 
Could you add your name in the COMMITERS file and commit it to check that 
things work properly ?

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] LZW Compression on geotiffs

[Armin Burger]

I would also always recommend to use -co PREDICTOR=2 when compressing 
with LZW (or DEFLATE). So far I made quite good experiences with LZW and 
PREDICTOR=2, with typical compression rates close to gzip compression 
(meaning when putting the tif file into a tgz archive file).


The only time that I discovered where LZW does not work well was when 
using gdalwarp and directly writing the output as (untiled) LZW TIFF. 
This could create LZW files up to 2-3 times bigger than the uncompressed 
input TIFF. When using gdalwarp and one wants to save disk space one 
should either create tiled LZW TIFF's, or warp to uncompressed TIFF and 
then use gdal_translate with LZW to create the final LZW image, 
PREDICTOR=2 is recommended for both methods.


armin


On 10/02/2014 01:13 AM, Even Rouault wrote:

Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :

On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:

For comparison:
Tiff as zipped347 MB
Tiff into png 263 MB
If I have understood right both zip and png are using deflate algorithm so
there might be some place for improving deflate compression in GDAL.

  I was curious how png could achieve such  better compression if it is
using the same deflate algorithm. I wouldn't think different
implementations would account for so much improvement. It turns out the
png compression uses a "filtering" step ahead of compression. This is
explained here. The filter is similar to a differential pulse code
modulation, in which the pixel is represented as the difference from the
pixels to the left, left upper diagonal, and above. This typically reduces
the magnitude of the value to something close to zero, making the encoding
more efficient.


True, a way to improve things might be to specify -co PREDICTOR=2. Should
apply to both LZW and DEFLATE.
This is one of the filter that might be used by PNG, except that PNG has
different filters, so it will eventually beat TIFF deflate.



  David



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

Re: [gdal-dev] LZW Compression on geotiffs

[Rahkonen Jukka (Tike)]

Even Rouault wrote:
> 
> Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :
> > On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:
> >
> > For comparison:
> > Tiff as zipped347 MB
> > Tiff into png 263 MB
> > If I have understood right both zip and png are using deflate
> > algorithm so there might be some place for improving deflate compression in
> GDAL.
> >
> >  I was curious how png could achieve such  better compression if it is
> > using the same deflate algorithm. I wouldn't think different
> > implementations would account for so much improvement. It turns out
> > the png compression uses a "filtering" step ahead of compression. This
> > is explained here. The filter is similar to a differential pulse code
> > modulation, in which the pixel is represented as the difference from
> > the pixels to the left, left upper diagonal, and above. This typically
> > reduces the magnitude of the value to something close to zero, making
> > the encoding more efficient.
> 
> True, a way to improve things might be to specify -co PREDICTOR=2. Should
> apply to both LZW and DEFLATE.
> This is one of the filter that might be used by PNG, except that PNG has 
> different
> filters, so it will eventually beat TIFF deflate.

Not a bad suggestion.

Original 424 MB
DEFLATE without predictor  380 MB 
DEFLATE with -co predictor=2 280 MB

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

Re: [gdal-dev] LZW Compression on geotiffs

[Robert Coup]

On Thu, Oct 2, 2014 at 12:46 PM, Armin Burger  wrote:

> The only time that I discovered where LZW does not work well was when
> using gdalwarp and directly writing the output as (untiled) LZW TIFF. This
> could create LZW files up to 2-3 times bigger than the uncompressed input
> TIFF. When using gdalwarp and one wants to save disk space one should
> either create tiled LZW TIFF's, or warp to uncompressed TIFF and then use
> gdal_translate with LZW to create the final LZW image, PREDICTOR=2 is
> recommended for both methods.


We've learned to do the latter (warp first, then compress via translate) if
you're writing into the output TIFF from more than one input file. The
compressed tiff will be smaller, and you won't get weird bugs appearing
occasionally.

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