[mapserver-dev] Scale Dependent Token Replacements: to mapscript or not to mapscript

Yves Jacolin yves.jacolin at camptocamp.com
Sat Dec 15 09:46:29 PST 2012


Hello,

I agree with Daniel and Worth :) I am working with mapscript to help to
generate mapfile to use it as map file configuration for WMs service. I
really need to get method to manage my mapfile.

[a little bit off topic]
I have the same issue with outputformat object: I can't get a list of
outputformat from the mapfile. outputformatlist() method doesn't exist in
python mapscript.
[/a little bit off topic]

Thanks,

Y.


2012/12/14 Daniel Morissette <dmorissette at mapgears.com>

> I object.  :)
>
> I agree with Worth that this should be supported in MapScript otherwise
> skipping features like this would mean that over time MapScript will become
> a second class citizen.
>
> Even if it is possible in theory to do the same thing in MapScript with
> custom code, RFC-86 proposes a nice way to handle a common need directly in
> the mapfile without custom coding, and my opinion is that a given mapfile
> should work the same way when rendered through the mapserv CGI as when it
> is rendered through MapScript. A generic MapScript app should be able to
> open any mapfile built for the CGI and render it without requiring custom
> code.
>
> Are the scaletokens processed at rendering time in your implementation? If
> yes then it should not be that hard to support it in MapScript, or is there
> some blocker that we are not aware of?
>
> My 0.02$
>
> Daniel
>
>
> On 12-12-14 3:41 AM, thomas bonfort wrote:
>
>> Devs,
>>
>> There's a point that I overlooked when submitting RFC86, which concerns
>> exposing the scale dependent token mechanism to mapscript.
>>
>> I'd argue that the whole point of the RFC is to simplify mapfile
>> management thus avoiding the use of mapscript in a number of cases, and
>> that there is no real usecase in exposing this API to mapscript (as a
>> mapscript script can do these replacements directly on the layer's
>> data/filter).
>> If there is no objection, I will amend the mapscript part of the RFC to
>> state: "Given the more straightforward methods to obtain the same
>> results as this RFC in mapscript, access to a layer's SCALETOKENs will
>>   not be exposed to mapscript for the time being".
>>
>> So, are there any objections? :)
>>
>> cheers,
>> thomas
>>
>>
>> ______________________________**_________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>
>>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> Provider of Professional MapServer Support since 2000
>
> ______________________________**_________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>



-- 

Responsable Formation et Support

Camptocamp France SAS

Savoie Technolac, BP 352

73377 Le Bourget du Lac, Cedex

Tel (France) : +33 4 79 26 57 98

Tel (Suisse) : 02 16 190 10 43 (new)

Mob. : +33 6 18 75 42 21

Fax : 04 79 70 15 81

Mail : yves.jacolin at camptocamp.com

http://www.camptocamp.com
<yves.jacolin at camptocamp.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20121215/eb243fe1/attachment.html>


More information about the mapserver-dev mailing list