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

[Worth Lutz]

I admit I quickly sent the previous email without much thought. I mostly use
mapscript and have code which get its direction from the mapfile.

 

Here is an example, which again is a quick thought,

 

Have a mapscript program fed a mapfile as input.

 

A particular layer (named LayerX) uses the scaletokens to choose an
appropriate shapefile.

 

Two different mapfiles have "LayerX" but the scale breakdown is different in
the two mapfiles.

 

The mapscript needs to know the scale breakdown to do something. I have no
idea what. :-)

 

The mapscript code retrieves the scaletoken information and does its
processing.

 

Again this is a contrived idea based on some of my mapscript coding from the
past.  The scaletoken information could be put into meta data but why have
it twice?

 

I'm not asking for this to be done at this time, only playing "devil's
advocate" to get the thought in someone else's head.  Reading your email put
this idea in mine and I thought I should share it.  :-)

 

Worth

 

  _____  

From: thomas bonfort [mailto:thomas.bonfort at gmail.com] 
Sent: Friday, December 14, 2012 9:41 AM
To: Worth Lutz; MapServer Dev Mailing List
Subject: Re: [mapserver-dev] Scale Dependent Token Replacements: to
mapscript ornot to mapscript

 

Worth,

 

I'm not sure I understand the "code mapfile specific information into
generic code which gets the specific information from the mapfile." part.
Could you give an example of that?

 

Supposing that you have a mapscript application that needs to modify a
layer's data based on scale:

Currently, you'd be doing something like:

 

setup map size and extent

if(scale<1000):

  layer.data="foo.shp"

else

   layer.data="bar.shp"

map.draw()

 

if mapscript had access to scaletokens, that code would become:

 

layer.setscaletoken("token",0,1000,"foo.shp")

layer.setscaletoken("token",1000,infinity,"bar.shp")

setup map size and extent

map.draw()

 

>From my point of view, the first method is clearer. I also can't really come
up with a use-case where a mapscript application would need to *discover*
what scaletokens where configured in a mapfile for a given layer. Should
such a use-case arise, then I agree that exposing scaletokens would be
necessary.

regards,

 

thomas 

 

On Fri, Dec 14, 2012 at 3:16 PM, Worth Lutz <wal3 at mindspring.com> wrote:

As user of mapscript, I sometimes write generic code to use different
mapfiles for either different clients or other reasons. The mapscript code
is generic and the specifics are in the mapfile. In other words, I would not
like to have to code mapfile specific information into generic code which
gets the specific information from the mapfile.  

 

I have not thought much about this use case, but think that maybe a generic
application written in mapscript might use this information in some way.
Then again, just having the layer set up in the mapfile might be enough.
Again I have not thought this through very well.

 

That said, I have no immediate need where I might need to use this.

 

Thanks to all the MapServer Developers,

 

Worth Lutz

 

  _____  

From: mapserver-dev-bounces at lists.osgeo.org
[mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Friday, December 14, 2012 3:42 AM
To: MapServer Dev Mailing List
Subject: [mapserver-dev] Scale Dependent Token Replacements: to mapscript
ornot to mapscript

 

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

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5957 - Release Date: 12/13/12

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5957 - Release Date: 12/13/12

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20121214/14188899/attachment-0001.html>