Layer ordering toggle

[GoogleCodeExporter]

Create an implementer option that makes the layer ordering on the map be the 
same as the layer ordering in the layertree (top to bottom).

- Baselayers exempt - always at bottom.
- As the user drags layer around the layer tree they change order in the map.
- Layer order in the "Active Layers" panel should change to reflect any 
ordering change in the layertree, or layers toggling on/off etc.
- Legend should also reflect order of layers (top to bottom).

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 21 Jan 2014 at 3:37

[GoogleCodeExporter]

As I see it the layers are already from top to bottom?
Layer at top of layertree is draw as last in the map and thus at the top of the 
map.

Can you give some examples?

Original comment by rinke.he...@gmail.com on 23 Jan 2014 at 2:29

[GoogleCodeExporter]

Not in my applications. The ordering appears to be random.

Try:
http://maps.warwickshire.gov.uk/inspire/

District/Borough boundaries appear on top of County Boundaries. Then add 
Children Centre Areas and they're on the top.

Furthermore, the Legend order doesn't reflect this currently. If you Trigger 
them in the order:
Children's centres, districts, county - the Childrens centres will be on top, 
but on the legend they'll be on the bottom.

Hope that clarifies the issue.

Original comment by jonathan...@warwickshire.gov.uk on 24 Jan 2014 at 12:32

[GoogleCodeExporter]

In a "default" map with all layers in the Overlays folder the ordering in the 
map was all right. The initial legend order is in order of adding the layers, 
but does move with moving layers.
This ordering problem is happening in folders with layers like your inspire map.
That clarifies it.

Original comment by rinke.he...@gmail.com on 24 Jan 2014 at 12:58

• Changed state: Started

[GoogleCodeExporter]

Rev 1317
Finished work on layer ordering in a layer tree.
See new example layertreeordering
Added possibility to make ordering TopBottom and BottomTop
Default is 'none' (like it was before).

Original comment by rinke.he...@gmail.com on 7 Feb 2014 at 1:31

• Changed state: Fixed

[GoogleCodeExporter]

Example doesn't load; I get a completely white page!

http://lib.heron-mc.org/heron/latest/examples/layertreeordering/

Original comment by jonathan...@warwickshire.gov.uk on 7 Feb 2014 at 5:31

• Changed state: Started

[GoogleCodeExporter]

Rev 1322
Jonathan,
Sorry about that, I had a local file reference in the example, fixed it in rev 
1322 and tested it in latest examples. Works well now.

Original comment by rinke.he...@gmail.com on 7 Feb 2014 at 7:21

• Changed state: Fixed

[GoogleCodeExporter]

Add to 1.0.1

Original comment by jus...@gmail.com on 26 Feb 2014 at 12:07

• Added labels: Milestone-Release1.0.1
• Removed labels: Project-None

[GoogleCodeExporter]

Testing this now, I've come across a bug.

My layertree starts with the attached. I'm using "ordering: 'TopBottom',"

1) Turn on all three layers, they're in the correct order on the map and in the 
legend.

2) Drag "County Boundary" to the bottom, so it is in the "testing" folder below 
"Children Centre Areas".
It will go below District boundaries but still show up above the children 
centres. This is in both the map and the legend.

3) Now drag District boundaries between the other two. There's no change in the 
legend or map ordering.

Original comment by jonathan...@warwickshire.gov.uk on 26 Feb 2014 at 4:52

Attachments:

• Clipboard02.png

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Rev 1371
Fixed above problems, it was a bit more complex ....
Because of complexity the 'BottomTop' option is now removed so the ordering 
option is only effective with: 'TopBottom' (as requested).

Original comment by rinke.he...@gmail.com on 6 Mar 2014 at 3:06

[GoogleCodeExporter]

Get the following error since rev 1371:
Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; 
.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 
3.5.30729; InfoPath.1; .NET4.0C; .NET4.0E)
Zeitstempel: Fri, 7 Mar 2014 08:30:56 UTC
Meldung: 'map.resolutions.length' ist Null oder kein Objekt
Zeile: 356 Zeichen: 21
URI: http://isd.bku-web.db.de/LIB/heron-trunk/lib/widgets/LayerTreePanel.js

