Hi all, As I stated in an earlier thread [1], I've changed some part of the OL's code to handle ka-Map pre-cached layers, similar to the TileCache class. With a cached layer, the ka-Map tiles will be loaded considerably faster.
[1] http://www.nabble.com/Fix-for-issue--327%3A-ka-Map-overlays-tc16620073.html A long time ago [2], Jochen Grefe has posted here about a similar aproach: [2] http://www.nabble.com/Using-kamaps-direct-cache-access-tc11581326.html#a11581326 The solution provided by him works, but it has some small problems I'll decribe here. First, I thought it was more natural to make a separate KaMapCache class, similar to TileCache class. One problem is that when the layer's group name (the "g" parameter in KaMap class) has white spaces, it doesn't get the proper url. Another problem is related to the directory structure described above. I've also changed the string concatenation to the Array.splice method, as used in " TileCache" class. So, I wrote a new KaMapCache class, that overextends a KaMap class. This class overrides the "getURL" to generate the full URL of each tile, without calling the server. To create a a new KaMapCache layer, you must indicate also the "i" parameter ( that will be used to calculate the file extension), and another special parameter, object names "metaTileSize", with "h" (height) and "w" properties, as suggested by Jochen. Here's a simple example. Is the same example of my earlier thread [1], but using a KaMapCache layer. // Create a new kaMapCache layer. You must allways inform the "i" parameter // for a KaMapCache layer. var kamap_base = new OpenLayers.Layer.KaMapCache( "Satellite", "http://www.example.org/web/acessible/cache";, {g: "satellite", map: "world", i: 'png24', metaTileSize: {w: 5, h: 5} } ); // Create an kaMapCache overlay layer (using "isBaseLayer: false"). Forces // the output to be a "gif", using the "i" parameter. var kamap_overlay = new OpenLayers.Layer.KaMapCache( "Streets", "http://www.example.org/web/acessible/cache";, {g: "streets", map: "world", i: "gif", metaTileSize: {w: 5, h: 5} }, {isBaseLayer: false} ); I don't have privileges to open a new ticket so I'll put the files as an atachment of this message. As it was stated in my earlier thread, I've splitted the "tile.php" in two files: "tile.php", and "config.php", so this configuration file can be used also with a "precache.php" file. Like the TileCache layers, you must pre-generate all tiles before using it. This is done with the "precache.php" file. This file is basically the "precache2.php" file that comes with ka-Map distribution, with almost none changes. Was removed a piece of code that was trying to remotely create the cache directory. This was a useless step, once "precache.php" is a command line tool that will generate that folder locally. The other change was related to the directory structure of the cache. There was a slighly difference between the directory generated by "precache2.php", and the one generated by "tile.php", the code already in use at OL. precache2.php: var/cache/World/50000/Group_Name/def/t-440320/l20480 tile.php: var/cache/World/50000/Group_Name/def/t-440320l20480 I don't know why this was changed, and I would like to hear some opinions. What's the best structure? Or both has the same performance? I mean, I suppose the second one would generate more folders inside the "def" folder for smaller scales like the street level scale. But since I'm not a hardware guru, I'm asking here in the list. This can somehow affect the hard disk performance or something related? The files used are: * "precache.php", renamed as "precache.php.txt" * "config.php", the same used in the my earlier's post. I'll not upload this again to avoid duplicities in the tracker. * "KaMapCache.js", the new class. I hope this patch helps. my best regards, Pedro Simonetti. http://www.nabble.com/file/p16623387/KaMapCache.js KaMapCache.js http://www.nabble.com/file/p16623387/precache.php.txt precache.php.txt -- View this message in context: http://www.nabble.com/Patch-for-a-ka-Map-cached-layer-tp16623387p16623387.html Sent from the OpenLayers Dev mailing list archive at Nabble.com. _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
