WMS-C different transformed layers

Jody Garnett added a comment - 14/Aug/09 7:02 PM That is a very fun effect. A couple of ideas ... The original tiles are a fixed size; and it looks like each one may be being transformed individually; rather then them being formed into a single image and then transformed as a whole?

Jody Garnett added a comment - 14/Aug/09 7:04 PM Graham/Emily do you know know what is up here? Looks like we are getting a mess of tiles back and returning them as individual grid coverages; rather then stitching them up into a moasic. It actually looks like things would be fine if the grid coverages were rendered a) larger b) with correct "no-data" sections.

Emily Gouge added a comment - 17/Aug/09 1:17 PM This is the results I would expect to see with the way we are processing the data. Each tile is downloaded from the tile server, re-projected if necessary, and displayed on the screen. When re-projected the black areas appear as we don't have information outside the tile to put in this area. We can't change the size of our requests because these are tiles and we don't have any control over the tile-size. It doesn't really make sense to view the tiles in a different projection than they are stored in. To make this work properly you have to create another tilecache in the projection you want to use the data in. I'm pretty sure it doesn't have anything to do with the image format (png/jpeg).

Georg Weickelt added a comment - 18/Aug/09 1:02 AM But why there is a difference between these two layers? "tk10" is also from the same tileserver and looks good, has no black areas. I agree, the image format can't be the reason. I tried the same with png-tiles with the same behavior. For me it makes sense to use another projection: - easy to use with UDIG, - and this public server only delivers EPSG 31468, I use 31469.

Georg Weickelt added a comment - 18/Aug/09 9:23 AM I found the difference: tk10 is transparent, ortho_rgb06 is not transparent. I changed to transparent tiles and it looks much better. Thanks for your help.

Emily Gouge added a comment - 18/Aug/09 4:23 PM Thanks Georg for sorting this out. You are correct; I've looked a little more closely at the code and the example you provided and the tiles are actually overlapping when they are in the other projection. When the images are transparent then you see the correct data coming through, however if they are not transparent than the "no data area" of the tile is filled in with black when re-projected and you can't see through to the other tile that has the data. Interesting problem and good to know for the future.

Jody Garnett added a comment - 01/Sep/09 12:59 AM Thanks for following this one up Emily - I was worried we would need to stitch together an image moasic out of the TileSet and offer a single resulting GridCoverage to the GridCoverageRenderer. So is this a won't fix? With a known workaround - or something we should look at?

Emily Gouge added a comment - 01/Sep/09 11:40 AM I would classify this as won't fix. I suppose we could look at stitching together all the image mosaic tiles then do the projection. However in my opinion, that's a lot of work for something that seems to have only come up once and has a reasonable work around. Maybe if the issue becomes more prevalent (or the workaround doesn't work for somebody) we look at stitching together the tiles?

Jody Garnett added a comment - 01/Sep/09 11:36 PM Sounds like it is something to look at with Simone has a "moasic operator" I will mark it down as won't fix.

Jody Garnett added a comment - 01/Sep/09 11:37 PM We are not in a position to fix this one right now; when GeoTools has a moasic operator this issue can be revisited. Please use the workaround described above.