CRS:84 vs EPSG:4326 and SCALE-HINT

Hi,

I have found other possible problem, (other of my posts http://forum.worldwindcentral.com/sh...ad.php?t=24264)

I have instaled your WWJ WMS server, and I have tested it using other client different as WWJ or WW .NET, my client is (ESRI software) and I have could see that there are a possible CRS ->CRS:84/EPSG parameter problems.

WMS 1.3.0 the co-ordinate axis order in reversed for CRS:84 and EPSG:4326. So, when requesting images in CRS:84 use the coordiate axis order of (long, lat) and when using EPSG:4326 use the (lat, long) order. And WW WMS server is invariant to change these. always use it as CRS:84. you can see that .xml files are using EPSG:4326 but WWJ WMS are using CRS:84 interpretation. it is a possible client-server problem.

http://viswaug.wordpress.com/2009/03...ms-130-images/

Other question: is scale-hint parameter to WMS auto-discovery configuration possible?

Best Regards
Raul

[garakl]

Thank you for catching this problem with CSR:84 and EPSG:4326.
I will address it as soon as possible.

Regarding the ScaleHint for auto-discovered layers....
I will add calculation of ScaleHint based on layer XML file.
We should be able to calculate ScaleHint min and max values based on total number of layers, number of empty layers, and tile size.
Good catch! Thank you!

hi,

what do you mean with empty layers?. and... by the way, what is the use of (numEmpty) parameter from (numlevels) xml layer config?

"<NumLevels count="10" NumEmpty="0"/>

Could you post a manual of all possible parameters in layer config xml-tag-parameters and the other xml config files?

regards
Raul

[garakl]

Let's take a look a typical model XML configuration file, for example landsati3 XML configuration file:

<NumLevels count="10" numEmpty="4"/>
<TileOrigin>
    <LatLon units="degrees" latitude="-90" longitude="-180"/>
</TileOrigin>
<LevelZeroTileDelta>
    <LatLon units="degrees" latitude="36" longitude="36"/>
</LevelZeroTileDelta>
<TileSize>
    <Dimension width="512" height="512"/>
</TileSize>
<Sector>
    <SouthWest>
        <LatLon units="degrees" latitude="-90" longitude="-180"/>
    </SouthWest>
    <NorthEast>
        <LatLon units="degrees" latitude="90" longitude="180"/>
    </NorthEast>
</Sector>

Now, remember that each LandSAT tile covers 2x2 degrees area and 14,410 x 14,410 pixels (about 700MB average single landsat tile).

<LevelZeroTileDelta> defines a size of the first ( 0 level ) tile size: 36 x 36 degrees, 512x512 pixels (defined by <TileSize>).

WWJ client uses <LevelZeroTileDelta> to calculate a size of tiles to send very first requests for imagery to a WMS server (when you first see a globe after the startup).
In ths case, it will be four requests for landsat imagery each 36x36 degrees (512x512 pixels).
Even one such request will require from WMS server to open 324 tiles ( 324 = 18 x 18 because each tile is 2x2 degrees), each tile is ~ 700MB and build a single tile of 36x36 degrees (512x512 pixels). WMS will never be able to do this within reasonable time of couple seconds (9 seconds is a default timeout on WWJ).

So, by specifying numEmpty="4" we are instructing WWJ to skip first four levels (0,1,2, and 3) and do not query WMS server until user zooms in to the zoom level 4.


Level 0, Tile delta 36", 512 pixels, resolution 0.0703125 (=36/512)
Level 1, Tile delta 18", 512 pixels, resolution 0.0.03515625 (=18/512)
Level 2, Tile delta 9", 512 pixels, resolution 0.017578125 (=9/512)
Level 3, Tile delta 4.5", 512 pixels, resolution 0.08789063
Level 4, Tile delta 2.25", 512 pixels, resolution 0.04394531
Level 5, Tile delta 1.125", 512 pixels, resolution 0.02197266
Level 6, Tile delta 0.562", 512 pixels, resolution 0.001098633
Level 7, Tile delta 0.28125", 512 pixels, resolution 0.000549316
Level 8, Tile delta 0.140625", 512 pixels, resolution 0.000274658
Level 9, Tile delta 0.0703125", 512 pixels, resolution 0.000137329

So, when WWJ zooms to the zoom level 4 (2.25" tile delta) - in this case WMS server should open 4 tiles in worst case and WMS server could handle such request performance wise.

Apparently, this will give me a chance to calculate that minScaleHint is 0.04394531 (resolution for level 4), and the maxScaleHint is 0.000137329 (resolution of the max layer).
Original LandSAT tile maximum resolution is 0.000138888888889 (14410 height in pixels / 2" latitude delta).

Now, WMS spec is really confusing about the ScaleHint definition. So we just use what makes sense.

hi, thanks for your explications!

but I don't understand some detail...

My icubed repository level 0 (download from here) has about 50 tiles (10tiles*5tiles-> 36ºx36º) in level 0, If WMS get a request of all world (-180,90,180,90)-> WMS has to do a mosaic from about 50 tiles (level 0), not 324... is it?. then, even it... yes it is very time-expensive to WMS server.

Other possibility is redo the piramid mosaic [0,9], to [0,11] and get other tiles to all world in a single tile 512x512 or minus tiles. ( I think that I can do it ) (If you want, I can send you the necesary tiles that extent the piramid and test it)

but If I have understood fine, numEmpty is only interpreted by WWJ not by standard WMS client then we need wait to SCALEHINT feature to do the same with standard WMS client.

But.... what happens if WMS-server hasn't some of level-tiles (ocean zone) to make the mosaic-response?
Does WMS search the tiles from other levels [0,9]... to do the mosaic? or fullfill the mosaic-part with black tiles? or what do you think, is a good idea fullfill the piramid folder-files with black tiles to avoid this wms-search?, if it is true... is there any kind of solution-parameter (LookForLowlevelTiles="false") to avoid WMS server look for other level tiles in low level folders, and fill with black tiles?

by the way the levels icubed 6,7,8 and 9, (or perhaps only level 9 repository) (I can build the other piramid levels using only this level) where is it?, is it possible to download form any site?.

Regards and thanks again , Sorry for my english.
Raul

[garakl]

WWJ will issue requests only for the visual side of the globe, so there will be less requests, and only for tiles that are not in the cache.
And in most cases WMS server receives requests from WWJ cleint that exactly fits tile size and geographical positions. In this case server simply loads and streams tiles to the WWJ client, therefore it is not too much work for server.

When WMS server cannot find tile it searches tile pyramid in both directions (first down, to higher resolution tiles and then up to lower resolution tiles) to fill-out voids. Today we do not have a way to disable such search or limit only to one directions (up or down). Let me bring this question to the WWJ team.

LandSAT imagery is about 1TB, layers 6,7,8,9 are pretty big even when archived, about 800GB. People have problems to download much smaller sets.
We need to find a reliable hosting solution or use peer-to-peer network to distribute large imagery and elevation sets.

then....I think that the problem in my old post http://forum.worldwindcentral.com/sh...ad.php?t=24264 is these. I have these level distributions

----------0
--------1111
-------222222
------33333333
-----444444444
----55555555555
---6666666666666
-----7----77---7
-----8----88---8
-----9----99---9

Only a subset of level 7 exist, then server are looking for other tiles up or down. and spend very much time... and perhaps a hang problem. What do you think?

If I refill with black tiles (levels 7,8,9) I will spend very much hard disk space. then I think that perhaps a configuration flag(true, false) to remove this search algorithm in WMS server, maybe a good idea, WMS server refill fill-out voids with black tiles instead of search algortihm.

Regards
Raul

[jenvy129]

Hi，Raul
I think i have confronted the same problem with u
I don't know how to deal with the blank tiles when zoom to a high resolution
Do you have some experiment about this problem?

Best regards

hi,

The only solution (I think) for this problem is downsampling All layers to the high resolution
--> big hard disk space.

Other solutions depend of the WMS client:

1) if you are using WWJ as client you can do it creating sectors in xml client file, then client cast queries to Nasa WMS server only with this sector configuration and the high resolution void tiles never will be asked, although the server can response these queries.

2) if you use other client WMS compatible you will have a problem when the client ask this void high resolution tiles, and the server spend very much time recreating this void tiles using the existing low-resolution tiles..... (no solution, only recreating void tiles to avoid it).

I don't understand yet, why server need so time to response these queries, I think that the loop code to resolve the void tiles maybe improved. Server only need search tiles in hard disk and if one tile doesn't exist, then look for it in high level. maybe that the problem is in Hard disk access because when you use very much tiles and levels, hard disk is slow to search in the tree.

Regards
Raul

[jenvy129]

Originally Posted by raul

hi,

The only solution (I think) for this problem is downsampling All layers to the high resolution
--> big hard disk space.

Other solutions depend of the WMS client:

1) if you are using WWJ as client you can do it creating sectors in xml client file, then client cast queries to Nasa WMS server only with this sector configuration and the high resolution void tiles never will be asked, although the server can response these queries.

2) if you use other client WMS compatible you will have a problem when the client ask this void high resolution tiles, and the server spend very much time recreating this void tiles using the existing low-resolution tiles..... (no solution, only recreating void tiles to avoid it).

I don't understand yet, why server need so time to response these queries, I think that the loop code to resolve the void tiles maybe improved. Server only need search tiles in hard disk and if one tile doesn't exist, then look for it in high level. maybe that the problem is in Hard disk access because when you use very much tiles and levels, hard disk is slow to search in the tree.

Regards
Raul

It helps , thank you very much