[mapserver-dev] RFC 44

Stephen Woodbridge woodbri at swoodbridge.com
Fri Apr 25 14:04:03 EDT 2008


Brent,

Ok, that is an interesting use case. So you are looking to have a 
tileindex in a different projection that the underlying files and want 
files selected based on the tileindex and then the individual files 
reprojected based on their individual .prj files into whatever the map 
projection might be.

OK, I guess that makes sense to me.

-Steve

Brent Fraser wrote:
> 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
>>



More information about the mapserver-dev mailing list