[mapserver-dev] RFC 44

[Paul Ramsey]

Comments appreciated, in particular regarding where in the lifecycle
this should be inserted:

========================================================
MS RFC 44: Automatic Projection Configuration for Layers
========================================================

:Date: 2008/04/24
:Author: Paul Ramsey
:Contact: pramsey at cleverelephant.ca
:Last Edited: 2008/04/24
:Status: Open

Overview
--------

In order to do reprojection, Mapserver currently requires a PROJECTION
block in the MAP file and in *every* LAYER block.  However, many (or
even most) layer types in Mapserver support retrieving SRS
information, from WKT files (like shape files .prj) or from tables
(like PostGIS spatial_ref_sys) or from the files themselves (like
GeoTIFF).

If the virtual layer API is extended to support automatic projection
configuration, new users can enjoy transparent support for
projections, while existing behavior and performance can be preserved
via the PROJECTION block.  Layers that cannot support automatic
projection will still require PROJECTION blocks, and map files that
have PROJECTION blocks can use those to avoid the overhead of
automatic projection configuration.

Technical Solution
------------------

We will add a new function to the layer->vtable, LayerLoadProjection.

*NEEDED:* where do we call LayerLoadProjection from for best effect?

LayerLoadProjection will:

 * Default to no-op and MS_SUCCESS
 * Load a projection if one is available, into layer->projection and
return MS_SUCCESS
 * Leave layer->projection alone and return MS_SUCCESS ASAP if no
projection is available
 * return MS_FAILURE in the event of something catastrophic (OOM, etc)
during load

Mapscript Implications
----------------------

See NEEDED above.

If LayerLoadProjection is called early in the lifecycle (during map
load, for example) then Mapscript can potentially read and over-ride
the projectionObj, which is good. If it is called late in the
lifecycle, then Mapscript cannot read the value, though it can still
over-ride it, simply by ensuring that a projectionObj with arguments
is set.

Files Affected
--------------

::

 maplayer.c
 mapshape.c (first implementation)
 map*.c (eventually all connection types that support automatic CRS discovery)

* Documentation will be updated to reflect the new feature

  * Mapserver CGI Reference

* Test suite will be updated to exercise the new features

  * Frank Warmerdam has volunteered to do this


Performance Implications
------------------------

PROJECTION blocks are faster than reading files and database tables
for this information. This feature will be slower than PROJECTION
blocks. The performance advantages of PROJECTION blocks will have to
be documented and highlighted.

In future phases, some performance issues can be shaved away by
starting to cache projection information so that FCGI implementations
do not have to re-read projection information or re-instantiate
projection objects ever.

Backwards Compatibility Issues
------------------------------

Installations with bad data (mismatched data and prj information)
might end up with an unexpected breakage. Installations with working
PROJECTION blocks already in place will have no problems.

Bug ID
------

Not yet.

Voting History
--------------

No vote yet.

References
----------

None.