[mapserver-dev] RFC 44

[Brent Fraser]

Steve,

   I disagree, it would make sense (to me anyway).   My scenario:

I've got 60 UTM zones worth of Landsat mosaic I want to serve up.
     - I don't want to re-project them all (it's 300 gb of wavelet compressed data) to a single (geographic?) projection
     - I want to use one tileindex layer in my map file in EPSG:4326 (ok, actually several of them due to external 
raster pyramids)

So my tileindex would have
PROJECTION
     "init=epsg:4326"
END

and my raster layer referencing the tileindex layer would have
PROJECTION
     "AUTO" # or something like it to indicate the data SRS def is in the data file not the tileindex def.
END

Brent Fraser

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