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
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
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
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
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
When creating the level x, gdal_retile interpolates the tiles of level x-1.
If not all data exist in level x-1, it interpolates with nodata values (I
guess ?). The result is that at the border, we can see almost black values,
but not exactly black. They become visible when setting the output
trans
I moved my level 1 tiles to a machine with big hard disk, many processors and
a lot of memory.
Then I restarted the process taking the level 1 tiles as source :
gdal_retile.py -targetDir subpyramid/ -levels 11 -pyramidOnly -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r biline
Thanks for the quick reply. I think it makes sense.
First I'll try to move all data to a computing machine with a big hard disk,
then if it's still slow, I'll try to increase self.cacheSize as you write.
As gdal_retile.py isn't computing the empty tiles, I guess I can use :
( pixel width of the
Hello,
It looks like gdal_retile.py slows down when processing a new level of the
pyramid.
Source files : 8065 geotiffs orthophotos of 4000 x 4000 pixels, in total 400
GB.
Command : gdal_retile.py -targetDir pyramid/ -levels 12 -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r
I would also be interested in such information.
Suscribing to this post in case it gets replies.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Parallel-Processing-tp3837605p5034690.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
__
acangi wrote:
>
> I re-created the first tile that gave me the problem (and only this tile)
> from the source files using gdal_retile and gdal_translate -projwin. The
> problem isn't there any more. [...] I still need to recreate the higher
> tiles, if that works.
>
Us
les of gdal_retile aren't tiled inside.
Alain
- Mail Original -
De: "Christian Müller (via Nabble)"
À: "acangi"
Envoyé: Mercredi 19 Août 2009 14h34:41 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: Re: [Gdal-dev] Flashy colors in a
> this strange area. What is the result.? I want to know if the problem is
> gdal_retile.py or geoserver.
>
>
>
> acangi writes:
>
>>
>> Hello list,
>>
>> I created a pyramid of aerial photos using gdal_retile.py and now see
>> there
Hello list,
I created a pyramid of aerial photos using gdal_retile.py and now see there
are strange zones in the pyramid. I'm trying to understand why I got this
strange results and how I can fix it (Bombing the area to make sure it looks
like what I have ?). Description :
1. The command I used w
escribed here.
> http://www.gdal.org/gdal_utilities.html
>
> If you have problems, send me a mail
>
> cheers
> christian
>
>
>
> acangi writes:
>
>>
>> Hello,
>>
>> Trying to execute this command :
>>
>> gdal_retile.py -targetDir
Hello,
Trying to execute this command :
gdal_retile.py -targetDir pyramid -levels 4 -v -pyramidOnly -s_srs
top50r.prj -ps 4000 4000 -r mode -co "TILED=YES" -co "INTERLEAVE=PIXEL" -co
"COMPRESS=LZW" -tileIndex pyramid -tileIndexField location *map.tif
gives the error "Unknown resampling method
ar CH wrote:
>
> acangi,
>
> Could you check if the after image shows any different colors with
> some other image viewer like ImageMagick? OpenEV might not be reading
> the color table correctly.
>
> --
> Chaitanya kumar CH.
>
> On Mon, Feb 16, 2009 at 7:43
Subscription problem, reposting as requested.
acangi wrote:
>
> Hello,
>
> I try to translate colormapped geotiff files from EPSG:31300 to EPSG:3812,
> using
>
> $ gdalwarp -s_srs EPSG:31300 -t_srs "+proj=lcc +lat_1=49.84
> +lat_2=51.16
21 matches
Mail list logo
