Opened 20 years ago
Closed 20 years ago
#596 closed enhancement (fixed)
Processing Directives
Reported by: | 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)
Change History (9)
by , 20 years ago
comment:1 by , 20 years ago
Cc: | 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 , 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 , 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 , 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 , 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 , 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:8 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
A patch against release 4.0.1 of Mapserver