$oLayer->set("status",MS_DELETE) vs. $oMap->moveLayerUp($i)

[huub@…]

I suppose this is a Chameleon bug, but...

I try to change the drawing order of layers in the map
by using 
   $oMap->moveLayerUp($i); // and $oMap->moveLayerDown($i); 

The map is updated correctly so i should say that MapScript works. But the
Chameleon framework does not update the legend list that is generated by de
legend template that is used by a LegendTemplate.widget

This in contrast to another task in the same application :
removing a layer from the map

by using
   $oLayer = $oMap->getLayer($i);
   $oLayer->set("status",MS_DELETE) ;

this removes the layer from the map and also the legend list is updated correctly.

How can this happen?


Huub

[dmorissette]

Paul, Assefa, does that ring any bell to you?  Sounds like a problem with the
LegendTemplate widget in Chameleon so I would be tempted to shovel that to the
Chameleon bugzilla.

[assefa]

I think It should go to Chameleon Bug. What I think is happening is maybe the
template widget is parsed before the movelayer widget.
If that is the case, the template widget should get a setting of a priority
lower that the movelayerwidget (or the movelayer widget get a higher priority).
The default setting is PRIORITY_MEDIUM so something like PRIORITY_LOW (for the
template widget) or PRIORITY_HIGH (for the movelayer) could do the trick.

[huub@…]

..is parsed before the movelayer widget...

i tried to prevent this by 
1. putting the LegendTemplate after  my LayerMove widget
2. giving LayerMove widget priority Medium, high, super, god (which is a curse)

Huub

[pspencer@…]

I suspect chameleon also, but it doesn't make sense.  I will attempt to confirm
that mapserver is doing the right thing first by isolating this using a small
script.

[huub@…]

I have come to the conclusion that this is a mapscript / -server error

It looks to me like changing the layer status is processed correctly in memory,
but changing layer metadata is  not. 


I tried to change the internal name of the sessionmapfile on the fly
by using $_SESSION["gszCurrentState"] = $this->moApp->moMapSession->saveState();

In these files is don't understand what happens
the original file with 
layer "roads"  "LEGEND_ORDER" "1"
layer "parks" "LEGEND_ORDER" "2"

is then printed as 
layer "parks" "LEGEND_ORDER" "2"
layer "roads"  "LEGEND_ORDER"  "1"

In the written files the requested changes are only partly reflected. That is: 
changing the layer order with moveLayer results in a switch of the layerobject, 
but het legend_order metadata is not changed. Even with explicit code after de 
moveLayer function

Only after a second update in Chameleon the correct legend_order is written in 
de session map file

layer "parks" "LEGEND_ORDER" "1"
layer "roads"  "LEGEND_ORDER"  "2"

It looks like the processLegendTemplate function still reads its layer_metadata 
info (layer_order) from the original mapsession object 

But when from does it get the correct settings after the second update?

Hope I helped you to trace down something...

Huub

[pspencer@…]

okay, finally got to this.  I have built a small script that demonstrates the
problem.  I can replicate the problem outside of chameleon so I think it is
something in MapServer to do with how layer order is changed and how the
processLegendTemplate function enumerates the layers.

The script loads the gmap map file, outputs the layer names, processes a legend
template, moves a layer, and then repeats the output (which doesn't change). 
There are two lines in the middle of the script that save and reload the map
file.  If these are uncommented, then the change takes effect.

This is essentially what Huub was attempting to do with the saveState() call
(although that won't work correctly for a couple of reasons).

We could use saving the map file as a work around, but this is a serious
performance hit.  The last time I did any profiling, loading and saving the map
are among the top consumers of time (order of 200 ms per, if I remember
correctly), which isn't bad if you only load and save once, but we will be
adding close to .5 secs to every page if we do it this way.

Huub, if the workaround is important for you, then I can try to implement it (it
will invovle more than two lines, unfortunately, because the whole application
state needs to be reset properly).

Script will be attached next.  The script is set up for my machine to use the
GMap data (which I won't attach) and a legend template from chameleon (which I
will attach) in an ms4w directory structure.

[pspencer@…]

sample script to replicate problem with moving layers and processing legend templates

[pspencer@…]

legend template used with test script

[huub@…]

The workaround you suggest implies a performance decrease for all update 
requests? I wouldn't want to jump to this because you suggest is dives into 
more the one PHP file? It would have an impact on Chameleon as a whole?

Then maybe i would like to wait for suggestions of the two collegues.

Maybe it is a (clumsy i agree) solution to put the legend widget seperately in 
a IFRAME that will be updated twice after the use of layerup/down?

Huub

[pspencer@…]

it would be for all update requests, but it wouldn't affect more than just the
one widget.  What I meant was that changing the saving/loading the current state
would  have to be done very carefully to make sure that the main chameleon
components are aware of the change (i.e. new map object etc).

the iframe could be used too ... approximately same performance hit though.

[dmorissette]

Julien, could you please have a look at this one.  See comment #6, Paul created
a a sample script to reproduce this outside of Chameleon.

[jlacroix]

In sortLayerByMetadata(), the legend template processing was resetting the layer
order to make it reversed. But the mapfile layer order was taken instead if the
original layer order. So the layers moved up and down were ignore. Now the
reversed layer order is use instead of the mapfile layer order. 

Marking as FIXED
Only available in mapserver 4.1, if you want me to apply this fix in mapserver
4.0 please reopen.