subject:"Re\: \[Geoserver\-users\] GWC seeding\: Error rendering coverage on the fast path"

Jonathan, Russ, Jukka

Thanks for all the details, but as I say, simply adding a .prj file to the
directory allowed me to create the layer.

However, the broken GWC tiles and GS and TC errors occur with both the 2009
TIFFs and the 2012 ones. Can either of the two of you with these tiles
recreate the problem:

OS 50k: sd86.tif & sd88.tif
ESPG: 27700 .prj file
BritNatGrid gridset (see earlier post for actual code)
PNG8
Bicubic interpolation
GeoServer 2.5.0
Tomcat 7.0.53
JAI
JAI I/O
Windows 2008 R2
Java 7u55 32-bit

If someone else could recreate the problem, it would certainly help. Or, if
someone can recreate the set-up above with no errors, that would also be
useful. I don't know if I am confronted with an error in my set-up or a
GS/GWC problem.

I've contacted the vendor of the TIFFs in question, and they can only be
released if the recipient signs a contractor licence, so I cannot post them
to this list, sadly.

Thanks

Tom

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139796.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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

Slightly corrected version. I missed out the big-tiff flag so it'd fail
over when the overviews took it over the 4GB limit.
Also now has some comments (REM lines).

REM Create a list of files

dir /b /s *.tif > tiff_list.txt
>
> REM Turn that list into a virtual dataset. This is a poor-mans mosaic (but
> super fast).

gdalbuildvrt -vrtnodata 0 -input_file_list tiff_list.txt os_5.vrt
>
> REM Now convert the VRT into a tiled, georeferenced, big geotiff

gdal_translate -of GTiff -co "TILED=YES" -co "BIGTIFF=YES" -co
> "COMPRESS=DEFLATE" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" -a_srs
> "EPSG:27700" os_5.vrt c:\prod\os_5.tif
>
> REM Finally we add the pyramids. Lanczos (rather than "average" produces
> the best results but isn't in all gdal builds.

gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE c:\prod\os_5.tif
> 2 4 8 16 32


Cheers,
Jonathan


On 12 May 2014 13:29, Jonathan Moules wrote:

>
>>> The tfw contains the "grid to world" affine transformation, not the
>> projection, which would be in the prj file instead.
>> Btw, a tif + tfw + prj is not a proper GeoTIFF, GeoTIFF has a spec, which
>> says every georeferencing information is
>> in the file headers (that is, you just have one file).
>>
>>
> Thanks for the information. I think we can blame the Ordnance Survey on
> this one then.
>
>
>  tl;dr: my later editions of those tiles are not in the same format, and
>> it
>> will take a little work to get them to work as a mosaic. I'll look at that
>> now.
>
> Actually Tom it's really simple.
>
>
> dir /b /s *.tif > tiff_list.txt
>> gdalbuildvrt -vrtnodata 0 -input_file_list tiff_list.txt os_5.vrt
>> gdal_translate -of GTiff -co "TILED=YES" -co "COMPRESS=DEFLATE" -co
>> "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" -a_srs "EPSG:27700" os_5.vrt
>> 5_Colour.tif
>> gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE 5_Colour.tif 2
>> 4 8 16 32
>
>
>
> Put that in a batch file (or run from the command console in stages - best
> to do that first) and you can use it to create a GeoServer optimised
> mosaic. (for the entire UK you may want to add a few extra levels of
> overviews)
> Just CD into the directory with all the files and run it there.
>
> For the entire UK I'd suggest splitting the files manually into two groups
> (north and south) and then running that on each part. Then imagemosaic
> those two halves.
>
> Cheers,
> Jonathan
>
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-12 Thread Rahkonen Jukka (Tike)

Hi,

One more thing, save some more space and compress the overviews as well. It is 
documented in http://www.gdal.org/gdaladdo.html
If image itself is compressed with DEFLATE, use --config COMPRESS_OVERVIEW 
DEFLATE.

-Jukka Rahkonen-

Jonathan Moules wrote:


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.

Speaking from experience (I did this myself long ago before understanding) - 
gdaladdo happily creates the pyramids at level 1. So you end up with a file 
that's double it's original size!


It is also good to know that gdaladdo -clean does not remove old overviews 
physically and filesize will not shrink.

Yup. It just removes the links to the overviews. I found that out the hard way 
too. :-)



The lines in my last email have what seems to be the optimal - everything is 
inside a single file and the result is optimised for GeoServer.

