[mapserver-users] Performance implications of OFFSITE usage?

[Stephen Lime]

It hits every output pixel anyway when resampling as you suggest. Actually
all that happens with OFFSITE or raster classes is that changes to the default
lookup table are made. So for each pixel the raw value is translated to a color
index in the output image. OFFSITE pixels aren't even considered. Actually
it's marginally faster to use OFFSITE since it skips an assignment statement and
the test has to happen on all pixels.

That said, no overlap is certainly better since no output pixels would be assigned
values twice. I guess it depends on the amount of overlap you're talking about
removing.

Steve

Stephen Lime
Internet Applications Analyst

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> "Ed McNierney" <ed at topozone.com> 07/19/01 12:37PM >>>
I'm doing some testing with USGS DRG maps projected as UTM and
collar-clipped.  My initial test took the raw output files - one per DRG
- and used the OFFSITE parameter to cause the pixel value 0 (black) to
be transparent.  This allowed me to create a TILEINDEX file for the raw
DRGs and just let MapServer take care of the overlap.

I've also got a DRG mosaic/clipping tool that can take these raw,
collar-clipped DRGs, mosaic them together, then chop out rectangular (in
UTM space) tiles.  I can then load them into a new TILEINDEX shapefile
and avoid using the OFFSITE parameter because the tiles do not overlap.

Now that I'm halfway through this I'm doubting the wisdom of it.  My
motivation was that the use of the OFFSITE parameter was forcing
MapServer to examine the value of every pixel rather than just process
them in bulk.  Avoid this should be a performance win.  I'm now
wondering whether that's a bogus assumption; when rescaling the source
TIFFs to produce the output image, enough pixel-level processing must be
going on that the OFFSITE comparison could be a trivial impact.

If anyone's got sage advice, experience with the libtiff or mapraster
code that's doing this, or just random opinions <g>, I'd appreciate any
thoughts.  Thanks!

	- Ed

Ed McNierney
Chief Mapmaker
TopoZone.com
ed at topozone.com 
(978) 251-4242