On Fri, May 16, 2014 at 10:37 AM, Rahkonen Jukka (Tike) <
jukka.rahko...@mmmtike.fi> wrote:
> Hi,
>
> Yes, I can repeat the error. At one certain zoom level requests to get
> some tiles always fail. The error at Geotools dev level is:
>
> 16 touko 11:25:35 ERROR [org.geowebcache.GeoWebCacheDispatc
Thanks, Jukka. It's good to know it was not just caused by some
misconfiguration by me.
Can anyone shed any light on the log Jukka has posted?
Thanks
Tom
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Re-GWC-seeding-Error-rendering-coverage-on-the-fast-path-tp5140684p51
Env = {}
Angle = 0.0
CQLFilter = null
Elevation = []
FeatureId = null
FeatureVersion = null
SRS = EPSG:4326
SldBody = null
Sld = null
Tiled = false
TilesOrigin = null
Layers = [org.geoserver.wms.Map
Has anyone been able to recreate the problem using the two TIFFs I linked to?
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Error-rendering-coverage-on-the-fast-path-tp5138864p5140671.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
---
-Original Message-
> From: Rahkonen Jukka (Tike) [mailto:jukka.rahko...@mmmtike.fi]
> Sent: 14 May 2014 12:12
> To: Tom Chadwin; 'geoserver-users@lists.sourceforge.net'
> Subject: Re: [Geoserver-users] GWC seeding: Error rendering coverage on
> the fast path
>
> H
Hi,
I have not tried myself, but it might be doable with gdal_rasterize
http://gdal.org/gdal_rasterize.html
Digitize a big polygon that covers your images, save as "mask.shp" and then run
gdal_rasterize -burn 100 -l mask.shp image.tif
Not sure if it works with paletted images but try and you wi
Alternatively, can anyone suggest a way in which I could blank out the visual
content of the TIFFs without damaging any of the other content relevant to
GDAL (I presume opening in Photoshop and filling with white is unlikely to
preserve all the metadata required). If I can do that, I can see if the
Hi,
Making it work with poor quality is better than nothing. What irritates me is
that you could not make it work through image mosaic. However, without original
images it is rather impossible for us to do anything more. You have already
tried remotely all that we have been able to suggest.
Le
OK, that all seems to have worked - many thanks. I am going to try rerunning
it, though, as the image quality is not good enough. I'll see if Lanczos is
available on my install, or look at the other options.
Any thoughts on the fact that the TIFF is bigger than the 2GB mentioned in
the docs as pot
Hi Tom,
Good questions:
> - is the resultant file a single GeoTIFF, and hence should I create that
> type of layer in GS?
>
It is a single file and should be loaded as such. So just "add geotiff" on
the stores.
>
> - do these GeoTIFF overviews perform better than a GS-generated image
> pyramid
Hi Jonathan
Just running the last stage of your script now - should complete overnight.
A couple of beginner's questions:
- is the resultant file a single GeoTIFF, and hence should I create that
type of layer in GS?
- do these GeoTIFF overviews perform better than a GS-generated image
pyramid?
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 th
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
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 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 origin
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 resolut
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 i
>
>
>> 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 f
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
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 buildi
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 u
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.buildLayerI
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.
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
> 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 outp
> 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
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 ev
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 issu
> 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 the
) 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 d
> 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
> 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?
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 n
> 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
Se
> 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 fil
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
> 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 colou
> 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 TIFF
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 t
> 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 inf
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. P
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",
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
Get
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 th
> 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
--
> There were some issues with 2.5.0 and raster stuff. Some of them have been
fixed for the 2.5.1. You might want to test the 2.5.x nightly snapshot to
see if that resolves the issue.
Will do.
> Alternately you might want to try deleting and re-adding the layer that is
giving you issues.
Yes, I'v
Hi Tom,
There were some issues with 2.5.0 and raster stuff. Some of them have been
fixed for the 2.5.1. You might want to test the 2.5.x nightly snapshot to
see if that resolves the issue.
Alternately you might want to try deleting and re-adding the layer that is
giving you issues. I'm assuming th
Ah, it's not just GWC. WMS is failing with the same errors for tiles which
come from some specific TIFFs.
Any ideas?
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/GWC-seeding-Error-rendering-coverage-on-the-fast-path-tp5138864p5138880.html
Sent from the GeoServer - Use
Full log:
2014-05-06 17:36:29,046 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: Error rendering coverage on the
fast path
at
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:331)
at
org.geoserver.wms.map.RenderedIma
Hello all
I am trying to seed an imagemosaic in integrated GWC (GS 2.5.0). This process
has worked for various of my layers, but fails in one, with the following
errors:
Error rendering coverage on the fast path
Unable to render RenderedOp for this operation
Problem communicating with GeoServe
50 matches
Mail list logo
