Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
Add to 1.0.1
Original comment by jus...@gmail.com
on 26 Feb 2014 at 12:07
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:
[deleted comment]
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
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
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
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
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
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
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
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
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
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
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
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
Original comment by jus...@gmail.com
on 11 Mar 2014 at 2:24
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
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
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
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
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
Ok, thanks. Jonathan: can you verify and hopefully set to 'Verified'?
Original comment by jus...@gmail.com
on 18 Mar 2014 at 11:07
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
Original issue reported on code.google.com by
jonathan...@warwickshire.gov.uk
on 21 Jan 2014 at 3:37