On Sun, Oct 30, 2011 at 3:20 PM, Martin Spott <[email protected]> wrote: > Alex Perry wrote: >> [...] What is >> preventing us from converting the whole Atlas project to WMS, and >> dropping the old nomenclature? > > I'm just guessing: Backwards compatibility with those users who'd like > to use Atlas without being required to have a functional internet > uplink ? The FSweekend show next month is typically one of those cases > where this schema applies.
I don't know what you're getting at. If Atlas knows how to get map tiles from a URL family in addition to the usual disk file name family, that doesn't affect offline use. Having said that, I wouldn't object to Atlas becoming a URL-only utility providing it still knows about file:// to avoid depending on a local webserver! If you're suggesting that the revised Map couldn't write to files any more, I think you're assuming a larger change to it than I had in mind. It might be nice to have a third utility AtlasTileServer which does provide a caching WMS webserver for Atlas and knows how to invoke Map to draw missing tiles at need. It could (1) keep a local Map instance busy between interactive requests, (2) recurse to a remote AtlasTileServer with its correspondingly better cache and higher throughput, and (3) kick TerraSync into fetching any missing Terrain tiles first. Ideally, Atlas and AtlasTileServer are happy keeping the GET request alive (and idle) while a tile is generated on the fly, and Atlas knows how to add the late-arriving tile into the framebuffer once it actually turns up. ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
