[mapserver-dev] RFC 44

Fri Apr 25 12:45:53 EDT 2008

Paul,

   We made a few changes changes to our copy of mapraster.c back in v4.6.  The project we did the changes for is no 
longer active so we've not reconciled them to mapserver v5.  You're welcome to the "enhanced" mapraster.c if you want it.

   While I said below I don't want to re-project the data, I am considering it (terabytes are cheap!).  I'd like to make 
the data useful in WorldWind and other WMS clients.  It seems a lot of client apps demand raster data in EPSG:4326...

Brent

Paul Ramsey wrote:
> How do you do it now, Brent?
> 
> On Fri, Apr 25, 2008 at 9:01 AM, Brent Fraser <bfraser at geoanalytic.com> 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
>>>
>>>
>>  _______________________________________________
>>  mapserver-dev mailing list
>>  mapserver-dev at lists.osgeo.org
>>  http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
> 
> 