On Mon, 5 Feb 2007, Frank Warmerdam wrote:
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.
wow! thanks for the speedy delivery!
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.
ah. i actually tried OFFSITE 255 for exactly that reason. i thought it might work ;-)
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.
hmmm. i made those edits to the mapfile, which you can see here http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/mapfile then i ran this shp2img command shp2img -m index.map -i png -o a.png -e -180 -30 180 30 -l vis -all_debug 42 which was successful and created this http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/a.png progress! however, this is still not quite right. you can see in this loop http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/data/F1520070203.loop.gif that the roi is, in fact, covered on that western edge. i'm at a loss as to how that command could 'partially' work. is that the result you got? or was the entire longitudal range covered? also very strange, is that requests for individual orbits sometime work and sometimes do not http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/orbits.html try the second one: http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/?SERVICE=WCS&REQUEST=GetCoverage&Coverage=F15200702030145.nt.d.OIS.vis&CRS=EPSG:4326&BBOX=-180,-10,180,10&Format=png this file definitely contains data http://www.ngdc.noaa.gov/eog/maps/public/dmsp/F15/2007/02/01/demo/data/F15200702030145.nt.d.OIS.vis.png in fact, all of them do. i tried commenting out the OFFSITE sections of those layers with no luck - so some of them display totally blank.
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.
great!
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.
i'm bold. but government sysads tend to be slightly less so where the internet is concerned. ;-( thanks for the tip though. cheers. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. - the dalai lama
