[ka-Map-dev] future of ka-Map

Paul Spencer pspencer at dmsolutions.ca
Wed May 7 20:17:43 EDT 2008


:)

On 7-May-08, at 7:59 PM, Lorenzo Becchi wrote:
> Paul, you're comments arrive just in time.
> I've planned to spend my participation at the OSGeo Hacking Event  
> [1] over ka-Map code and OL integration.
>
>
> Paul Spencer wrote:
>
>> * a php-based configuration file similar to the existing config.php  
>> for specifying various options and identifying maps and tile caches
>
> if I'll be alone at the the Hacking Event I will not touch config.php
>
>> * a php-based tile engine similar to the existing tile.php for  
>> dynamically serving tiles from a cache and rendering them as  
>> necessary
>
> what changes would you like to do to tile.php?

nothing substantial I guess, but there was some discussion around  
transparent tiles that got me thinking the code could be better  
organised perhaps.  Also it may be nice to make the directory depth  
configurable (we've added an extra level of meta directories to  
accommodate larger tile sets.

Also some work on cache management scripts would be nice:

* pre-generate specific areas of the cache at specific scales
* re-generate the cache based on tiles that are already in the cache  
when there is new data
* clean the cache to keep its size under control by removing least  
recently accessed tiles

>
>
>> * a php-based tool that returns javascript or json to the client  
>> with an appropriately configured layer(s) (all the settings for the  
>> layer are taken from the configuration of the cache and other  
>> settings)
>
>
> I was thinking to use OWS Context with an extension for the ka-Map  
> layer. Another idea is the OLON object but has never come to be  
> included in OL trunk. Both XML and JSON output can be easily offered.

I like OLON :) but I am not sure what the best option would be.  I'd  
like it to be something that you can point at a ka-Map php script of  
some sort and the layers just magically get added to a map.

>
>
>> * a client-side way of using the javascript or json from the server- 
>> side - could be as simple as including a script tag after  
>> OpenLayers.js or an entirely new Control or add-in for OpenLayers.
>
> I still don't know what's the direction I want to take but I've  
> thought to both solution.
> The Control could help at least to manage the multiple-maps  
> configuration. Then the Legend should be adapted in a separate  
> Control to let the people choose which layerSwitcher to use. I've  
> already wrote a new legend control for OL and it should not take too  
> much time to clean it and adapt it to ka-map.
> I was even thinking to offer the integration in ka-Explorer,  
> depending on the time I'll have available.
> If we'll refine the architectural part together before the Hacking  
> Event I'll have more time to code.
>
>> This would focus efforts on improving tile.php rendering, tile  
>> management tools such as precache.php, and cleaning up that code  
>> while leaving the javascript stuff to OpenLayers.
>
> I do agree.
>
>
> ciao
> Lorenzo
>
> [1] http://wiki.osgeo.org/wiki/OSGeo_Hacking_event


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/



More information about the ka-Map-dev mailing list