Stephen Woodbridge wrote:
Re: [mapserver-users] Unexpected result from overlapping images in tile index
> Right, you can not rely on the tileindex from doing anything more than say
> these are the objects that intersect with your bbox.
True, if you use an unsorted shapefile tileindex. As mentioned, by using
sortshp utility it is possible to sort the index but that is not especially
admin friendly because there is no way to know if the shapefile is sorted and
by which attributes and as ascending or descending.
By saving the tileindex into Spatialite or PostGIS it is possible to filter and
sort the index on the fly as you wish in a controlled way. For example we are
rendering the newest orthophotos over the older ones this way:
LAYER
NAME "spatialite_tileindex"
STATUS ON
TYPE POLYGON
UNITS METERS
SIZEUNITS PIXELS
CONNECTIONTYPE OGR
CONNECTION "/orthophotos.sqlite"
DATA "select * from all_orthos where archived='false' order by year"
METADATA
"wms_title" "spatialite_tileindex"
"wms_srs" "EPSG:2393 EPSG:3067 EPSG:4326 EPSG:3857"
"wms_keywordlist" "technical_layer"
END #metadata
CLASS
NAME "footprints"
STYLE
WIDTH 0.91
OUTLINECOLOR 0 0 0
COLOR 39 200 55
END #style
END #class
PROJECTION
"init=epsg:3067"
END
END
LAYER
NAME "newest_orthophotos"
STATUS ON
TILEINDEX "spatialite_tileindex"
...
-Jukka Rahkonen-
-Steve W
On 1/19/2017 1:08 PM, Peter Schmitt wrote:
> 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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
>
> <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
>
> <https://github.com/pedros007/mapserver-tindex-problem/blob/master/gra
> y.png?raw=true>
>
> I have a
> tileindex http://bl.ocks.org/d/968e0f11f1fd9b02444c3765bbb285a1
> <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
>
> <https://github.com/pedros007/mapserver-tindex-problem/blob/master/exp
> ected.png?raw=true>
>
> but instead I get this:
>
> https://github.com/pedros007/mapserver-tindex-problem/blob/master/gray.png?raw=true
>
> <https://github.com/pedros007/mapserver-tindex-problem/blob/master/gra
> y.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
> <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
> <https://github.com/pedros007/mapserver-tindex-problem>
>
> --
> Pete
>
> _______________________________________________
> mapserver-users mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> <https://lists.osgeo.org/mailman/listinfo/mapserver-users>
>
>
>
>
> --
> Pete
>
>
> _______________________________________________
> mapserver-users mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
mapserver-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-users
