Opened 20 years ago

Closed 20 years ago

#596 closed enhancement (fixed)

Processing Directives

Reported by: josb@… Owned by: sdlime
Priority: high Milestone:
Component: MapScript-SWIG Version: 4.0
Severity: minor Keywords:
Cc: sgillies@…

Description

Mapserver .map files allow for raster layers to have "PROCESSING" directives to
allow input bands to be selected, scaled etc. Perl mapscript (and others based
on the SWIG interface) do not have this. I have written a couple of routines to
add this functionality. Following are some patches against release 4.0.1 of
Mapserver.

diff -2 -r mapserver-4.0.1/map.h mapserver-4.0.1-new/map.h
733c733,735
< #ifndef SWIG
---
> #ifdef SWIG
> %immutable;
> #endif
735a738,739
> #ifdef SWIG
> %mutable;
diff -2 -r mapserver-4.0.1/mapscript/mapscript.i
mapserver-4.0.1-new/mapscript/mapscript.i
579a580,605
>   /* addProcessing()
>    */
>   void addProcessing(char *processingString) {
>     /* NOTE: processing array maintained as size+1 with NULL terminator.
>       This ensure that CSL (GDAL string list) functions can be
>       used on the list for easy processing. */
>     if(processingString == NULL) return;
>     self->num_processing++;
>     if(self->num_processing == 1)
>       self->processing = (char **) malloc(2*sizeof(char *));
>     else
>       self->processing = (char **) realloc( self->processing, 
>         sizeof(char*) * (self->num_processing+1) );
>     self->processing[self->num_processing-1] = processingString;
>     self->processing[self->num_processing] = NULL;
>   }
> 
>   /* clearProcessing()
>    */
>   void clearProcessing(void) {
>     if( self->num_processing > 0 )
>       msFreeCharArray( self->processing, self->num_processing );
>     self->processing = NULL;
>     self->num_processing = 0;
>   }
>

Attachments (1)

diff (1.2 KB ) - added by josb@… 20 years ago.
A patch against release 4.0.1 of Mapserver

Download all attachments as: .zip

Change History (9)

by josb@…, 20 years ago

Attachment: diff added

A patch against release 4.0.1 of Mapserver

comment:1 by sgillies@…, 20 years ago

Cc: warmerdam@… mapserver-bugs@… added
I'm going to CC Frank Warmerdam as well since he is the author of the
processing directives.

I haven't been using the processing so I am not clear on the usage.
Your use case is one where you would set several directives and then
clear them all when they are unwanted?  Is there any need to selectively
remove directives?  Any need to inspect a layer for processing directives
that may be defined?  Like

   if (layer.getProcessing(0) == 'A Directive'):
       # Do something ...

Also, I'd like to suggest that we change the layerObj member num_processing
in map.h to "numprocessing".  This better matches the style of other
quantity attributes in MapServer (like numlayers, numclasses, numstyles ...)

comment:2 by fwarmerdam, 20 years ago

Yikes, 

I didn't realize there was a patch for this.  Based on the email to the list
I added setProcessing() to add a processing directive. 

I originally called it addProcessing() (and in fact I implemented an underlying
msLayerAddProcessing()) but I ended up calling it setProcessing() for similarity
to the existing PHP setProcessing() method. 

It would be sensible to change num_processing to numprocessing, but I don't 
don't particularly see the need for mapscript to apps to query the processing
directives so it isn't a high priority for me.  

It also isn't clear to me that a clearProcessing() method is needed. 
 
I guess there is a broader question of what degree of fine control over stuff we
want to give mapscript applications.  My preference would be to avoid cluttering
the mapscript APIs with control over stuff never likely to be used.  


comment:3 by dmorissette, 20 years ago

For the record, the following methods are already implemented in PHP MapScript:

   boolean setProcessing(string)
        Add the string to the processing string list for the layer.
        The layer->num_processing is incremented by 1.
        Ex : $oLayer->setprocessing("SCALE_1=AUTO");
             $oLayer->setprocessing("SCALE_2=AUTO");       

   aString getProcessing()
        Returns an array containing the processing strings

   boolean clearProcessing()
        Clears all the processing strings


Your proposed getProcessing(int index) would differ a bit from the PHP version,
we may have to do something to keep both in sync.  Perhaps a dual behavior in
the PHP version: if the optional index argument is passed then it returns a
single directive in the format "NAME=VALUE", and if the optional index is
omitted then it would return an array with all the directives as it does
already.  The behavior can also be extended in SWIG MapScript the day you have
typemaps for arrays of strings.

comment:4 by sgillies@…, 20 years ago

My ZMapServer product would use a getProcessing method.
Integral to ZMapServer is a map configuration form (sorta like maplab)
and I'll need to present to users the current values of processing
directives, and therefore also need to access the number of directives.

In my opinion, getProcessing should return one processing directive
in the same way that getLayer returns one single layer.  It provides
the API with some consistency and that means users don't have to
go to the documentation quite as much.  When getProcessing returns
an array, it is sort of unexpected behavior when compared to other
get* methods.

But maybe that's just me, I'm a bit obsessive about symmetry and
uniformity. :)

I really can't ever see us supporting arrays generally in the SWIG
mapscript.  And it's quite easy to create them on the fly using Python
list comprehensions like

directives = [layer.getProcessing(i) for i in range(layer.numprocessing)]

I think that Perl and Ruby can do one-liners like this as well.

comment:5 by fwarmerdam, 20 years ago

I am convinced that we should rename num_processing to numprocessing, and
add a getProcessing() method that returns one line. 

Who wants to do this? 

comment:6 by dmorissette, 20 years ago

I agree with your consistency argument, but I like the getProcessing() returning
an array because it's very handy to deal with, and I'm mostly worried about
breaking backwards compatibility since getProcessing() was there in PHP
MapScript 4.0.

Anyway, hopefully very few people are using it and the change won't affect too
many people.

comment:7 by sgillies@…, 20 years ago

Status: newassigned
I'll pick this one up.

comment:8 by sgillies@…, 20 years ago

Resolution: fixed
Status: assignedclosed
Done.

Extended layerObj with setProcessing (renamed Frank's addProcessing),
getProcessing and clearProcessing methods.  See doc/mapscript.txt for
details.

Tried to avoid a global renaming of num_processing by using a SWIG
rename directive ... this didn't work out, so I did change num_processing
to numprocessing everywhere in MapServer.  MapServer compiles and all my
Mapscript unit tests pass, so I think there should be no problems.

Daniel, I wasn't sure how you would want to resolve this on the php end,
so I left the attribute of your PHP proxy class as "num_processing".

There is a new test case in mapscript/python/tests/testMapScript.py with
a couple tests of the processing directives.

Note: See TracTickets for help on using tickets.