non-square shapefiles and tileindex

[Frank Warmerdam]

Ara.T.Howard wrote:
> On Sat, 3 Feb 2007, Frank Warmerdam wrote:
> 
>> Ara,
>>
>> Yes, I do that frequently.  Note that all items from the tileindex that
>> touch the map request area *are* rendered.
> 
> huh.  that's not what i'm seeing, so i've probably made a mistake.
> 
> for instance, if you make this request
> 
>   
> http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/?SERVICE=WCS&REQUEST=GetCoverage&Coverage=vis&CRS=EPSG:4326&BBOX=-180,20,180,30&Format=png 
> 
> 
> you'll see only one orbit in the image.  this is odd since every orbit 
> crosses

Ara,

OK, with the data package you provided, I was able to reproduce the problem.
In fact, all the orbits were being drawn, but the OFFSITE wasn't working as
desired so nodata was being written over valid data.

There are two problems.

The first is that OFFSITE is completely ignored for greyscale input data.
I believe I omitted this because it seemed to me that the OFFSITE ought
to apply to the input pixel value, but that was difficult since OFFSITE
is an RGB tuple.

The second problem is that OFFSITE processing is applied *after* any
scaling or other processing.

As it turns out the greyscale processing does try to honour known nodata
values marked in the metadata of the source raster.  So you can either add
it in the .hdr files (I don't think GDAL supports this for ENVI files) or
you can provide an override in the map file as a processing statement.

eg.
   PROCESSING "NODATA=255"

However, it turns out that NODATA testing is applied *after* scaling as
well due to the way processing in MapServer works.  This is clearly
not what you would desire, and it in fact gets reported as an issue
in the debug stream if you have debug on.  By by careful selection of
your scaling in your case you can ensure that only the 255 values end
up mapping to 255 in the final result.  To do that I slightly altered
your scaling to:

   PROCESSING "SCALE=0,64"
   PROCESSING "NODATA=255"

Thus any value of 64 or higher is mapped to 255, and values from 0-63 are
mapped to 0 to 254 or so.  This gives the desired output.

I have filed the following bug report with regard to OFFSITE values.  I
believe that OFFSITE values ought to be supported for greyscale inputs,
and they should be interpreted in terms of the output RGB tuple that would
be produced.

   http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=2024

BTW, in MapServer 5.0 the new RFC 21 color correction allows easier
non-linear color correction on the fly.  In your case the following
produces better results than the simple linear scaling:

   PROCESSING "LUT=0:0,20:128,63:254"

If you are bold, you might consider upgrading to MapServer 5 (aka development
version) and experiment with that.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org