[mapserver-dev] RFC 100 : Support for tile index with mixed SRS in raster layers

Even Rouault even.rouault at mines-paris.org
Wed Jul 3 03:38:29 PDT 2013


Hi Thomas,

> Hi Even,
> This seems like a nice addition for folks handling large amounts of raster
> data in different projections. I don't have any important comments to make,
> just a few details you might want to explicit/fix:
> 
> - your mapfile snippet includes DUMP true which has been deprecated

Will remove it.

> - RFC 37 also proposed using PROJECTION AUTO, but to my knowledge was never
> adopted/implemented. Can you add a reference to that RFC in your proposal
> with a word of context on how they both relate ?

Ah indeed, I wasn't aware of RFC 37.

It seems that it is at least partially implemented in an embryonic way, since 
the LayerGetAutoProjection virtual method exists in the code base, and there 
was an implementation for maporaclespatial.c but it is disabled, and there's 
no caller of LayerGetAutoProjection.

In my implementation, the LayerGetAutoProjection() isn't used, but I extended 
to tileindex layers and shapefile layers what already existed for raster layers 
with a single DATA, i.e. that layer->projection is first resolved to an actual 
projection when layer->projection.args[0] == "auto" , before doing any 
reprojection.

> - I see you've added TILESRS as an rfc86 scaletoken replaceable string
> (thus with the storage of orig_tilesrs in layerObj). Is there a usecase for
> such a replacement to be done ?

Well, I didn't really understood what this orig_XXX stuff was supposed to do, 
but as I saw that tileitem/TILEITEM also used that mechanism, I blindlessly 
immitated that. But yes, this doesn't really make sense. I'll remove it from 
the implementation.

Thanks for your comments,

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the mapserver-dev mailing list