Original comment by wolfram.winter on 7 Mar 2014 at 8:34

[GoogleCodeExporter]

Rev 1374
Wofram,
Could not reproduce your error, but maybe the error was due to 
preloadChildren:true in the LayerTreePanel options, I needed it in a previous 
version, but removed it now.

Layer ordering was not always right when moving down a folder with checked 
layers.
Fixed this as well.

Original comment by rinke.he...@gmail.com on 7 Mar 2014 at 12:19

[GoogleCodeExporter]

I didn't use preloadChildren:true - but your changes works now for me - Thanks!

Original comment by wolfram.winter on 10 Mar 2014 at 7:04

[GoogleCodeExporter]

Wolfram,
It was in the options inside the LayerTreePanel.js, so that change did the 
trick.
Good to hear it is solved.

Original comment by rinke.he...@gmail.com on 10 Mar 2014 at 11:56

[GoogleCodeExporter]

Using 1.0.1 this isn't behaving as expected. The ordering in the legend appears 
to be random and doesn't always reflect the order on the layertree.
Moving layers around in the tree partially fixes things, but it seems to be 
intermittent and I can't identify the triggers.

Example:
1) http://maps.warwickshire.gov.uk (from tomorrow 2014-03-12 - until then it's 
only running 1.0.0)
2) Open Legend panel (on right)
3) Turn on Fire stations
4) Turn on One Stop Shops.

In the legend the Fire stations will be on top (wrong), but on the map the one 
stop shops are on top (correct).

---
Drag Fire stations above One Stop shops in the list. The map is correctly 
updated, but the legend changes to become wrong again.

----
Another example:
1) Reload
2) Turn on county boundary
3) Turn on Children Centre Areas
4) Turn on District Boundaries
They're correct on the map but wrong in the legend.

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 12:31

• Changed state: Started

[GoogleCodeExporter]

Jonathan,

It should work correctly from rev 1374 and should be included in Heron 1.0.2
You started the last tests after layerordering was included in Heron 1.0.1
So please update with at least rev 1374 or test in latest.

Original comment by rinke.he...@gmail.com on 11 Mar 2014 at 1:12

• Changed state: Fixed

[GoogleCodeExporter]

Hi Rinke, Thanks. Sorry I somehow completely failed to put together the 
timelines for 1.0.1 release and your post #10 here.
Thanks again,
Jonathan

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 1:13

[GoogleCodeExporter]

Re-opened and targeted for 1.0.2 - pls. close when considered fixed.

Original comment by jus...@gmail.com on 11 Mar 2014 at 1:38

• Changed state: Started
• Added labels: Milestone-Release1.0.2
• Removed labels: Milestone-Release1.0.1

[GoogleCodeExporter]

Now I'm getting confused about Status.
I did set it to "Fixed" (Developer made source code changes, QA should verify)
Now it is back to Started???
So I put it to Fixed again now because the fixes requested have been made by me.

When Jonathan has tested I'd say he should set it to "Done" (as it is closest 
to Close)

Original comment by rinke.he...@gmail.com on 11 Mar 2014 at 1:54

• Changed state: Fixed

[GoogleCodeExporter]

Yes the statuses are not very clear, because 'fixed' is a closed state, while 
as you clearly indicate it is really an open state. But when setting to 'fixed' 
the issue disappears from the issue lists and gets trike-through in WIki.  
'done' is related to non-coding tasks.  That was why I reopened.

So how to deal with this? It is a matter of convention, the statuses available 
are:

    Open Statuses:
     New     = Issue has not had initial review yet
     Accepted    = Problem reproduced / Need acknowledged
     Started     = Work on this issue has begun

    Closed Statuses:
     Fixed   = Developer made source code changes, QA should verify
     Verified    = QA has verified that the fix worked
     Invalid     = This was not a valid issue report
     Duplicate   = This report duplicates an existing issue
     WontFix     = We decided to not take action on this issue
     Done    = The requested non-coding task was completed

