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