Open AnyOldName3 opened 1 month ago
Thanks for your thoughts. Two comments..
Caching, whether on disk, http, or an L2 memory cache, is something we decided not to tackle up front. Disk caching will likely be a series of hooks so the user can customize the process.
For re-use, osgEarth (Rocky's precursor) had the idea of using anything already loaded into the scene as source data - but only for elevation. The hope was to extend this idea in Rocky for all data. So if true source data is not found or doesn't exist, check the existing scene for data it can use in its place. In-memory tiles are tracked in the TerrainTilePager
so this may be the logical place to implement an L2-cache-style interface once we have one.
I've got some stuff locally that should lead to Bing and Azure maps working (I'd hoped just to do one, but one's deprecated and the other doesn't do satellite and aerial photography on the free tier and doesn't have any elevation support at all). However, it's chewing through API calls, which is bad on its own, but also caused this symptom when doing more than a little panning around as there's a rate limit.
Similarly to the problem I fixed with #41, you can get gaps in the map that are shown as white. The approach taken in #41 of falling back to a lower LOD level can still fail if there's intermittent unavailability, e.g. due to network issues or because you're calling a rate-limited API - if the lower-quality LOD has fallen out of the cache, then a new network request will need to happen, which could fail. If it does, then you'll still end up with partial tiles, just like before #41 was merged.
Ideally, apps wouldn't need to deal with dodgy connections or exhaust rate limits (as discussed in the other MR, the latter could be lessened by increasing the default size of the in-memory HTTP cache, adding a second-level disk cache, or caching the generated
GeoImage
s), but things won't always run under perfect conditions, so it's worth handling them gracefully.One thought I've had is that if a tile knew it only had partial coverage, but another fully-covered tile was already present, the other tile could optionally be used instead even if the LOD level was less appropriate. However, if there's already a fully-covered tile for the same region, it must have had data, so in principle, that data could be used again, either by grabbing the potentially-composite data from the existing tile, or by ensuring the intermediate data for all current tiles is kept around.