[mapserver-dev] RFC 44

[Stephen Woodbridge]

Paul,

This is a great idea! I can think of one minor (I think) thing you need 
to do for this. With tileindexes, if a .prj file exists then that would 
be used for ALL the files represented by the tileindex. This would avoid 
having to look at individual .prj which would be a preformance boost. 
And I'm not sure it makes any sense to have a tileindex with mixed 
projection without at least projecting the extents into the srs of the 
tileindex - I think we don't want to go there anyway.

This might mean that tile4ms should have an optional srs parameter 
and/or read and verify that all files added to the tileindex are from 
the same srs if they have .prj files.

Thoughts?
   -Steve

Paul Ramsey wrote:
> 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.
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev