[ka-Map-users] <kein Betreff>

[Jacob Delfos]

Paul,

The version handling is something that must be in the url, maybe as a number behind the layername, with a rare delimeter (e.g. drainage~03). This avoids the browser caching issue. 

When the application initialises, something must determine whether a new version is to be used. Maybe this could be specified in the mapfile somewhere, on an individual layer basis. We actually already use a "lastupdate" metadata attribute, for other purposes. This could be read in init.php, line 72 somewhere. If the version number is to be increased, it can read the previous version number from a version text file (once only on initialisation) or also from the metadata, delete the outdated tiles, and add the new version number to the layername in the url's.

I may have a look at implementing this, if I can find time.....

regards,

Jacob


-----Original Message-----
From: ka-map-users-bounces at lists.maptools.org [mailto:ka-map-users-bounces at lists.maptools.org] On Behalf Of Paul Spencer
Sent: 6 July 2005 08:48
To: maik at maitro.de
Cc: ka-map-users at lists.maptools.org
Subject: Re: [ka-Map-users] <kein Betreff>

Hi,

there is nothing right now unfortunately.  We discussed several ways of 
handling this, the most likely being to include a version number for a 
map in the configuration file and to use this version number somehow in 
the tile caching system to indicate that a tile is expired and to delete it.

The reason you probably don't have permission to delete the cached files 
is that they are created by the apache (or iis) user account.  By 
including the capability to regenerate tiles based on a map version, the 
apache process could take care of deleting cached tiles and would have 
the necessary permissions to do so.  tile.php already contains the 
necessary code to force tile regeneration, so it would just be a matter 
of adding the version check.  Ideally, a version file would get written 
into the meta folder for each metatile containing the version number. 
This would add overhead to tile.php and cause the whole application to 
slow down because every tile access would have additional file i/o 
tests.  Perhaps there is a smarter way?

Alternately, a new script could be written to scan the cache directory 
and cause all existing tiles to be regenerated.  This would help with 
the performance issue by eliminating unnecessary tests in the 
performance critical code, and optimize tile generation to only those 
tiles that have been previously generated (and therefore most likely to 
be needed)

This being said, I have no plans to add this capability at this time due 
to lack of resources.  If someone wants to tackle this issue, I would be 
willing to incorporate the results into the cvs version though :)

Cheers

Paul

maik at maitro.de wrote:
> Hello,
> 
> we have a little problem with ka-Map!
> ka-Map creates for every scale an own folder on the server. When we change our mapfile ka-Map doesn`t create a new map. It takes the cashed map from the created folder. The problem is, that we use a dynamic mapfile an we have no rights to delete the folders every time. Is there a solution to solve this problem?
> 
> Thanks a lot and greetings from Karlsruhe, Germany
> 
> Hans-Peter Hebel &
> Maik Trömel
> 
> _______________________________________________
> ka-Map-users mailing list
> ka-Map-users at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/ka-map-users
> 

-- 
+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+
_______________________________________________
ka-Map-users mailing list
ka-Map-users at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/ka-map-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/ka-map-users/attachments/20050706/df8fde67/attachment.html