[mapserver-users] TileIndex - accuracy and truncation ?

Fri Jun 13 01:23:15 PDT 2014

Hi Jukka,

Thanks for the response.

I've set up an FTP access to browse the folder containing the generated PNGs and the tileindex:  ftp://hvmgo01.hvenegaard.dk/tiles_20140613/

The two (upper/lower) tiles mentioned earlier are # 281 and 311 respectively.

Feel free to use them for testing.

--

My source _is_ a mosaic (a 2,5 Gb GeoTIFF), but it performs terribly when used directly. That's why I'm chopping it up into multiple tiles.

And I'm outputting the tiles as PNG to facilitate transparency along the outer edges of the covered area. This is a must.

The coordinate system of both the source mosaic and the tiles are EPSG:25832, i.e. UTM zone 32N, ETRS 89.

All images are axis aligned to this projection. I.e. no reprojection takes place.

--

I really don't have any detailed experince with (Geo)TIFF, and I'm using FME to generate both the tiles and the tileindex in a single run.

I can fairly easily switch FME to generate GeoTIFF tiles, if it fits my purpose, but the meaning of many of the format parameters eludes me.

Can you advise me as to the optimal settings in the dialog below, if this is a solution ?

[cid:image001.png at 01CF86F0.8A9DE3B0]

Kind regards / Med venlig hilsen
Lars I. Nielsen
----------------------------------------------------------------
Landinspektør, Senior GIS Programmør og Konsulent
Hvenegaard Landinspektører A/S
Rugaardsvej 55, DK-5000 Odense C
Denmark
Tel. +45 6313 5050
http://www.hvenegaard.dk<http://www.hvenegaard.dk/>

Fra: Rahkonen Jukka (Tike) [mailto:jukka.rahkonen at mmmtike.fi]
Sendt: 13. juni 2014 09:02
Til: Lars I. Nielsen; 'mapserver-users at lists.osgeo.org'
Emne: Re: TileIndex - accuracy and truncation ?

Hi,

I am sure that the accuracy of tileindex vectors does not make the trouble.  The tileindex is only used for selecting which images will be needed for building the requested output image and this is done by selecting polygons which intersect with the requested BBOX.  Once the correct image files are selected the georeferencing of the images is read from the images themselves, in your case from png + WLD.

I suppose that white lines appear when the selected images are subsampled to a non-original pixel size for the output one by one. At the image boundary when the image pixels cover less than 50% of the output pixel area the corresponding output pixel is painted white. Let's say this was at the upper edge of the lower tile. Normally when the same pixel is rendered from the lower edge of the upper tile there should be more than 50% image data for the pixel and it should be rendered with color. Now for some reason also the upper tile yields white pixel and the result is "not data for this pixel in lower tile or in upper tile".

It is a bit heavy to try to solve the issue only by thinking.  Could you put two adjacent tiles with WLD files somewhere so I could have a try with them? Tell the EPSG code as well.  Meanwhile, if you have some experience on GDAL or if you are willing to learn you can also try to make the mosaic in another way than using tileindex. Create a GDAL virtual mosaic file with gdalbuildvrt tool and use the resulting .vrt file as datasource for your layer instead of tileindex. Read http://www.gdal.org/gdalbuildvrt.html and http://www.gdal.org/gdalbuildvrt.html.  As a result GDAL will take care of subsampling and it may give different results.

On the other hand, if you could tolerate using GDAL instead of FME you can avoid all the trouble by converting your original image into tiled and compressed geotiff with overviews.

-Jukka Rahkonen-

Lars I. Nielsen wrote:

Hi,

For performance reasons, I've (used FME to) split a large PNG into 450 small tiles, serving them with a Mapserver tileindex as a WMS service to a web solution.

Howeever, white lines appear between some of the tile rows (not all) at some scales (not all).

I've looked deeper into the WLD files for the individual tiles, and found that the calculations are accurate to 1/10 of a nanometer. At least if one uses all 10 decimals.

Tiles are 2254 pixels high, and (as per the WLDs below) 6138899.3169212583 - 0.0204375000 * 2254 = 6138853.2507962583 (almost equal to 6138853.2507962584)

Which leads me to suspect that some sort of truncation goes on, yielding some sort of rounding error.

Do anyone know whether the tileindex calculations truncates any of the values in the WLD files ? And if so, by how much ?

Cheers.

--

A typical map picture with a white line can be seen via this link:

http://hvmgo01.hvenegaard.dk/mswms/mapserv.exe?map=odensekkgd_wms.map&LAYERS=ASSISTENS&TRANSPARENT=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image/png&SRS=epsg:25832&BBOX=586609.80952408,6138781.1015875,586686.0222225,6138857.3142859&WIDTH=256&HEIGHT=256
Here's the WLD of the two tiles displayed in the picture:

Upper tile WLD:
0.0204375000
0.0000000000
0.0000000000
-0.0204375000
586620.6934394070
6138899.3169212583

Lower tile WLD:
0.0204375000
0.0000000000
0.0000000000
-0.0204375000
586620.6934394070
6138853.2507962584

--

Ps! As I wrote previously, I'm using FME to create the tiles. So I have little control over the actual coordinate and pixel values, and only specify the number of tiles I need. So manual truncation is not really a viable option.

Kind regards / Med venlig hilsen
Lars I. Nielsen
----------------------------------------------------------------
Landinspektør, Senior GIS Programmør og Konsulent
Hvenegaard Landinspektører A/S
Rugaardsvej 55, DK-5000 Odense C
Denmark
Tel. +45 6313 5050
http://www.hvenegaard.dk<http://www.hvenegaard.dk/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20140613/1b514ce6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 52928 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20140613/1b514ce6/attachment.png>