Thanks, I'll go for LZW.
Just for clarity : 4 GB was the size of the smaller set that I used for the
tests. I expect the full LZW pyramid to be around 500 GB. The JPEG pyramid
is 125 GB.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-and-nodata-tp5079895p509
Hmm, jpeg is not a lossless compression, LZW is lossless. It appears
that we have a problem beyond our scope. I never use jpeg and prefer
LZW or png. I would go with LZW, this is the safe way.
4 GB are not dramatically. I store my tiles/pyramids in a database
prepared for geoserver, there
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
Any new tile is created according to the create options "-co
Name=value" you can pass in as parameter.
First an image is created, larege enough to hold the tile and its
neighbors from level x-1
Second , the tiles from level x-1 are painted onto this image.
Third, the scaling takes place.
I ran gdal_retile on a smaller set of data (same data with nodata values) so
I already have a result. You can see the border on the picture. In GeoServer
I set the outputTransparentColor to #00.
I don't think my problem comes from the existing nodata values in the source
files, but rather fro
AFAIK at the time I did the gdal_retile there was no concept of aux.xml files.
Anyways, the utility does no image operation itself, we will see on Monday.
Quoting acangi :
After removing the GDAL_PAM_ENABLED=NO, I made a
gdal_translate -a_nodata 0
on the files, this generated the aux.xml fi
After removing the GDAL_PAM_ENABLED=NO, I made a
gdal_translate -a_nodata 0
on the files, this generated the aux.xml files, and gdalinfo shows now the
nodata values :
Band 1 Block=4000x16 Type=Byte, ColorInterp=Red
NoData Value=0
Band 2 Block=4000x16 Type=Byte, ColorInterp=Green
NoData Value
You are right, give this a try.
Quoting acangi :
Maybe it's related to the fact I was preventing creation of *.aux.xml files
with
export GDAL_PAM_ENABLED=NO
Currently investigating
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-and-nodata-tp5079895p508
Maybe it's related to the fact I was preventing creation of *.aux.xml files
with
export GDAL_PAM_ENABLED=NO
Currently investigating
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-and-nodata-tp5079895p5083086.html
Sent from the GDAL - Dev mailing list archi
gdalinfo doesn't give me any information about nodata, even after a
gdal_translate -of GTiff -co "PROFILE=GeoTIFF" -co "INTERLEAVE=PIXEL" -co
"COMPRESS=JPEG" -a_nodata 0 orthocol.tif ../orthocol0.tif
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-and-nodata
12 matches
Mail list logo