I've tested now it on the OS 50k for the entire country - there's no need to 
split into two files and image mosaic. The resultant file is only about 2.5GB 
pre overviews (which usually add another 30%). So just loading that file as a 
regular single GeoTiff should be fine.

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain 
confidential, sensitive or personal information and should be handled 
accordingly. Unless you are the named addressee (or authorised to receive it 
for the addressee) you may not copy or use it, or disclose it to anyone else. 
If you have received this transmission in error please notify the sender 
immediately. All email traffic sent to or from us, including without limitation 
all GCSX traffic, may be subject to recording and/or monitoring in accordance 
with relevant legislation.
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

>
>
>
> 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.
>

Speaking from experience (I did this myself long ago before understanding)
- gdaladdo happily creates the pyramids at level 1. So you end up with a
file that's double it's original size!



> It is also good to know that gdaladdo -clean does not remove old overviews
> physically and filesize will not shrink.
>

Yup. It just removes the links to the overviews. I found that out the hard
way too. :-)



The lines in my last email have what seems to be the optimal - everything
is inside a single file and the result is optimised for GeoServer.

I've tested now it on the OS 50k for the entire country - there's no need
to split into two files and image mosaic. The resultant file is only about
2.5GB pre overviews (which usually add another 30%). So just loading that
file as a regular single GeoTiff should be fine.

Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-12 Thread Rahkonen Jukka (Tike)

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
mailto:tom.chad...@nnpa.org.uk>> 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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-12 Thread Russell Hore

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  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

--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

>
>
>> The tfw contains the "grid to world" affine transformation, not the
> projection, which would be in the prj file instead.
> Btw, a tif + tfw + prj is not a proper GeoTIFF, GeoTIFF has a spec, which
> says every georeferencing information is
> in the file headers (that is, you just have one file).
>
>
Thanks for the information. I think we can blame the Ordnance Survey on
this one then.


 tl;dr: my later editions of those tiles are not in the same format, and it
> will take a little work to get them to work as a mosaic. I'll look at that
> now.

Actually Tom it's really simple.


dir /b /s *.tif > tiff_list.txt
> gdalbuildvrt -vrtnodata 0 -input_file_list tiff_list.txt os_5.vrt
> gdal_translate -of GTiff -co "TILED=YES" -co "COMPRESS=DEFLATE" -co
> "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" -a_srs "EPSG:27700" os_5.vrt
> 5_Colour.tif
> gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE 5_Colour.tif 2
> 4 8 16 32



Put that in a batch file (or run from the command console in stages - best
to do that first) and you can use it to create a GeoServer optimised
mosaic. (for the entire UK you may want to add a few extra levels of
overviews)
Just CD into the directory with all the files and run it there.

For the entire UK I'd suggest splitting the files manually into two groups
(north and south) and then running that on each part. Then imagemosaic
those two halves.

Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-12 Thread Andrea Aime

On Mon, May 12, 2014 at 1:33 PM, Jonathan Moules <
jonathanmou...@warwickshire.gov.uk> wrote:

> Hi Tom,
> I'm trying it with those tiffs (albeit different dates again). Using
> ImageMosaic. But when I press "publish" I get a wicket error:
>
> java.lang.RuntimeException: Error occurred while building the resources
>> for the configuration page at
>> org.geoserver.web.data.layer.NewLayerPage.buildLayerInfo(NewLayerPage.java:307)
>> at
>> org.geoserver.web.data.layer.NewLayerPage$6.onClick(NewLayerPage.java:242)
>> at
>> org.geoserver.web.wicket.SimpleAjaxLink$1.onClick(SimpleAjaxLink.java:45)
>> at org.apache.wicket.ajax.markup.html.AjaxLink$1.onEvent(AjaxLink.java:68)
>> at
>> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
>> at
>> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
>> at
>> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
>> at
>> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
>
> ...
>
>
> However I was trying to use the raw base tiff files without pre-processing
> them in any way. GDALInfo says they have no projection for one thing. Which
> is weird because it's picking up the TFW too:
>

The tfw contains the "grid to world" affine transformation, not the
projection, which would be in the prj file instead.
Btw, a tif + tfw + prj is not a proper GeoTIFF, GeoTIFF has a spec, which
says every georeferencing information is
in the file headers (that is, you just have one file).

Cheers
Andrea

-- 
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

Hi Jonathan

I think I'm running into the same thing. I've got a copy of the same two
tiles from 2012 (I think), but this suggests that creating mosaics purely
from OS TFWs is not simple:

