[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