uDIG

wms layer ordering

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: UDIG 1.1-SC1, UDIG 1.2.M0
  • Fix Version/s: UDIG 1.2.M0
  • Component/s: webservices
  • Labels:
    None
  • Environment:
    mac os x 10.5, leopard

Description

I am advancing and starting to use multiple nested wms layers from the same wms server This is all with uDig-1.1-SC2.

In the Add Data dialog topmost-level layers with a name seem to be ordered opposite of the ordering in GetCapabilities. This is however fixed when the layers are added. So in the Layers-list-tab in the left and in the Projects-tree, the ordering is correct.
Possible fix: Perhaps the ordering in the Add Data dialog should be the same as in GetCapabilities?

For nested layers, the situation seem to be more messy. The ordering in the Add Data dialog seem to be alphabetical by the layer title and not the ordering from the GetCapabilities-document. When those layers are added, the layers rearrange to totally random.

  1. Text File
    UDIG-1431-1.1.x-part1.patch
    26/Sep/08 5:21 PM
    3 kB
    Tore Halset
  2. Text File
    UDIG-1431-1.1.x-try2.patch
    28/Sep/08 5:57 PM
    4 kB
    Tore Halset
  1. add-1.png
    36 kB
    17/Sep/08 2:44 AM
  2. add-2.png
    36 kB
    17/Sep/08 2:44 AM
  3. add-3.png
    37 kB
    17/Sep/08 2:44 AM
  4. added-list.png
    11 kB
    17/Sep/08 2:45 AM

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tore Halset added a comment -
URL: http://dalsnuten.ecc.as/ecc/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities
Username: guest
Password: guest

As you see from add-1.png, add-2.png and add-3.png the order of the layers and nested layers is random and even varies from time to time. I would like this order to be the same as the order in the GetCapabilities-document as the order matter, otherwise the end user may end up with the background layer in front.

As you see from added-list.png, the CellLayer ended up in the middle of the list. I want that to be on top of the list as it is first in the GetCapabilities-document.

Yes, I know the user can drag and drop layers to reorganize the order, but the defaults should be better.

Show
Tore Halset added a comment - URL: http://dalsnuten.ecc.as/ecc/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities Username: guest Password: guest As you see from add-1.png, add-2.png and add-3.png the order of the layers and nested layers is random and even varies from time to time. I would like this order to be the same as the order in the GetCapabilities-document as the order matter, otherwise the end user may end up with the background layer in front. As you see from added-list.png, the CellLayer ended up in the middle of the list. I want that to be on top of the list as it is first in the GetCapabilities-document. Yes, I know the user can drag and drop layers to reorganize the order, but the defaults should be better.
Hide
Permalink
Jody Garnett added a comment -
This seems a resonable request; are you comfortable working on this issue Tore? It sounds like the solution is going to cover a few area of the code ...
- the AddLayer wizard page
- the process of adding layers to the Map
- anything else?
Show
Jody Garnett added a comment - This seems a resonable request; are you comfortable working on this issue Tore? It sounds like the solution is going to cover a few area of the code ... - the AddLayer wizard page - the process of adding layers to the Map - anything else?
Hide
Permalink
Tore Halset added a comment -
Yes, I can take a look at it. Perhaps during FOSS4G.
Show
Tore Halset added a comment - Yes, I can take a look at it. Perhaps during FOSS4G.
Hide
Permalink
Tore Halset added a comment -
Work in progress. This patch keep the order in the "Add Data" dialog over to the map. The problem was that the layers was keys in a HashMap. After switching to LinkedHashMap, the ordering is kept.

There is still one more problem. The order of the layers in the "Add Data" dialog varies as well. It is always correct the first time a WMS is connected, but wrong after then. Perhaps the layer list is cached in the catalogue or anything.

Show
Tore Halset added a comment - Work in progress. This patch keep the order in the "Add Data" dialog over to the map. The problem was that the layers was keys in a HashMap. After switching to LinkedHashMap, the ordering is kept. There is still one more problem. The order of the layers in the "Add Data" dialog varies as well. It is always correct the first time a WMS is connected, but wrong after then. Perhaps the layer list is cached in the catalogue or anything.
Hide
Permalink
Tore Halset added a comment -
This fixes the issue in 1.1.x as far as I can see for now..

Have not tried in trunk (yet)
Show
Tore Halset added a comment - This fixes the issue in 1.1.x as far as I can see for now.. Have not tried in trunk (yet)
Hide
Permalink
Jody Garnett added a comment -
That is cool; the catalog does try and save the order of things between runs; I am not too sure of the details?
Show
Jody Garnett added a comment - That is cool; the catalog does try and save the order of things between runs; I am not too sure of the details?
Hide
Permalink
Jody Garnett added a comment -
Are you going to (or have you already) applied the patches above?
Show
Jody Garnett added a comment - Are you going to (or have you already) applied the patches above?
Hide
Permalink
Tore Halset added a comment -
I am using the try2-patch myself and it is working nicely. It would be nice if you could apply it to the svn branches. The patch is against 1.1.x as I have not managed to get trunk up and running on my mac.
Show
Tore Halset added a comment - I am using the try2-patch myself and it is working nicely. It would be nice if you could apply it to the svn branches. The patch is against 1.1.x as I have not managed to get trunk up and running on my mac.
Hide
Permalink
Jody Garnett added a comment -
I have applied the patch to trunk as of -r30861
Show
Jody Garnett added a comment - I have applied the patch to trunk as of -r30861
Hide
Permalink
Jesse Eichar added a comment -
applied to 1.1.0
Show
Jesse Eichar added a comment - applied to 1.1.0
Hide
Permalink
Tore Halset added a comment -
This fix was not completely correct. It made the order of the layers consistent, but the ordering of the wms layers is reversed. This is simply fixed by removing the reversing of the layer list.
Show
Tore Halset added a comment - This fix was not completely correct. It made the order of the layers consistent, but the ordering of the wms layers is reversed. This is simply fixed by removing the reversing of the layer list.
Hide
Permalink
Tore Halset added a comment -
This patch removes the invalid Collections.reverse(..)
Show
Tore Halset added a comment - This patch removes the invalid Collections.reverse(..)
Hide
Permalink
Tore Halset added a comment -
That patch made the ordering correct for wms, but reveresed the order of the feature types for wfs. It should probably be fixed in the Add Data dialog for wms instead. Sorry.
Show
Tore Halset added a comment - That patch made the ordering correct for wms, but reveresed the order of the feature types for wfs. It should probably be fixed in the Add Data dialog for wms instead. Sorry.

People

  • Assignee:
    Unassigned
    Reporter:
    Tore Halset
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: