Using .map file as a raster layer source

Sean Gillies sgillies at FRII.COM
Thu Aug 25 10:56:15 EDT 2005


On Aug 25, 2005, at 8:43 AM, Frank Warmerdam wrote:

> On 8/25/05, Tamas Szekeres <szekeres.tamas at freemail.hu> wrote:
>> It would be useful to make the possibility to use a .map file as a 
>> data
>> source of a raster layer in another .map file.
>> =20
>> The main benefits of this enhancement are:
>> =20
>> 1. High number of maps could be joined into a single map. The maps 
>> could
>> be organized hierarchically.
>> 2. Tileindex support can be used to filter the maps to be drawn.
>> 3. There's no need to create temporary images in the filesystem as 
>> with
>> WMS layers
>> =20
>> In order to try this functionality a patch have been added in
>> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=3D1445
>
> Tamas,=20
>
> This is an interesting addition, but I am a bit uncertain whether it 
> is a=
> =20
> good general addition to MapServer.  Once concern I have is about the 
> fact
> that sub-maps can generally not be influenced by the calling map 
> except for
> setting of the target extent. Are we likely to find people wanting 
> more con=
> trol
> than this, and needing to build mechanisms to satisfy it?  Does this 
> capabi=
> lity
> really give us something we wouldn't otherwise have?=20
>
> A few details:
>  o The patch does not address RGB, RGBA or other types of render 
> results.  =
> It
>    seems that it assumes the result of the drawMap() is an 8bit GD 
> image re=
> sult.
>    At the very least it ought to error out gracefully for other return 
> resu=
> lts.
>
>  o We would really need appropriate user documentation in order to 
> incorpor=
> ate
>    this as a supported feature.=20
>
> As I see it, we have three options going forward:
>
>  1) The patch is incorporated as a fully supported feature of 
> MapServer.=20
>      We would need documentation for this.  We would also need a=20
>      detailed proposal to the technical steering committee on the 
> feature.
>      There would likely need to be significant discussion and revision 
> of
>      the patch.
>
>  2) We apply the patch "as is", perhaps with better error trapping for
>      non-8bit imagObj results and it is an unsupported and undocumented
>      feature of MapServer.  You might want to submit a specific howto 
> for
>      the web site on using it, but we wouldn't try and document it in 
> the
>      main references.  We would likely still need TSC approval for 
> this, bu=
> t
>      I don't think we would need to set a high bar since it wouldn't 
> affect
>      any other functionality.
>
>  3) The patch is not applied to MapServer, but you can of course 
> continue
>      to use it for your local use.=20
>
> I would be willing to vote "+1" on option 2 barring any compelling=20
> argument against it from others.  But I am concerned about the=20
> conceptual complexity of making it a fully supported feature of 
> MapServer
> (option 1).
>
> Contrats on a cool hack!  (I mean hack in the most positive sense).=20
>

Neither of you say it, but to me this seems to be sorta like an inline 
WMS. I like the idea, and we should see about fitting it into the 
proposed new layer architecture.

Sean

--
Sean Gillies
sgillies at frii dot com
http://zcologia.com



More information about the mapserver-dev mailing list