Running WorldWind without a net connection or with local storage...
This seems to be a common question and need. I'm going to jot down my notes as I go along. I don't have a solution yet (not for complexity, just time).
First, if a net connection is "kind of" there, but not really (e.g. a net connection in need of repair, or a bad url), the underlying .NET infrastructure is ruthlessly persistent at trying to make a broken connection work -- gladly running off for up to 100 seconds before failing. Multiply this by the 25 or so tiles that are trying to be shown at any given moment, and your Update thread will be spinning for hours (well... 41:40 minutes to be exact). You will be left with spin lat/lon lines over an empty earth for at least 4-5 minutes before it really gives up.
Quick simple hack it to adjust the request.Timeout to be ~3-4 seconds in WorldWind.Net.WebDownload's Download() routine. This is still hacky, as it waits around for still 10's of seconds, while potentially killing downloads for those with slow net connections.
One real solution is to maintain some knowledge of the net connection across all of the quad tile requests, and ideally allocate one thread for testing connectivity to each potential datasource on the net. This will not tie up the main update thread with connection requests, as a tile can gladly check the state of the connectivity before doing anything.
Caveat/Todo: I have not yet looked closely at the GeoSpatialDownloadRequest DownloadRequest inside a Quadtile to see if it is shared by all tiles in a QTS (assuming a QTS will have a common server). If this is the case, then perhaps this code really does the universal connection management or just needs augmenting (e.g. to force it off the main update thread). From all accounts, the download queues held in QuadTileArgs should do all this, haven't had time yet to figure out why not.
It would also be nice to have the imageAccessor be smart about accessing data for "permanent" directory data -- a discussion in a previous post. The quadtiles are set up to fail frequently, instead of flagging incompletes. See http://issues.worldwind.arc.nasa.gov/browse/WW-478 as an example.
First, if a net connection is "kind of" there, but not really (e.g. a net connection in need of repair, or a bad url), the underlying .NET infrastructure is ruthlessly persistent at trying to make a broken connection work -- gladly running off for up to 100 seconds before failing. Multiply this by the 25 or so tiles that are trying to be shown at any given moment, and your Update thread will be spinning for hours (well... 41:40 minutes to be exact). You will be left with spin lat/lon lines over an empty earth for at least 4-5 minutes before it really gives up.
Quick simple hack it to adjust the request.Timeout to be ~3-4 seconds in WorldWind.Net.WebDownload's Download() routine. This is still hacky, as it waits around for still 10's of seconds, while potentially killing downloads for those with slow net connections.
One real solution is to maintain some knowledge of the net connection across all of the quad tile requests, and ideally allocate one thread for testing connectivity to each potential datasource on the net. This will not tie up the main update thread with connection requests, as a tile can gladly check the state of the connectivity before doing anything.
Caveat/Todo: I have not yet looked closely at the GeoSpatialDownloadRequest DownloadRequest inside a Quadtile to see if it is shared by all tiles in a QTS (assuming a QTS will have a common server). If this is the case, then perhaps this code really does the universal connection management or just needs augmenting (e.g. to force it off the main update thread). From all accounts, the download queues held in QuadTileArgs should do all this, haven't had time yet to figure out why not.
It would also be nice to have the imageAccessor be smart about accessing data for "permanent" directory data -- a discussion in a previous post. The quadtiles are set up to fail frequently, instead of flagging incompletes. See http://issues.worldwind.arc.nasa.gov/browse/WW-478 as an example.
posted by Geoff at 10:16 PM
0 Comments:
Post a Comment
<< Home