MS RFC 47: Move IGNORE_MISSING_DATA to run-time configuration¶
- Date:
2008/10/09
- Author:
Paul Ramsey
- Contact:
pramsey at cleverelephant.ca
- Last Edited:
2008/10/15
- Status:
Adopted on 2008-10-15 - Completed
- Version:
MapServer 5.4
Overview¶
Making the options for ignoring missing data in tile-indexed layers and WMS client layers more flexible, and configurable at run-time via the map file.
Technical Solution¶
Currently MapServer has only compile-time (./configure --ignore-missing-data) control of behavior when files referenced in tile indexes are missing, via the IGNORE_MISSING_DATA define, and that behavior is applied globally.
Under this RFC, the missing data behavior will be defined:
at run time
globally for a map file
As well, the option to "fail on a missing layer" will be added to the WMS client code, which currently defaults to "ignore on a missing layer".
All changes will preserve the current default behavior in cases where new behavior is not requested by the user: missing data in tileindexes will continue to cause failure and missing WMS layers will continue to be ignored, unless MapServer is compiled with --ignore-missing-data.
A map-level configuration option will be added, CONFIG "ON_MISSING_DATA" "[ACTION]", with the following valid actions: "IGNORE", "LOG", "FAIL". The default map-level behavior will be "FAIL", unless MapServer is compiled with --ignore-missing-data, in which case it will be "LOG". This will preserve the current behavior for all legacy mapfiles and compile set-ups.
In the case of "LOG" behavior, the logging will only occur if the mapfile is set up for logging: DEBUG is set and MS_ERRORFILE is set. Documentation must note that DEBUG and MS_ERRORFILE need to be set.
At the same time, this ticket (#2722) can probably be tracked down and resolved.
Mapscript Implications¶
None.
Files Affected¶
mapshape.c
mapogr.c
mapraster.c
maprasterquery.c
Documentation will be updated to reflect the new feature
MapServer Mapfile Reference
Backwards Compatibility Issues¶
None. Legacy mapfiles and compile setups should retain existing behavior in the presence of this new code.
Bug ID¶
Voting History¶
N/A
References¶
N/A