Practically a developer should set a bug/feature task to 'fixed' and then the 
"Jonathans" should set it to 'Verified'. 

This will be something to put on the dev wiki once the workflow is set. I will 
look into the adminstration if we can modify status settings.

Original comment by jus...@gmail.com on 11 Mar 2014 at 2:13

[GoogleCodeExporter]

I'm happy to use "Verified" - it's a good way for me to "sign off" on stuff.

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 2:19

[GoogleCodeExporter]

Original comment by jus...@gmail.com on 11 Mar 2014 at 2:24

• Changed state: Ready

[GoogleCodeExporter]

Ok, that was easier than I thought: any state value can be administered 
globally. It is only that about 250+ issues have the 'fixed' status. Making 
that an 'Open State' would us give all those 'fixed' issues in the list (and 
emails when setting them to 'verified'. So I introduced a 'Ready' status Open 
State. See current values:

    Open Statuses:
     New     = Issue has not had initial review yet
     Accepted    = Problem reproduced or feature/need acknowledged
     Started     = Work on this issue has begun and is in progress
     Ready   = Work has been completed and committed in Subversion, QA should verify

    Closed Statuses:
     Fixed   = Developer made source code changes, no verification required (minor bugs)
     Verified    = QA has verified that the fix worked
     Invalid     = This was not a valid issue report
     Duplicate   = This report duplicates an existing issue
     WontFix     = We decided to not take action on this issue
     Done    = The requested non-coding task was com

So the QA/Jonathans should verify on issues with the 'Ready' status and put 
these to 'Verified'. We can use 'Fixed' for minor bugs and other changes like 
documentation that are not verified/reviewed.
 Hope this workflow is acceptible to all.

So a typical new feature goes New --> Accepted --> Started --> Ready --> 
Verified
When the QA does not find it ready, he/she can put the issue back to 'Started'.

Minor changes go through:

    New --> Accepted --> Started --> Fixed

    New --> Accepted --> Started --> Done is typically for questions and support type-issues.

So this issue is now in 'Ready' :-)

Original comment by jus...@gmail.com on 11 Mar 2014 at 2:32

[GoogleCodeExporter]

The new "Ready" didn't last long I'm afraid.

I've now tested the latest; it's better but still exhibiting the problem. I 
think I may have a handle as to a cause this time though.

Layers that start with visible: true don't behave properly, either in the 
legend or the map.
Layers that are off by default work fine as best I can tell.

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 2:45

[GoogleCodeExporter]

So can you put the issue back to Started then? 

I did some writeup on
https://code.google.com/p/geoext-viewer/wiki/Contributing
Offcourse, we need state diagrams and such as found in many places e.g.
http://docs.joomla.org/Bug_Tracking_Process but we can take a more minimalistic 
approach for now.

Original comment by jus...@gmail.com on 11 Mar 2014 at 2:51

[GoogleCodeExporter]

Oh right. I did originally but we had an "collision" - you posted your thing 
(#23) at the same time as I posted mine (#24). So I had to re-post but forgot 
to change it the second time. Done this time.

Original comment by jonathan...@warwickshire.gov.uk on 11 Mar 2014 at 2:53

• Changed state: Started

[GoogleCodeExporter]

Rev 1393
Layers that get started with visible was a nasty one, but should be fixed now.

Just, I like the status change, makes it very clear!

Original comment by rinke.he...@gmail.com on 13 Mar 2014 at 12:09

• Changed state: Ready

[GoogleCodeExporter]

Ok, thanks. Jonathan: can you verify and hopefully set to 'Verified'?

Original comment by jus...@gmail.com on 18 Mar 2014 at 11:07

[GoogleCodeExporter]

Sorry for the delay, been v. busy these past few days.
All looks good now. Thanks Rinke!

Original comment by jonathan...@warwickshire.gov.uk on 19 Mar 2014 at 11:05

• Changed state: Verified