[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