[mapserver-dev] RFC 44

[Paul Ramsey]

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
>