[Mapserver-dev] IGNORE_MISSING_DATA - make this dynamic?

Paul Spencer pspencer at dmsolutions.ca
Wed Oct 20 18:49:02 EDT 2004


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 shapefiles 
>> are
>> not found that are expected (such as those from a tileindex, or the main
>> 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 their
>> maps as they work.
>>
>> I would like to suggest getting rid of the macro, and instead having a
>> layer or map level directive (via PROCESSING or CONFIG) to control this
>> dynamically.  Furthermore, I would like the default be to error-out on
>> missing data, so the user who anticipates this happening sometimes would
>> 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, and
> that this error be handled either by the programmer (in the mapscript case)
> or (in the CGI case) by blocks of code indicated by processing or config
> 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 ;)

Cheers,

Paul


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



More information about the mapserver-dev mailing list