https://www.ordnancesurvey.co.uk/forums/discussion/1001439/1250-000-scale-colour-raster

>From my non-expert understanding, is it that the .tfws only give coordinate
info, not projection? So, with the full coverage 2009 files I was working
from before, I guess perhaps they must have been preprocessed into GeoTIFFs,
or resupplied as such, rather than TFWs.

tl;dr: my later editions of those tiles are not in the same format, and it
will take a little work to get them to work as a mosaic. I'll look at that
now.

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139751.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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

Hi Tom,
I'm trying it with those tiffs (albeit different dates again). Using
ImageMosaic. But when I press "publish" I get a wicket error:

java.lang.RuntimeException: Error occurred while building the resources for
> the configuration page at
> org.geoserver.web.data.layer.NewLayerPage.buildLayerInfo(NewLayerPage.java:307)
> at
> org.geoserver.web.data.layer.NewLayerPage$6.onClick(NewLayerPage.java:242)
> at
> org.geoserver.web.wicket.SimpleAjaxLink$1.onClick(SimpleAjaxLink.java:45)
> at org.apache.wicket.ajax.markup.html.AjaxLink$1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)

...


However I was trying to use the raw base tiff files without pre-processing
them in any way. GDALInfo says they have no projection for one thing. Which
is weird because it's picking up the TFW too:

