Hi,
You can simplify your process because you already use –a_srs parameter (“assign spatial reference system”) . Therefore it should not be necessary to create all those .prj files at all.
Gdaladdo with resolution 1 does not make sense because it means creating an overview with original resolution. I hope that gdaladdo quitly skips it, otherwise you are getting all too large files. It is also good to know that gdaladdo –clean does not remove old overviews physically and filesize will not shrink. If you experiment with different resampling methods, use –ro option and create an external .ovr file. You can also test the quality with different resampling methods almost realtime by renaming the different ovr files into something like image.average.ovr and image.nearest.ovr. During the test rename the one you want to use into image.ovr.
-Jukka Rahkonen-
···
Russell Hore wrote:
They way I have created my pyramid with this data is as follows (and if somebody can improve it, please tell me)
Take the OS *.tif files and copy them into a directory for each OS Grid e.g. SD, SO, SH etc
Add the relevant world files to each directory.
Create a ‘prj’ file for each tif file. It is always the same so I create a pro.prj file and with a bit of scripting, find all the *.tif files and copy prj.prj to the same name, changing the extension to pro, so I end up with three files for each tif (sh67.tif, sh67.prj, sh67.tfw)
Now I run this script (quick, dirty, no comments and no apologies for that)
echo -n Working on
pwd
mkdir out
for file in ls *tif
do
echo -n Working on $file
gdal_translate -of GTiff -co “TILED=YES” -co “COMPRESS=DEFLATE” -co “BLOCKXSIZE=512” -co “BLOCKYSIZE=512” -a_srs “EPSG:27700” $file out/$file
done
mv out/* .
rm -fr out
for file in ls *tif
do
echo -n Working on $file
gdaladdo -clean $file
gdaladdo -r average $file 1 2 4 8 16 32 64 128
done
(As I understand it that creates GeoTIFFs from all the tifs and adds overviews.)
I then create the pyramid with;
#!/bin/bash
export thedir=pwd
export thedir=basename $thedir
echo $thedir
mkdir pyramid
ls *tif > …/tiles$thedir.txt
gdal_retile.py -v -levels 9 -ps 2048 2048 -co ‘TILED=YES’ -co ‘BLOCKXSIZE=256’ -co ‘BLOCKYSIZE=256’ -s_srs EPSG:27700 -targetDir pyramid --optfile …/tiles$thedir.txt
Not sure pif that helps?
Russ
On 12 May 2014, at 13:15, Tom Chadwin <tom.chadwin@anonymised.com> wrote:
Yes. Apologies for my ignorance. I’ve now added an epsg:27700 .prj file to
the folder, and the layer now creates fine.
However, previewing it in tile layers has the same effect: broken graphics,
and the same GeoServer and Tomcat errors.
To make that clear, I can now recreate this problem with two different pairs
of TIF/TFWs, representing the same coverage, one from a 2009 edition, one
from 2012.
Any ideas?
Thanks
Tom
–
View this message in context: http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139757.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
