[mapserver-users] Unexpected result from overlapping images in tile index

[Peter Schmitt]

Thanks for the sortshp tip!  You are correct -- sorting the tileindex
yields the result I expected.

If the black pixels cover the full extents of black.tif (ie. with zero
NODATA values), then Mapserver will render either an all black or an all
gray image, regardless of the sorting order in the non-overlapping
geometries in the tileindex.  When I internally tile the source images and
zoom in, Mapserver does something curious: If the intersection between the
tileindex and the requested bbox contain a single record, Mapserver will
render the correct image.  When I zoom in, Mapserver renders an aliased
image on the 256x256 WMS requests sent by the client.  I would guess the
requested BBOX is intersected with the tileindex.  When the intersection
yields a single item in tileindex, it renders the correct image.  When
there are two items in the intersection of the requested BBOX and
tileindex, the images are painted over the full requested BBOX in the order
provided by the tileindex.

I also could not find any docs/requirements on a tileindex guaranteeing
ordering of the stacking images returned by the tileindex... so I guess
it's best to not rely on this and just burn in NODATA/an external mask to
my source images if I need such behavior.

Thanks again,
Pete


On Thu, Jan 19, 2017 at 4:31 AM, thomas bonfort <thomas.bonfort at gmail.com>
wrote:

> Peter, if I understand correctly....
> I'm not aware that there is any documentation or requirement that using a
> tileindex with mapserver garantees any ordering in the stacking of the
> images returned by the tileindex. Namely, if your tileindex returns your
> gray (opaque) image after (i.e. on top of) your black/white image, then
> your black/white image will be completely obscured by your gray image.
> This is what I'd try:
> - try using the sortshp utility on your tileindex (once in ascending
> order, once in descending) and see if the resulting image is affected
> - use a postgis based tileindex layer with explicit ORDER BY clauses to
> enforce that transparent images get rendered after opaque ones
>
> --
> thomas
>
> On Thu, Jan 19, 2017 at 12:31 AM Peter Schmitt <pschmitt at gmail.com> wrote:
>
>> Hi,
>>
>> I have a tile index to render a layer from two images.  The images are
>> black.png  https://github.com/pedros007/mapserver-tindex-problem/blob/
>> master/black.png?raw=true which has NODATA values over the white areas
>> and grayscale pixels with intensity 1 and gray.png with intensity 128 and
>> zero NODATA values in the image https://github.com/pedros007/
>> mapserver-tindex-problem/blob/master/gray.png?raw=true
>>
>> I have a tileindex http://bl.ocks.org/d/968e0f11f1fd9b02444c3765bbb285a1
>> that basically stacks/flattens the black image on top of the gray one.
>> However, when I make a WMS request to the layer:
>>
>> LAYER
>>         NAME my_layer
>>         TYPE RASTER
>>         TILEINDEX tindex.shp
>>         TILEITEM "location"
>>         OFFSITE 0 0 0
>>         STATUS OFF
>>     END
>> END
>>
>> I get only the gray image.  In other words, I expected to get this:
>> https://github.com/pedros007/mapserver-tindex-problem/blob/
>> master/expected.png?raw=true
>>
>> but instead I get this:
>> https://github.com/pedros007/mapserver-tindex-problem/blob/
>> master/gray.png?raw=true
>>
>> I have a couple of work-arounds that I'm not crazy about:
>>
>> 1. Add Layer masks http://www.mapserver.org/
>> development/rfc/ms-rfc-79.html to two separate layers, make two WMS
>> requests and stack the results client side. I have gotten this working for
>> two layers. However, I may need to render a very large number of such
>> layers and think this wont work client-side (via OpenLayers-3).
>> 2. I could burn in NODATA values (or use a mask) to gray.tif, but I'd
>> rather not modify my source data.
>>
>> A version of this email & example files are in a GitHub repo:
>> https://github.com/pedros007/mapserver-tindex-problem
>>
>> --
>> Pete
>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>


-- 
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20170119/5557d3fe/attachment.html>