MapTools.org

[Chameleon] Raster Processing Option

Paul Spencer spencer@dmsolutions.ca
Wed, 28 Jan 2004 08:41:29 -0500
Thanks for being generous :)

seriously, though, perhaps part of the problem is really in mapserver. 
Chameleon typically uses a "Read-Write" mode of preserving state with 
mapfiles which means that it saves a copy of the map file for every 
page.  In some cases this is overkill, but when there is a lot of state 
to maintain ... or if layers are being added/removed ... then it is a 
much more robust way of maintaining state.

I am suspecting one of two things:

1. there is a problem when MapServer saves a map file containing this. 
It is not common for mapserver users to use PHP MapScript to save map 
files, mostly its a read-only operation, so it possible that there is a 
bug in here

2. the other possibility (more unlikely I think) is that you are not 
using the version of mapserver that you think you are, and the version 
you are using has problems.

To test the save thing, use a little php script like:

<?php

dl( 'php_mapscript_41.dll' ); //replace with your version and extension

$oMap = ms_newMapObj( 'path-to-your-mapfile.map' );
$oMap->save( 'path-to-a-temp-file.map' );

echo "<pre>";
print_r( file_get_contents( 'path-to-a-temp-file.map' );
echo "</pre>";
?>

that will tell us right away if there is a problem with saving 
processing options ... in which case it is more of a mapserver issue 
than a Chameleon issue and should be reported appropriately in the 
mapscript bugzilla.

Cheers,

Paul

Jeff Hamm wrote:

>  
> I've still not had any resolution of my problem of enabling the 
> PROCESSING "BANDS=5,4,3" for raster images within Chameleon 
> 1.1alpha6. My map file (with Landsat image) works fine under Mapserver 
> 4, but won't produce any image using MapDHTML widget(just the 
> waitimage), unless I comment out the PROCESSING directive, in which 
> Chameleon produces a map, without any processing. Same thing occurs with 
> other PROCESSING options, such as SCALE.
>  
> Some pertinent extracts from the Map file:
>  
> IMAGETYPE png24:
>  
>   OUTPUTFORMAT
>     NAME png24
>     MIMETYPE "image/png"
>     DRIVER "GD/PNG"
>     IMAGEMODE RGBA
>  END
>  LAYER
>     DATA "o55_18ref.tif"
>     NAME "o55_18"
>     GROUP "Base"
>     SIZEUNITS PIXELS
>     STATUS ON
>     TOLERANCE 0
>     TOLERANCEUNITS PIXELS
>     TRANSPARENCY 50
>     TYPE RASTER
>     UNITS METERS
>     PROCESSING "BANDS=5,4,3"
>     OFFSITE 255 255 255
>     PROJECTION
>     "proj=aea"
>     "ellps=GRS80"
>     "lat_0=59"
>     "lon_0=-132.5"
>     "lat_1=61.667"
>     "lat_2=68"
>     "x_0=500000.0"
>     "y_0=500000.0"
>     "units=m"
>     "no_defs"
>     END
>     METADATA
>      "wms_title" "o55_18"
>      "wms_group_title" "Base"
>     END
> END
>  
> Is there a workaround? Because the Map file seems to get corrupted when 
> the PROCESSING directive is included (an extra END gets inserted in the 
> LAYER object according to the tmp map files), is there a parsing issue 
> somewhere?
> If anyone has Landsat processing working within Chameleon, what's the 
> proper configuration in a Linux/Apache installation of Mapserver 4.0:
>  
> MapServer version 4.0 OUTPUT=PNG OUTPUT=WBMP SUPPORTS=PROJ 
> SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT INPUT=TIFF 
> INPUT=EPPL7 INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE
>  
> I'd really prefer to put the Chameleon version into production, which 
> works well enough aside from this problem (I'm being generous), but this 
> is a show stopper. Any helpful comments appreciated.
>  
> Jeff Hamm
> GIS and Planning Advisor
> Yukon Land Use Planning Council
> Whitehorse, Yukon
> 867 667 7397
>  

-- 
  -----------------------------------------------------------------
|Paul Spencer                           spencer@dmsolutions.ca    |
|-----------------------------------------------------------------|
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
  -----------------------------------------------------------------



This archive was generated by Pipermail.