[ka-Map-users] Some thoughts/questions about tile.php
Morgan Pyne
morgan.pyne at gmail.com
Thu Jul 13 18:07:35 EDT 2006
Hi all,
First post to this list, so thanks to all involved for a great piece
of software that's evolving in leaps and bounds.
I too had been pondering the tile.php script and and been wondering
about things which may speed up processing.
Once of the things that I noticed is that the metatile is created,
written out to disk, and then read in again to be sliced up into the
individual tiles. I was wondering: could we bypass writing the
metatile to disk altogether?
Is it possible to simply access the GD buffer for the metatile in
memory and operate directly on this while generating the tiles? A
quick scan of the mapscript docs didn't show me an obvious way to do
this (would we need a method on the imgObj class to return a GD
handle useable directly by PHP's GD functions?) but perhaps some of
you more experienced mapscripters here might have some insight into
this.
Apart from metatile creation, it could be useful to access the imgObj
as a GD handle for post-processing of the images within PHP using the
standard GD functions.
Cheers,
Morgan
On 14/07/2006, at 8:20 AM, Stephen Woodbridge wrote:
> Tim,
>
> Thanks, for the link. I knew this was possible but since I don't
> have all the times generated I'm stuck using auto for the time being.
>
> Did anyone get mod_rewrite or a 404 handler to redirect a cache hit
> to tile.php if the file did not exist. This does not solve the
> problem of a partially written file in the cache, should whould
> require changes like I outlined below.
>
> -SteveW
>
> Tim Schaub wrote:
>> Just a reminder that there is a "tile_source" "cache" option for
>> layer
>> metadata. If you set this in your mapfile, the call to tile.php is
>> avoided completely (tile source is determined on the client
>> side). This
>> does speed things up a bit. I agree that it would be good to
>> optimize
>> tile.php - anything that you could do would be somewhere between the
>> speed of the cache option and the current tile.php speed.
>> Terse docs:
>> http://ka-map.ominiverdi.org/wiki/index.php/
>> Mapfile_Metadata_Configurati
>> on#Mapfile_LAYER_Section
>> Tim
>> -----Original Message-----
>> From: ka-map-users-bounces at lists.maptools.org
>> [mailto:ka-map-users-bounces at lists.maptools.org] On Behalf Of Stephen
>> Woodbridge
>> Sent: Thursday, July 13, 2006 1:33 PM
>> To: ka-map-users at lists.maptools.org ML
>> Subject: [ka-Map-users] Some thoughts/questions about tile.php
>> Hello Paul, et al,
>> I have been looking at tile.php and had some thoughts/questions about
>> how it works and how it might be made faster.
>> 1) currently the first thing it does is open lock file on the
>> metatile
>> 2) if the file exist, it gets a shared lock
>> 3) serves the image
>> 4) removes the lock
>> It seems like it would be faster to avoid this locking, ie: if the
>> file
>> exists just serve it. If image creation were written to a tmp file
>> name
>> and renamed to the actual tile name when the write was done and
>> the file
>> closed, this would be atomic and should avoid the problem that the
>> code
>> above is dealing with.
>> Since the whole concept of tiled mapping is to generate once and
>> serve
>> many times it seems this would be a valuable performance
>> improvement by
>> avoiding 3 file operations per tile requested.
>> Second issue is that directory structure is pretty flat as Paul has
>> mentioned in the past. I was thinking that a very trivial change
>> would
>> be to split the directories tnnnnn-lnnnnnn into tnnnnn/lnnnnnn which
>> would significantly reduce the number of entries in any given
>> directory.
>> Any thoughts or issues on these would be appreciated.
>> Best regards,
>> -SteveW
>> _______________________________________________
>> ka-Map-users mailing list
>> ka-Map-users at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/ka-map-users
>
> _______________________________________________
> ka-Map-users mailing list
> ka-Map-users at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/ka-map-users
More information about the ka-Map-users
mailing list