Files: sd88.tif
>SD88.TFW
> Size is 4000, 4000
> Coordinate System is `'
> Origin = (38.000,50.000)
> Pixel Size = (5.000,-5.000)
> Metadata:
>   TIFFTAG_COPYRIGHT=ORDNANCE SURVEY CROWN COPYRIGHT 2013
>   TIFFTAG_DATETIME=2013:08:20 11:11:18
>   TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD88
>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
>   TIFFTAG_XRESOLUTION=254
>   TIFFTAG_YRESOLUTION=254
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (  38.000,  50.000)
> Lower Left  (  38.000,  48.000)
> Upper Right (  40.000,  50.000)
> Lower Right (  40.000,  48.000)
> Center  (  39.000,  49.000)


GeoServer 2.5-Snapshot.



How about just mosaicing them together into a couple of huge files? And
then imagemosaic those.

Cheers,
Jonathan


On 12 May 2014 10:33, Tom Chadwin  wrote:

> Hi Russ
>
> Yes, it's been a couple of years since we uploaded the data to our
> datacentre. I'll see if I've got a more up-to-date copy, and see if the
> problem persists. Regardaless, I'd still like to know what the explanation
> is.
>
> Thanks
>
> Tom
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139738.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
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

Hi Russ

Yes, it's been a couple of years since we uploaded the data to our
datacentre. I'll see if I've got a more up-to-date copy, and see if the
problem persists. Regardaless, I'd still like to know what the explanation
is.

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139738.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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-12 Thread Russell Hore

I get;

  TIFFTAG_DATETIME=2013:11:07 16:33:56
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD88

  TIFFTAG_DATETIME=2013:11:07 16:33:55
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD86

This is PSMA data.

Russ

On 12 May 2014, at 10:02, Tom Chadwin  wrote:

>> sd86 and sd88
> 
> GDALinfo indicates that it is a 2009 cut:
> 
>  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD86
>  TIFFTAG_DATETIME=2011:01:18 16:23:57
> 
>  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD88
>  TIFFTAG_DATETIME=2011:01:18 16:24:00
> 
>> I'll also double check GDALinfo on those two tiles.
> 
> Identical output, apart from filename, timestamp, and coordinate data.
> 
> Can anyone recreate this?
> 
> Thanks
> 
> Tom
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139734.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

--
"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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> sd86 and sd88

GDALinfo indicates that it is a 2009 cut:

  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD86
  TIFFTAG_DATETIME=2011:01:18 16:23:57

  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD88
  TIFFTAG_DATETIME=2011:01:18 16:24:00

> I'll also double check GDALinfo on those two tiles.

Identical output, apart from filename, timestamp, and coordinate data.

Can anyone recreate this?

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139734.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

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> I would make a new start and take first only two images and make an
imagemosaic from those.

OK, I've recreated the error with a mosaic of just two tiles. Same GS and
Tomcat log errors. If there are some UK GS 2.5 users out there with full
coverage of OS 50k tiles, try creating a new mosaic store with just the
tiles sd86 and sd88. Use an appropriate gridset (I've pasted mine below),
set the layer to bicubic interpolation, and then preview it in the tilecache
(PNG8).

If anyone can recreate, that would help. If not, I'll find out about whether
I can distribute these licence-encumbered tiles to someone else for testing.
I'll also double check GDALinfo on those two tiles.

Thanks

Tom

Gridset:

http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://geowebcache.org/schema/1.6.0
http://geowebcache.org/schema/1.6.0/geowebcache.xsd";
xmlns="http://geowebcache.org/schema/1.6.0";>
1.6.0
120

UK_OSGB

27700

0.0
0.0
70.0
130.0

false

2800.0
1400.0
700.0
350.0
175.0
84.0
42.0
21.0
11.2
5.6
2.8
1.4
0.7
0.35
0.14
0.07

1.0
2.8E-4

UK_OSGB:0
UK_OSGB:1
UK_OSGB:2
UK_OSGB:3
UK_OSGB:4
UK_OSGB:5
UK_OSGB:6
UK_OSGB:7
UK_OSGB:8
UK_OSGB:9
UK_OSGB:10
UK_OSGB:11
UK_OSGB:12
UK_OSGB:13
UK_OSGB:14
UK_OSGB:15

256
256
false

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139727.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Andrea Aime

On Thu, May 8, 2014 at 7:16 PM, Rahkonen Jukka (Tike) <
jukka.rahko...@mmmtike.fi> wrote:

> Hi,
>
> I would make a new start and take first only two images and make an
> imagemosaic from those. It it fails immediately, send links to those images
> and others could try to reproduce the error. It everything is fine, add a
> third image into the mosaic and test. Continue.
>
> But I wonder if the issue could come from somethign else. Is there
> anything that could prevent JAI from finding the width when GetMap BBOX is
> hitting the corner of four images?  What is the meaning of "affine" here:
> at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179)
> at org.geotools.image.ImageWorker.affine(ImageWorker.java:3113)
>
> Is there some reprojection job going on?
>

If there was you'd see a warp operation in the chain, affine is called just
to rescale the data or offset
the data, both opeations are common in a mosaic when you ask more than one
tile and/or
the target resolution does not match one of the source ones.

Cheers
Andrea

-- 
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Rahkonen Jukka (Tike)

Hi,

I would make a new start and take first only two images and make an imagemosaic
from those. It it fails immediately, send links to those images and others
could try to reproduce the error. It everything is fine, add a third image into
the mosaic and test. Continue.

But I wonder if the issue could come from somethign else. Is there anything
that could prevent JAI from finding the width when GetMap BBOX is hitting the
corner of four images? What is the meaning of "affine" here:
at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179)
at org.geotools.image.ImageWorker.affine(ImageWorker.java:3113)

Is there some reprojection job going on?

-Jukka Rahkonen-

Tom Chadwin wrote:

> On the grep process, have it grep out just -i "band" and see if any files
come back with more than one band defined. (grasping at straws now, but
maybe one of them will be attached to something :) )

No joy - all identical output apart from the filename, and the same number
of lines output as there are files. I guess I should double-check that there
is not a file which is giving multiple Band 1s, balanced out by the same
number which have no Bands, but I really don't think that's likely, is it?

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139272.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> On the grep process, have it grep out just -i "band" and see if any files
come back with more than one band defined. (grasping at straws now, but
maybe one of them will be attached to something :) )

No joy - all identical output apart from the filename, and the same number
of lines output as there are files. I guess I should double-check that there
is not a file which is giving multiple Band 1s, balanced out by the same
number which have no Bands, but I really don't think that's likely, is it?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139272.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Chris Snider

On the grep process, have it grep out just -i "band" and see if any files come 
back with more than one band defined. (grasping at straws now, but maybe one of 
them will be attached to something :) )

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
Direct (719) 452-7257



-Original Message-
From: Tom Chadwin [mailto:tom.chad...@nnpa.org.uk] 
Sent: Thursday, May 08, 2014 8:59 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GWC seeding: Error rendering coverage on the 
fast path

> Did you mod my example at all or did  you leave it to grep out the 
> band
gray and Band 1?

No, I did:

for i in $(find . -name "*.tif"); do var=`echo $i ;gdalinfo $i | grep -i 
"colorInterp"`; echo $var;done;

> Also, can you check your mosaic in standard Layer preview with the 
> single large tile?

OK, I _can_ see the big tile in OpenLayers layer preview. I'm sure this failed 
before, but let's forget that for the mo. 

> Additionally, instead of seeding, can you use the drop down under the 
> Preview column of the "Tile Layers" screen and choose one of the jpeg 
> options?  Do either of these methods work and display your completed
> image?   

I only have PNG8, as I unchecked the other options. When I choose this, I have 
a 4x4 block of broken tiles. Could the error be something to do with bands in 
the output tiles, rather than the input TIFFs? I'll gdalinfo them and see.

So now I look at it closely, I see something new: this tile gap does not 
correspond with a single source TIFF, but overlaps (presumably) four of them. 
What this means I do not know.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139266.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity • Requirements for 
releasing software faster • Expert tips and advice for migrating your SCM 
now http://p.sf.net/sfu/perforce ___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> I only have PNG8, as I unchecked the other options. When I choose this, I
have a 4x4 block of broken tiles. Could the error be something to do with
bands in the output tiles, rather than the input TIFFs? I'll gdalinfo them
and see.

Except I don't know how to identify which GWC tiles those are to check. And
the PNG8s probably don't exist anyway. The browser returns 400 Bad request
for them.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139269.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> Did you mod my example at all or did  you leave it to grep out the band
gray and Band 1?

No, I did:

for i in $(find . -name "*.tif"); do var=`echo $i ;gdalinfo $i | grep -i
"colorInterp"`; echo $var;done;

> Also, can you check your mosaic in standard Layer preview with the single
> large tile?

OK, I _can_ see the big tile in OpenLayers layer preview. I'm sure this
failed before, but let's forget that for the mo. 

> Additionally, instead of seeding, can you use the drop down under the
> Preview column of the "Tile Layers" screen and choose one of the jpeg
> options?  Do either of these methods work and display your completed
> image?   

I only have PNG8, as I unchecked the other options. When I choose this, I
have a 4x4 block of broken tiles. Could the error be something to do with
bands in the output tiles, rather than the input TIFFs? I'll gdalinfo them
and see.

So now I look at it closely, I see something new: this tile gap does not
correspond with a single source TIFF, but overlaps (presumably) four of
them. What this means I do not know.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139266.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Chris Snider

Tom,

Did you mod my example at all or did  you leave it to grep out the band gray 
and Band 1?  

Also, can you check your mosaic in standard Layer preview with the single large 
tile?  Additionally, instead of seeding, can you use the drop down under the 
Preview column of the "Tile Layers" screen and choose one of the jpeg options?  
Do either of these methods work and display your completed image?   

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.



-Original Message-
From: Tom Chadwin [mailto:tom.chad...@nnpa.org.uk] 
Sent: Thursday, May 08, 2014 8:13 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GWC seeding: Error rendering coverage on the 
fast path

> run a small script that runs gdalinfo on each file and grep out the 
> bands

Thanks for the example. I've run it on our full coverage (UK nationwide, 816 
TIFFs), and they all come out with identical info.

Where to look next? I'm about to try setting ExpandToRGB=true in the mosaic's 
.properties file.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139250.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity • Requirements for 
releasing software faster • Expert tips and advice for migrating your SCM 
now http://p.sf.net/sfu/perforce ___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> ExpandToRGB=true in the mosaic's .properties file.

No change in behaviour - same errors.

I am getting pretty baffled by this. Anyone have any other ideas?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139256.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> run a small script that runs gdalinfo on each file and grep out the bands

Thanks for the example. I've run it on our full coverage (UK nationwide, 816
TIFFs), and they all come out with identical info.

Where to look next? I'm about to try setting ExpandToRGB=true in the
mosaic's .properties file.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139250.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Chris Snider

You may need to increase the number of tiles surrounding the one to check for 
inconsistencies.  The default meta-tiling value if 4 X 4.  If you can run a 
small script that runs gdalinfo on each file and grep out the bands, you may 
find something that way.

Example we used for some information processing (adjust as required):

for i in $(find . -name "*.sid"); do var=`echo $i ;gdalinfo $i | grep -i 
"band.*Gray"`; echo $var | grep "Band 1";done;

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
Direct (719) 452-7257


-Original Message-
From: Tom Chadwin [mailto:tom.chad...@nnpa.org.uk] 
Sent: Thursday, May 08, 2014 7:12 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GWC seeding: Error rendering coverage on the 
fast path

> I'll do the same on the other adjacent TIFFs

I've now compared gdalinfo output of the TIFF in question with all of its eight 
surrounding TIFFs. The band/colour table information is identical:

Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
  Color Table (RGB with 256 entries)

All 256 colour table entries are also identical in all nine files.

Where should I look now?




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139239.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity • Requirements for 
releasing software faster • Expert tips and advice for migrating your SCM 
now http://p.sf.net/sfu/perforce ___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> I'll do the same on the other adjacent TIFFs

I've now compared gdalinfo output of the TIFF in question with all of its
eight surrounding TIFFs. The band/colour table information is identical:

Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
  Color Table (RGB with 256 entries)

All 256 colour table entries are also identical in all nine files.

Where should I look now?




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139239.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> Ah! It seems you have images in your mosaic that are not sharing the same
number of bands? That is indeed not supported, the images have to be uniform
at least for the color model (e..g, you cannot mix gray and rgb, byte and
float based, and so on).

I've just done a diff on the good and bad TIFFs' GDALinfo as above, this
time including the colour table info. No difference in number of entries in
colour table (256), type (byte), ColorInterp (palette), or even in the
contents of each of those 256 entries.

I'll do the same on the other adjacent TIFFs, assuming that those are the
ones likely to be involved in this process if I do limit the BBOX to the
problematic TIFF? Or can this error be thrown if a distant TIFF in the same
mosaic, nowhere near the GWV seed BBOX, differs in the way suggested?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139234.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-08 Thread Andrea Aime

On Thu, May 8, 2014 at 2:17 PM, Tom Chadwin  wrote:

> Caused by: java.lang.IllegalArgumentException: All source images must have
> the same number of bands.
>

Ah! It seems you have images in your mosaic that are not sharing the same
number of bands? That is indeed not supported, the images have to be uniform
at least for the color model (e..g, you cannot mix gray and rgb, byte and
float
based, and so on).

Cheers
Andrea

-- 
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> it would be good to capture just the failing request with all the
parameters and especially BBOX. 

How?

> gdal_translate -of GTIFF -co tiled=yes -co compress=LZW failing.tif
> new_copy.tif and change the new image into the mosaic directory.

Tried this - no change.

However, I now have more information. Tomcat stderr has this:

Error: One factory fails for the operation "Mosaic"
Occurs in: org.geoserver.jai.ConcurrentOperationRegistry
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.media.jai.FactoryCache.invoke(FactoryCache.java:122)
at
javax.media.jai.OperationRegistry.invokeFactory(OperationRegistry.java:1674)
at
org.geoserver.jai.ConcurrentOperationRegistry.invokeFactory(ConcurrentOperationRegistry.java:412)
at javax.media.jai.registry.RIFRegistry.create(RIFRegistry.java:332)
at javax.media.jai.RenderedOp.createInstance(RenderedOp.java:819)
at javax.media.jai.RenderedOp.createRendering(RenderedOp.java:867)
at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179)
at org.geotools.image.ImageWorker.affine(ImageWorker.java:3113)
at
org.geotools.gce.imagemosaic.RasterLayerResponse.postProcessRaster(RasterLayerResponse.java:1293)
at
org.geotools.gce.imagemosaic.RasterLayerResponse.processRequest(RasterLayerResponse.java:1235)
at
org.geotools.gce.imagemosaic.RasterLayerResponse.createResponse(RasterLayerResponse.java:1194)
at 
org.geotools.gce.imagemosaic.RasterManager.read(RasterManager.java:1125)
at
org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:629)
at
org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:608)
at
org.geoserver.catalog.SingleGridCoverage2DReader.read(SingleGridCoverage2DReader.java:140)
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.readBestCoverage(RenderedImageMapOutputFormat.java:1296)
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.directRasterRender(RenderedImageMapOutputFormat.java:861)
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:329)
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:251)
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:123)
at org.geoserver.wms.GetMap.executeInternal(GetMap.java:509)
at org.geoserver.wms.GetMap.run(GetMap.java:253)
at org.geoserver.wms.GetMap.run(GetMap.java:124)
at
org.geoserver.wms.DefaultWebMapService.getMap(DefaultWebMapService.java:328)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.geoserver.kml.WebMapServiceKmlInterceptor.invoke(WebMapServiceKmlInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.geoserver.gwc.wms.CacheSeedingWebMapService.invoke(CacheSeedingWebMapService.java:61)
at
org.geoserver.gwc.wms.CacheSeedingWebMapService.invoke(CacheSeedingWebMapService.java:35)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.geoserver.gwc.wms.CachingWebMapService.invoke(CachingWebMapService.java:79)
at
org.geoserver.gwc.wms.CachingWebMapService.invoke(CachingWebMapService.java:54)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.geoserver.ows.util.RequestObjectLogger.invoke(RequestObjectLogger.java:54)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at com.sun.proxy.$Proxy66.getMap(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.geoserver.ows.Di

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-07 Thread Rahkonen Jukka (Tike)

For me both gdalinfo reports look the same except the coordinates. Pity.
That tiff works with the WMS request does not guarantee that it returns with 
the GetMap that is sent by GWC. Because of that it would be good to capture 
just the failing request with all the parameters and especially BBOX. Perhaps 
WMS or JAI does not like to draw some adjacent granules together. That was why 
I asked to send the gdalinfo reports but they did not reveal anything. 

I do not understand much about the error message but perhaps the real error 
happens somewhere here
Caused by: java.lang.RuntimeException: - Unable to render RenderedOp for this 
operation.
at javax.media.jai.RenderedOp.createInstance(RenderedOp.java:827)
at javax.media.jai.RenderedOp.createRendering(RenderedOp.java:867)
at javax.media.jai.RenderedOp.getWidth(RenderedOp.java:2179)
at org.geotools.image.ImageWorker.affine(ImageWorker.java:3113) 

You can do a desperate trial by re-writing the failing image with GDAL
gdal_translate -of GTIFF -co tiled=yes -co compress=LZW failing.tif 
new_copy.tif and change the new image into the mosaic directory.

-Jukka Rahkonen-


Tom Chadwin wrote:

GDALinfo output below. As I say, though, the TIFF which will not cache will
be returned when requested by WMS.

Bad Tiff:

Driver: GTiff/GeoTIFF
Files: g:\data_dir\data\os\50k\sd86.tif
Size is 4000, 4000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.324964644,
AUTHORITY["EPSG","7001"]],
AUTHORITY["EPSG","6277"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4277"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-2],
PARAMETER["scale_factor",0.9996012717],
PARAMETER["false_easting",40],
PARAMETER["false_northing",-10],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","27700"]]
Origin = (38.000,48.000)
Pixel Size = (5.000,-5.000)
Metadata:
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD86
  TIFFTAG_DATETIME=2011:01:18 16:23:57
  TIFFTAG_COPYRIGHT=ORDNANCE SURVEY CROWN COPYRIGHT 2009
  TIFFTAG_XRESOLUTION=254
  TIFFTAG_YRESOLUTION=254
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  38.000,  48.000) (  2d18'24.22"W, 54d12'54.63"N)
Lower Left  (  38.000,  46.000) (  2d18'19.45"W, 54d 2'7.47"N)
Upper Right (  40.000,  48.000) (  2d 0'0.00"W, 54d12'56.04"N)
Lower Right (  40.000,  46.000) (  2d 0'0.00"W, 54d 2'8.86"N)
Center  (  39.000,  47.000) (  2d 9'10.92"W, 54d 7'32.10"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette

...and then the colour table.

Good TIFF:

Driver: GTiff/GeoTIFF
Files: g:\data_dir\data\os\50k\sd66.tif
Size is 4000, 4000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.324964644,
AUTHORITY["EPSG","7001"]],
AUTHORITY["EPSG","6277"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4277"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-2],
PARAMETER["scale_factor",0.9996012717],
PARAMETER["false_easting",40],
PARAMETER["false_northing",-10],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","27700"]]
Origin = (36.000,48.000)
Pixel Size = (5.000,-5.000)
Metadata:
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD66
  TIFFTAG_DATETIME=2011:01:18 16:23:41
  TIFFTAG_COPYRIGHT=ORDNANCE SURVEY CROWN COPYRIGHT 2009
  TIFFTAG_XRESOLUTION=254
  TIFFTAG_YRESOLUTION=254
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  36.000,  48.000) (  2d36'48.38"W, 54d12'50.42"N)
Lower Left  (  36.000,  46.000) (  2d36'38.84"W, 54d 2'3.28"N)
Upper Right (  38.000,  48.000) (  2d18'24.22"W, 54d12'54.63"N)
Lower Right (  38.000,  46.000) (  2d18'19.45"W, 54d 2'7.47"N)
Center  (  37.000,  47.000) (  2d27'32.72"W, 54d 7'29.30"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette

...and then the colour table.

Thanks for the help - I really appreciate it.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139059.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

---

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

GDALinfo output below. As I say, though, the TIFF which will not cache will
be returned when requested by WMS.

Bad Tiff:

Driver: GTiff/GeoTIFF
Files: g:\data_dir\data\os\50k\sd86.tif
Size is 4000, 4000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.324964644,
AUTHORITY["EPSG","7001"]],
AUTHORITY["EPSG","6277"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4277"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-2],
PARAMETER["scale_factor",0.9996012717],
PARAMETER["false_easting",40],
PARAMETER["false_northing",-10],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","27700"]]
Origin = (38.000,48.000)
Pixel Size = (5.000,-5.000)
Metadata:
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD86
  TIFFTAG_DATETIME=2011:01:18 16:23:57
  TIFFTAG_COPYRIGHT=ORDNANCE SURVEY CROWN COPYRIGHT 2009
  TIFFTAG_XRESOLUTION=254
  TIFFTAG_YRESOLUTION=254
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  38.000,  48.000) (  2d18'24.22"W, 54d12'54.63"N)
Lower Left  (  38.000,  46.000) (  2d18'19.45"W, 54d 2'7.47"N)
Upper Right (  40.000,  48.000) (  2d 0'0.00"W, 54d12'56.04"N)
Lower Right (  40.000,  46.000) (  2d 0'0.00"W, 54d 2'8.86"N)
Center  (  39.000,  47.000) (  2d 9'10.92"W, 54d 7'32.10"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette

...and then the colour table.

Good TIFF:

Driver: GTiff/GeoTIFF
Files: g:\data_dir\data\os\50k\sd66.tif
Size is 4000, 4000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.324964644,
AUTHORITY["EPSG","7001"]],
AUTHORITY["EPSG","6277"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4277"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-2],
PARAMETER["scale_factor",0.9996012717],
PARAMETER["false_easting",40],
PARAMETER["false_northing",-10],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","27700"]]
Origin = (36.000,48.000)
Pixel Size = (5.000,-5.000)
Metadata:
  TIFFTAG_IMAGEDESCRIPTION=1:5 TILE SD66
  TIFFTAG_DATETIME=2011:01:18 16:23:41
  TIFFTAG_COPYRIGHT=ORDNANCE SURVEY CROWN COPYRIGHT 2009
  TIFFTAG_XRESOLUTION=254
  TIFFTAG_YRESOLUTION=254
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  36.000,  48.000) (  2d36'48.38"W, 54d12'50.42"N)
Lower Left  (  36.000,  46.000) (  2d36'38.84"W, 54d 2'3.28"N)
Upper Right (  38.000,  48.000) (  2d18'24.22"W, 54d12'54.63"N)
Lower Right (  38.000,  46.000) (  2d18'19.45"W, 54d 2'7.47"N)
Center  (  37.000,  47.000) (  2d27'32.72"W, 54d 7'29.30"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette

...and then the colour table.

Thanks for the help - I really appreciate it.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139059.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

2014-05-07 Thread Rahkonen Jukka (Tike)

Hi,

For me it looks like it is not GWC that fails but WMS. GWC seems to wait a
response from the WMS but that never comes. Something goes wrong when WMS is
trying to process the metatile GetMap that is sent by GWC.
Perhaps if you enable request logging of your Jetty or Tomcat you could find
GetMaps which fail. I can't say out of memory how to configure the request
logging nor if GetMaps goes into the log when using the integrated GWC.

If you know which file makes troubles, run gdalinfo from that and also from one
of the well behaving images and send reports into the list.

-Jukka Rahkonen-

Tom Chadwin wrote:

> The problem does seem to be with specific source TIFFs in the mosaic, one of
which I have identified specifically. I can view it in layer preview as part
of the mosaic, but if try to seed a GWC job with the bounding box limited to
this one TIFF, it fails with the errors in the first post in this thread.

> What can cause GWC to fail on some TIFFs but not on others? In other words,
how do I investigate this further?

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139057.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

The problem does seem to be with specific source TIFFs in the mosaic, one of
which I have identified specifically. I can view it in layer preview as part
of the mosaic, but if try to seed a GWC job with the bounding box limited to
this one TIFF, it fails with the errors in the first post in this thread.

What can cause GWC to fail on some TIFFs but not on others? In other words,
how do I investigate this further?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139057.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path

> You might want to test the 2.5.x nightly snapshot to
see if that resolves the issue.

Installed the latest nightly: no change in behaviour.

I need to track down what I suspect might be problematic underlying tiles. I
can request them via plain WMS, just not via integrated GWC.

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5139040.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GWC seeding: Error rendering coverage on the fast path