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
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 the
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
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.
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 d
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
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/direct
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
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 und
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
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 resulti
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
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_
+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
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
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
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 “
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
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 -o
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.
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
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 S
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/mapgea
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
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.
>
> (*
25 matches
Mail list logo
