[Mapserver-dev] IGNORE_MISSING_DATA - make this dynamic?

Steve Lime steve.lime at dnr.state.mn.us
Thu Oct 21 08:31:46 EDT 2004

Frank et al. I agree with Frank. I tend to think CGI first and then
MapScript, so solutions need to help both camps and Frank's does this.
However, it's not a priority at all so it shouldn't jump ahead of other
bugs for 4.4. I think a CONFIG option makes sense.


>>> Paul Spencer <pspencer at dmsolutions.ca> 10/20/04 5:49 PM >>>
Sean Gillies wrote:
> On Oct 20, 2004, at 2:26 PM, Frank Warmerdam wrote:
>> Folks,
>> Currently we have a macro called IGNORE_MISSING_DATA that if defined
>> causes MapServer to quietly proceed if some raster files or
>> are
>> not found that are expected (such as those from a tileindex, or the
>> DATA file for a layer).  It would appear, at least on Unix, that this

>> symbol
>> is normally defined meaning that most mapserver binaries are very 
>> forgiving
>> (but not terribly informative) about layers with missing files.
>> I feel that having it as a compile time directive makes it harder for

>> folks
>> who just receive binaries to control this behaviour.  Also, having it
>> turned on by default makes it harder for folks to debug problems in
>> maps as they work.
>> I would like to suggest getting rid of the macro, and instead having
>> layer or map level directive (via PROCESSING or CONFIG) to control
>> dynamically.  Furthermore, I would like the default be to error-out
>> missing data, so the user who anticipates this happening sometimes
>> have to add the directive to get the more forgiving behaviour.
>> Any thoughts on this?  Is this a feature that should be put off till 
>> after
>> the 4.4 release?  Should I just forget the idea?
>> Best regards,
> Frank,
> I'd be OK with this.  My preference is for MapServer to set an error,
> that this error be handled either by the programmer (in the mapscript
> or (in the CGI case) by blocks of code indicated by processing or
> directives.
> Sean
> -- 
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies

I'd like to second Sean in this.  In php/mapscript there are a number of

cases when fatal errors are produced that could be handled much more 
reasonably if mapserver just returned error codes and recorded the 
errors internally in its error stack.  The 'terminate with prejudice' 
approach makes it really hard to build applications that behave 
predictably ;)



> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu

More information about the mapserver-dev mailing list