Rendering top WMS layers

[jas511]

In my app, I am importing many WMS layers (say 20-30 for this problem). The problem is that many of them are large layers that cover large areas, such as DEM data. Others though are smaller layers such as country boundary lines.

The problem is that I always want to render the layers like country boundaries layer, but if I have multiple larger layers, I only want to render the one on top, because it takes a lot of CPU usage to get the images from the WMS server and draw the images. It is slowing my app down to a crawl because I'm rendering the layers I can't even see. It is also causing a "flashing" effect because both the bottom and top layers are both rendering, so depending on the image retrieval, certain areas will flip between the two layers.

I've tried using the opaque value of the layer capabilities to determine if it should always be rendered or not (I render only transparent layers all the time, and only the top opaque layer), but that only works if the layers are properly marked (which seems that is often not the case). Rendering only the top layer does not seem like it will work because then layers that should show up, like the country boundaries, will not.

Are there any known ways to work around this problem?

EDIT: It looks like my major problem was that I was importing each WMS layer as a separate worldwind layer, rather than putting them all in the same WMS Layer (and specifying multiple names). But any other thoughts would be appreciated.

Thanks,
Jeff

[nlneilson]

Originally Posted by jas511

EDIT: It looks like my major problem was that I was importing each WMS layer as a separate worldwind layer, rather than putting them all in the same WMS Layer (and specifying multiple names). But any other thoughts would be appreciated.

It seems from your post the data is hogging the CPU which is common and the reason optimizing is necessary.

I don't know if I am following correctly in your "EDIT".

To lower the amount of data for all opaque layers it is advisable to have them on separate layers and have only the layer you want visible ON and the rest OFF.
"... I was importing each WMS layer as a separate worldwind layer ..."
It seems this would be the best way and turn them all OFF except the layer you want visible.

Do you have any idea of how much CPU is being take up by your downloading??

It may be a good idea to get your downloading done and run offline to get the excessive data display glitch taken care of.

[jas511]

Thanks for your reply. What I meant by my edit was if I had 5 layers that overlapped the same bounds on in my client as separate layers, then each of the 5 were being rendered, even though only the top one would actually be seen. When all 5 were requested to the WMS as one layer, it looks like the WMS took care of only returning the one that would actually be visible.

This might belong in another thread, but what I did find though is that when I'm displaying CADRG imagery (RPF, CIB, etc), it doesn't seem to matter what the scale of imagery is, only one of the layers shows. For example, I have one layer that is 1:250000 and one that is 1:100000, but it doesn't matter what the map scale is, the same layer always shows.
I know that I can use the min/map scale hint on the WMS layers, but it seems like that is not always set. Is there a way the server can specify the correct scale of the imagery, so it is only served at that specific scale (or so the client only requests it at that scale)?

[nlneilson]

Originally Posted by jas511

When all 5 were requested to the WMS as one layer, it looks like the WMS took care of only returning the one that would actually be visible.

I am not familiar with how that is done.
I don't use WMS to serve my data because pre-tiled images are mush faster.
The only WMS request I am familiar with is done with the layers that are in the SDK and have not made any changes to that IIRC.

[jas511]

Alright, thanks for the information. In our environment, we have a WMS server that has all of our map data (and we cannot change that format). I'll continue looking for a solution to the main issue, which is that many layers can be slow and we need a way to optimize the ones that are displayed so we're not requesting images we don't need (if they are covered by other images for example).

PS - I'm not sure if the WMS is necessary picking the correct layer (in terms of its scale value) to display, but it is just displaying one of them and not making requests on all of them as far as I can tell.

[nlneilson]

This is what can be used to see what is being requested.
I don't recall if or how it works with WMS.
layers/BasicTiledImageLayer.java
just below url =

     url = tile.getResourceURL();
     System.out.println("#568\n" + url);

[jas511]

Thanks. I did some more debugging of the performance of the WMS and the problem seemed to be my cache size. When I made the cache too small, there were way too many requests being made, which caused the application to slow down. Though I'm still doing some more debugging...I appreciate your help.

[heidtmare]

Due to transparencies and what not its not really possible for wwj to put in a blanket rule that says "only render the top most layer for this zoom level".

How you would normally do that for imagery, as you hinted to earlier, is to add those layers to a layerset in your wms and then request that layerset instead of each individual layer. Then it would be the job of the wms to create a composite representation of those layers.
You could set up a wwj layer to composite them in the client but you would have to manage that yourself and have a ruleset telling it the order to do so.

[nlneilson]

Originally Posted by jas511

... min/max scale hint (if it exists) on the client side and requesting each layer individually and not the whole layer set...thoughts?

The min/max is for the level of the layer.

"... requesting each LEVEL individually and not the whole layer set"
Is this what you meant?

"When I made the cache too small, ..."
Why???
I don't think the cache size has anything to do with the amount of requests other than eliminate the requests when the cache is "full".

It's good you are debugging to find where your slow down is at.
Writing code that 'WORKS' is relatively fast and easy.
Error handling and optimizing takes much more time and work.
You learn more doing that also.

Keep at it, you will get there.