1.4.1 issues

[Ammianus]

Thanks 5of0. I think your plan is good, if you want I can try to test out your change as well.

Does anyone else have any more information on Issues #1 and #2? Maybe they were fixed at some point since they were from early in this thread.

For now I might tackle another simple one that I came across, #4, seems like we should be able to clean that up.

[Ammianus]

Originally Posted by 5of0

And has anyone looked at the camera.cs? I read through the IRC - it looks like some raytracing/3D geometry issues?

I added this as a new issue. Does anyone have any more details or know if it was fixed?

Edit:
Probably not, last time it was modified in SVN was 3/26/2008

[Ammianus]

I added two additional Issues

#7 - enhancement discussed before for having the log file rollover at some size rather than just keep appending
http://worldwindcentral.com/wiki/1_4...d.log_rollover

#8 - a user recently reported in the Bug Reports forum that the Mars tiles do not work (server returns 401 error)
http://worldwindcentral.com/wiki/1_4...es_do_not_load

[5of0]

Originally Posted by nlneilson

...
The checking for 0001-0009 or 1_9 should only be necessary if you copy from the WWJ cache to the WW.net cache. If you just download from the WWJ server WW.net adds the leading "00"s so nothing has to be changed other than changing the server URL you are requesting the images from.
Has anyone tried this??

Bull: "it almost sounds too simple."

The only glitch I can see is if the .dds format used by WWJ is different from that used by WW.net. I don't currently have WW.net installed to try it.

I've got a fix in SVN, and it was actually pretty simple - it took a few gos to come up with something that didn't cause problems, but I've updated the wiki with what I've got set up.

From the conversation I read, the main idea was to allow WW.NET to share a cache with WWJ. The idea was brought up to just switch WW.NET to a WWJ-style cache, with backwards compatibility. This sounded like the best solution to me, and I was able to implement it pretty simply, I think.
The changes in my branch change WW.NET to do just that:

• First check for the tile, assuming a WWJ-style cache
• If it's not found in a WWJ cache, check assuming a WW.NET-style cache
• If it's not found in either of those, it's not cached, cache it WWJ-style

I tested it out, and when unleashed on a old-style cache, it will create what appear to be duplicate directories (0064 and 64), but there are in reality no duplicate files - newly cached tiles go in 64, and it still reads the older cached files from 0064.

I certainly wasn't trying to deal with anything serverside, and I don't think that was ever the issue - WW should be able to just point to a WWJ server and use it. I'm running XP (I also have Vista), and WWJ stores the cache in
D:\Documents and Settings\All Users\Application Data\WorldWindData\Earth
It is not directly compatible with the WW.NET cache because some of the layer names are different (e.g. "BMNGWMS" vs "BMNG", "NASA LandSat I3 WMS" vs "I-Cubed ESAT World Landsat7 Mosaic"). I've done some testing with WW.NET in offline mode, and the files themselves are compatible - WW.NET can read the WWJ dds tiles without any issues, and if the layer names are the same, my branch can now read straight out of a WWJ cache.

[5of0]

Originally Posted by Ammianus

Thanks 5of0. I think your plan is good, if you want I can try to test out your change as well.

Does anyone else have any more information on Issues #1 and #2? Maybe they were fixed at some point since they were from early in this thread.

For now I might tackle another simple one that I came across, #4, seems like we should be able to clean that up.

Sounds good. You could test my branch, I don't know what other testing than I've already done, but browse around, make sure stuff is loading from cache, I suppose.

I only have the vaguest ideas as to #1. #2, I've read through the thread, and it sounds like a workaround may be in place? I'm not sure - I'd have to do some testing. James_In_Utah would know more, if he doesn't show up here soon I'll pm him to get his input.

[Ammianus]

I combed through all of the threads in the first page of the Bug Reports forum. I either posted questions or logged them as an Issue if it looked to be still open. Some may be minor but we should track everything somewhere so that knowledge doesn't get lost. I posted in a lot of threads, but I think we should have gleaned most of the issues that were posted there and not tracked in our list.

I added 3 new Issues, 9, 10, 11
# 2.9 WW doesn't install correctly for multi-user env
# 2.10 NltTerrainAccessor.cs BUG
# 2.11 DirectX Screen Lock Issue


Maybe this is getting to be a more complete list now?

[Ammianus]

Originally Posted by 5of0

Sounds good. You could test my branch, I don't know what other testing than I've already done, but browse around, make sure stuff is loading from cache, I suppose.

I only have the vaguest ideas as to #1. #2, I've read through the thread, and it sounds like a workaround may be in place? I'm not sure - I'd have to do some testing. James_In_Utah would know more, if he doesn't show up here soon I'll pm him to get his input.

It also may be useful for someone with WWJ to try to use the cache created when you download to the cache with your code, and vice versa...ie point your version to a WWJ cache.

I don't have WWJ so it may be difficult to test that, but I can test just the general behavior.

[nlneilson]

Originally Posted by 5of0

• First check for the tile, assuming a WWJ-style cache
• If it's not found in a WWJ cache, check assuming a WW.NET-style cache
• If it's not found in either of those, it's not cached, cache it WWJ-style

I tested it out, and when unleashed on a old-style cache, it will create what appear to be duplicate directories (0064 and 64), but there are in reality no duplicate files - newly cached tiles go in 64, and it still reads the older cached files from 0064.

I certainly wasn't trying to deal with anything serverside, and I don't think that was ever the issue - WW should be able to just point to a WWJ server and use it.

It's good you got that working.

Looking at my earlier post "other than changing the server URL you are requesting the images from" should have been: "changing the request to the WWJ server URL".

In WW.net I had my cache under C:\NWW\
In WWJ I have it so the directory the app is run from there is \WWData where the cache is. That way the app can be run from a usb flash drive, sd card, external drive, DVD (without saving new data), or whatever storage media.
So with Bull's idea: "better to have it default to WWJ format" then the WW.net and WWJ would be compatible other than the data structure, that is the directory/directory names like: (e.g. "BMNGWMS" vs "BMNG"). I just have mine "Marble".

For someone to change their existing "legacy" cache to "WWJ format" would just need to have the leading "00"s removed. The Python script in post #55 would do this at a rate of about 5,000 files per minute. I will be writing this again in java so the basic java jvm that comes with Windows can run it, Python would not have to be installed. This will also correct for the (bug ?) in the Python script that removes all the leading "00"s, if the directory or file just has "0" it should be left. For tiles near -90 latitude and -180 longitude this is necessary, for the FAA data for the U.S. this was not required so it was not a bug for that.

The java code could also change the cache packs on the WW.net server.
Java should be as fast as Python, maybe faster, so converting the cache packs would not take much time (5,000 files/min). This would match the "WWJ format". This just renames the files, no extra space is required to do the renaming.

[5of0]

nlneilson:
Yes, that makes sense. A script to convert the cache would be good, although not terribly necessary - it would speed things up slightly (since it doesn't have to do any checking for a WWJ cache first), but other than that my branch will read the .NET cache just fine. I was pondering adding a notification if the user was using an old cache - maybe just a message up in the corner? - that told them they should convert it, and maybe just writing a routine to do so in C#, since it's not a terribly complicated or involved process.

So do we like the idea of defaulting to WWJ format? I think that's my main question.

[nlneilson]

My vote, which doesn't count for anything, would be defaulting to the WWJ format.
I don't understand the reason for the leading "00"s in the first place.

There are several things in WW.net that is not in WWJ, one in particular is the ability to remove the black borders from images that are in the .jpg or .dds format.
If I switch back to WW.net for some apps it would be good to be able to use the same cache without modifying the WW.net code other than just location and layer names.