Using .map file as a raster layer source

[Tamas Szekeres]

Frank,

Could the use of msImageCopyMerge or the generalization of msDrawMap (that
accepts the initial image as a parameter) solve problem you have mentioned?


Tamas


On Thu, 25 Aug 2005 10:43:38 -0400, Frank Warmerdam <fwarmerdam at GMAIL.COM>
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.
>>
>> The main benefits of this enhancement are:
>>
>> 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
>>
>> In order to try this functionality a patch have been added in
>> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1445
>
>Tamas,
>
>This is an interesting addition, but I am a bit uncertain whether it is a
>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
control
>than this, and needing to build mechanisms to satisfy it?  Does this
capability
>really give us something we wouldn't otherwise have?
>
>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
result.
>   At the very least it ought to error out gracefully for other return
results.
>
> o We would really need appropriate user documentation in order to
incorporate
>   this as a supported feature.
>
>As I see it, we have three options going forward:
>
> 1) The patch is incorporated as a fully supported feature of MapServer.
>     We would need documentation for this.  We would also need a
>     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,
but
>     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.
>
>I would be willing to vote "+1" on option 2 barring any compelling
>argument against it from others.  But I am concerned about the
>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).
>
>Best regards,
>--
>---------------------------------------+----------------------------------
----
>I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
>light and sound - activate the windows | http://pobox.com/~warmerdam
>and watch the world go round - Rush    | Geospatial Programmer for Rent