[mapserver-users] MINSCALE/MAXSCALE for CLASS???

[Daniel Morissette]

Steve, and Steve,  :)

I understand the performance issue if this is abused, but I've seen
several cases where we just want to display the same data differently
depending on scale (think of a highways layer for instance... you want
it to be visible at all scales in a map, but displayed differently).  

In those cases we end up duplicating the layer definition multiple times
for each scale: always accessing the same shapefile but using different
class definitions... and this leads to overly complicated mapfiles.

If the class->scale test was done before evaluating the class expression
internally then I don't think there would be any performance impact
compared to duplicating the layer definition in the mapfile for each
scale as lots of people do right now.  The implementation could even be
smart enough to detect when all classes are out of scale and skip the
whole layer in this case.

Anyway, please count my vote on this... I've had this at the back of my
mind for quite a while already.

Daniel



Steve Lime wrote:
> 
> The main reason is performance. It's much more efficient to make scale
> based decisions at the layer level
> rather than having to get a feature, classify it and then dump it
> because of scale considerations. It could
> be added but I would advise against using it. Other thoughts?
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> >>> Stephen Woodbridge <woodbri at swoodbridge.com> 03/20/02 02:40PM >>>
> Steve Lime, et al,
> 
> Is there any reason why MINSCALE/MAXSCALE couldn't be added to the
> CLASS
> objects? It would greatly simplify creating the mapfile in many cases.
> A
> lot of my LAYERs are the same data only difference line weights at
> different scales.
> 
> Could we do something like CLASSITEM "{scale}" or whatever then use
> EXPRESSION to select on it.
> 
> Anyway, food for thought . . . back to building another mapfile.
> 
> -Steve W.