From crschmidt at metacarta.com  Mon Dec  4 08:06:06 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Mon, 4 Dec 2006 11:06:06 -0500
Subject: [tiling] TileCache 1.2 Release
Message-ID: <20061204160606.GA2774@metacarta.com>

TileCache 1.2 has been released.

TileCache is an implementation of a WMS-C compliant server made
available under the BSD license by MetaCarta, and provides a
Python-based WMS/TMS/WorldWind server, with pluggable caching mechanisms 
and rendering backends. In the simplest use case, TileCache requires only
write access to a disk, the ability to run Python CGI scripts, and a WMS
you want to be cached.

Changes since 1.1:
 * Add support for WorldWind style requests, courtesy of Emily Gouge,
   from Refractions.
 * Add support for Mapnik rendering.
 * Add support for rendering using metatiles: instead of rendering one
   tile at a time, render a 5x5 tileset, and then slice the tiles up. 
   Good for vector layers, where labels crossing tile boundaries is useful. 
   To turn on, use 'metaTile=yes' in layer definition. Requires 
   Python-Imaging.
 * Added Service information caching to mod_python request handler.
 * Improved TMS metadata
 * Fix TileCache to work on Python 2.2 
 * Fix TileCache to work on Windows. (With help from Tim Schaub)

TileCache 1.2 Download: http://labs.metacarta.com/wms-c/tilecache-1.2.tar.gz
TileCache Information: http://labs.metacarta.com/wms-c/
TileCache Demo: http://labs.metacarta.com/wms-c/demo.html

Questions, comments, or suggestions on TileCache can be directed to
labs at metacarta.com.   

Follow-up to this email can be directed to the mailing list where it was
received.

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Wed Dec  6 04:23:49 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed, 6 Dec 2006 07:23:49 -0500
Subject: [tiling] TileCache 1.3
Message-ID: <20061206122349.GA19971@metacarta.com>

TileCache 1.3 has been released.

With this release comes improved metatiling support. 

 * As Chris Holmes reported, images were being shifted from their 
   previous position by the size of the metaBuffer. This has been fixed.
 * Tim Schaub and Matthew Perry reported problems maintaining
   transparency in palletted PNGs. This has been fixed with a patch from
   Matthew.
 * metaBuffer and metaSize variables were not being properly initialized
   from the configuration. Fixed.
 * Mapnik performance has been improved by caching the Mapnik Map
   object. This means, however, that TileCache requires Mapnik SVN r405
   or later to function correctly.
 * Integrated an additional fix to Windows for writing tiles which
   already exist in the Disk Cache, courtesy of Tim Schaub.
 * Added documentation of all layer params to the README.

Thanks to all the users who reported problems and fixes. 

With this release, metaTiling support is now complete. TileCache is now
used with metaBuffering on to power the OpenStreetMap map at
http://labs.metacarta.com/osm/ (powered by Mapnik). It is my belief that
metaTiling support is now complete and well-tested, and ready for use in 
production. 

The new release is available from:
  http://labs.metacarta.com/wms-c/#TileCache

The CHANGELOG for this version of TileCache is at:   
   http://labs.metacarta.com/wms-c/tilecache-1.3.tar.gz/CHANGELOG

Followup to this post should be sent to the mailing list on which you
received it.

(As Schuyler might say, <s>maps</s> metaTiles are cool!)

Regards,
-- 
Christopher Schmidt
MetaCarta

From yu.gotou at gtec-ni.com  Wed Dec 13 23:06:07 2006
From: yu.gotou at gtec-ni.com (YuGo)
Date: Thu, 14 Dec 2006 16:06:07 +0900
Subject: [tiling] tilecache-1.3 problem
Message-ID: <4580F7DF.10402@gtec-ni.com>

Hi,
I tried to set up tilecache-1.3 via mod_python on FedoraCore5.
When I access 'http://192.168.1.45/tilecache/tilecache.py',recieved the
following error messages.
-----------------------------------------------------------------
Mod_python error: "PythonHandler tilecache"
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
291, in HandlerDispatch
    arg=req, silent=hlist.silent)
  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
531, in resolve_object
    raise AttributeError, s
AttributeError: module '/var/www/html/tilecache/tilecache.py' contains
no 'handler'
------------------------------------------------------------------

I added httpd.conf(apache)  this about mod_python.
-----------------------------------------
LoadModule python_module modules/mod_python.so
<Directory "/var/www/html/tilecache">
      AddHandler python-program .py
      PythonHandler tilecache
      PythonDebug On
 </Directory>
------------------------------------------

How to  avoid this errors?



From crschmidt at crschmidt.net  Thu Dec 14 04:51:22 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Thu, 14 Dec 2006 07:51:22 -0500
Subject: [tiling] tilecache-1.3 problem
In-Reply-To: <4580F7DF.10402@gtec-ni.com>
References: <4580F7DF.10402@gtec-ni.com>
Message-ID: <20061214125122.GA18410@crschmidt.net>

On Thu, Dec 14, 2006 at 04:06:07PM +0900, YuGo wrote:
> Hi,
> I tried to set up tilecache-1.3 via mod_python on FedoraCore5.
> When I access 'http://192.168.1.45/tilecache/tilecache.py',recieved the
> following error messages.
> -----------------------------------------------------------------
> Mod_python error: "PythonHandler tilecache"
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
> 291, in HandlerDispatch
>     arg=req, silent=hlist.silent)
>   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
> 531, in resolve_object
>     raise AttributeError, s
> AttributeError: module '/var/www/html/tilecache/tilecache.py' contains
> no 'handler'
> ------------------------------------------------------------------
> 
> I added httpd.conf(apache)  this about mod_python.
> -----------------------------------------
> LoadModule python_module modules/mod_python.so
> <Directory "/var/www/html/tilecache">
>       AddHandler python-program .py
>       PythonHandler tilecache
>       PythonDebug On
>  </Directory>
> ------------------------------------------
> 
> How to  avoid this errors?

Per the README, your <Directory> should look like:

     <Directory /var/www/wms-c/>
         AddHandler python-program .py
         PythonHandler TileCache.Service 
         PythonOption TileCacheConfig /path/to/tilecache.cfg
     </Directory>

That is: TileCache.Service should be used instead of "tilecache", and
you need to include a PythonOption to determine the location of the
TileCacheConfig. 

Regards,
-- 
Christopher Schmidt
Web Developer

From cholmes at openplans.org  Thu Dec 14 10:47:41 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Thu, 14 Dec 2006 13:47:41 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061204160606.GA2774@metacarta.com>
References: <20061204160606.GA2774@metacarta.com>
Message-ID: <45819C4D.6090404@openplans.org>

http://onearth.jpl.nasa.gov/tiled.html

Has this come up on the list before?  It looks like it's similar to 
ours, but a bit different?  Or are they using ours?  Seems like it'd be 
good to standardize with them if we haven't already.  If we have then we 
should list in the implementation section...

Chris

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061214/ad0e745a/attachment.vcf 

From ijturton at gmail.com  Thu Dec 14 11:29:04 2006
From: ijturton at gmail.com (Ian Turton)
Date: Thu, 14 Dec 2006 14:29:04 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <45819C4D.6090404@openplans.org>
References: <20061204160606.GA2774@metacarta.com>
	<45819C4D.6090404@openplans.org>
Message-ID: <ff30b0340612141129t2f60c59di82dc8ca40abff385@mail.gmail.com>

On 12/14/06, Chris Holmes <cholmes at openplans.org> wrote:
> http://onearth.jpl.nasa.gov/tiled.html
>
> Has this come up on the list before?  It looks like it's similar to
> ours, but a bit different?  Or are they using ours?  Seems like it'd be
> good to standardize with them if we haven't already.  If we have then we
> should list in the implementation section...

This came up at one of the OGC meetings this week, I believe it is a
different standard that they are using (WMS-C?). I'll see if I can
find my notes which meeting it was and see if we could find a link to
the talk.

Ian


-- 

Ian Turton
http://www.geotools.org
http://pennspace.blogspot.com/

From SCHUTP at AGR.GC.CA  Thu Dec 14 11:37:42 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Thu, 14 Dec 2006 14:37:42 -0500
Subject: [tiling] Nasa WMS Tile server?
Message-ID: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>

It's somewhat different, and a fair bit better IMHO.  I think we can
learn from what they've done.  One important thing they did is to choose
a larger tile size than we have.  This has the effect of significantly
reducing traffic and avoids limitations on the number of files in a
directory.  It handles millions of hits a day, on a fairly small server.


Cheers, Peter

-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Chris Holmes
Sent: Thursday, December 14, 2006 1:48 PM
Cc: tiling at lists.eogeo.org
Subject: [tiling] Nasa WMS Tile server?

http://onearth.jpl.nasa.gov/tiled.html

Has this come up on the list before?  It looks like it's similar to 
ours, but a bit different?  Or are they using ours?  Seems like it'd be 
good to standardize with them if we haven't already.  If we have then we

should list in the implementation section...

Chris

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org

From crschmidt at metacarta.com  Thu Dec 14 12:07:54 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Thu, 14 Dec 2006 15:07:54 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>
Message-ID: <20061214200754.GB29263@metacarta.com>

On Thu, Dec 14, 2006 at 02:37:42PM -0500, Schut, Peter wrote:
> It's somewhat different, and a fair bit better IMHO.  I think we can
> learn from what they've done.  One important thing they did is to choose
> a larger tile size than we have.  

I think I'm confused on something here, and I'd like to try and
understand why.

The WMS-C spec, as discussed at FOSS4G, contains a way to describe the
size of the images in a layer. The TileSets contained in the TileCache
metadata[1] include a Width and Height to describe the size of the
images. This means that WMS-C  

> This has the effect of significantly
> reducing traffic and avoids limitations on the number of files in a
> directory.  It handles millions of hits a day, on a fairly small server.

If you consider going down to zoom level 20, you'll have a default of 2
million tiles. Directories on ext3 support 32000 subdirectories. We're
still off by a fair number of levels that way.

The problem with 512px base images is that you can't fit the entire
world (and only the entire world -- no extras) into a 512px wide device
screen if that's your top size. 256px lets you fit it into 512px --
128px lets you fit it in 256. This is one of the benefits of WMS-C: you
can specify your tile size to match the environement you're in and the
service you want to offer. 

I can't load the onearth page -- server is timing out for me -- so I'd
be interested if someone could mirror the content somewhere so I can
actually understand a bit better, and perhaps address differences
between the NASA spec and WMS-C.

[1]
http://labs.metacarta.com/wms-c/Basic.py?request=GetCapabilities&service=WMS 

Regards,
-- 
Christopher Schmidt
MetaCarta

From schuyler at nocat.net  Thu Dec 14 11:41:41 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Thu, 14 Dec 2006 11:41:41 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <ff30b0340612141129t2f60c59di82dc8ca40abff385@mail.gmail.com>
References: <20061204160606.GA2774@metacarta.com>
	<45819C4D.6090404@openplans.org>
	<ff30b0340612141129t2f60c59di82dc8ca40abff385@mail.gmail.com>
Message-ID: <20061214194141.GT3838@vishnu.tridity.org>

* On 14-Dec-2006 at 11:35AM PST, Ian Turton said:
> On 12/14/06, Chris Holmes <cholmes at openplans.org> wrote:
> > http://onearth.jpl.nasa.gov/tiled.html
> >
> > Has this come up on the list before?  It looks like it's similar to
> > ours, but a bit different?  Or are they using ours?  Seems like it'd be
> > good to standardize with them if we haven't already.  If we have then we
> > should list in the implementation section...
> 
> This came up at one of the OGC meetings this week, I believe it is a
> different standard that they are using (WMS-C?). I'll see if I can
> find my notes which meeting it was and see if we could find a link to
> the talk.

p.s. WMS-C is "ours" insofar as it came out of the OSGeo tiling BoF at
FOSS4G 2006... :)

SDDE

From cholmes at openplans.org  Thu Dec 14 12:22:17 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Thu, 14 Dec 2006 15:22:17 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061214200754.GB29263@metacarta.com>
References: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>
	<20061214200754.GB29263@metacarta.com>
Message-ID: <4581B279.8020803@openplans.org>



Christopher Schmidt wrote:
> On Thu, Dec 14, 2006 at 02:37:42PM -0500, Schut, Peter wrote:
>> It's somewhat different, and a fair bit better IMHO.  I think we can
>> learn from what they've done.  One important thing they did is to choose
>> a larger tile size than we have.  
> 
> I think I'm confused on something here, and I'd like to try and
> understand why.
> 
> The WMS-C spec, as discussed at FOSS4G, contains a way to describe the
> size of the images in a layer. The TileSets contained in the TileCache
> metadata[1] include a Width and Height to describe the size of the
> images. This means that WMS-C  
> 
>> This has the effect of significantly
>> reducing traffic and avoids limitations on the number of files in a
>> directory.  It handles millions of hits a day, on a fairly small server.
> 
> If you consider going down to zoom level 20, you'll have a default of 2
> million tiles. Directories on ext3 support 32000 subdirectories. We're
> still off by a fair number of levels that way.
> 
> The problem with 512px base images is that you can't fit the entire
> world (and only the entire world -- no extras) into a 512px wide device
> screen if that's your top size. 256px lets you fit it into 512px --
> 128px lets you fit it in 256. This is one of the benefits of WMS-C: you
> can specify your tile size to match the environement you're in and the
> service you want to offer. 
> 
> I can't load the onearth page -- server is timing out for me -- so I'd
> be interested if someone could mirror the content somewhere so I can
> actually understand a bit better, and perhaps address differences
> between the NASA spec and WMS-C.


Just the contents of the page I linked to? 
http://sigma.openplans.org/cholmes/tiled.html

The links they gave were relative, so they now point at sigma.  But they 
weren't working for me on their page (like: 
http://onearth.jpl.nasa.gov/wms.cgi?request=GetTileService)

It'd definitely be great if we made something compatible with what 
they've done.  And it doesn't sound too far apart.

Ian, if you've got the contact info of someone there that'd be great.

Chris

> 
> [1]
> http://labs.metacarta.com/wms-c/Basic.py?request=GetCapabilities&service=WMS 
> 
> Regards,

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061214/dc570b7f/attachment.vcf 

From crschmidt at crschmidt.net  Thu Dec 14 12:32:13 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Thu, 14 Dec 2006 15:32:13 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <4581B279.8020803@openplans.org>
References: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>
	<20061214200754.GB29263@metacarta.com>
	<4581B279.8020803@openplans.org>
Message-ID: <20061214203212.GC4754@crschmidt.net>

On Thu, Dec 14, 2006 at 03:22:17PM -0500, Chris Holmes wrote:
> Just the contents of the page I linked to? 
> http://sigma.openplans.org/cholmes/tiled.html

It looks like this is WMS-C with a different pattern of metadata.
Without access to their actual metadata, it's hard to match the output.
WMS-C and TileCache match their "features of this extension mechanism":

 - It is a minimal addition to the existing WMS standard.
 - A tiled WMS client can operate as a full WMS client.
 - The data transfer is done using standard WMS, eliminating the need to
   introduce a different protocol.
 - A standard WMS server can easily be modified to provide the needed
   tiled WMS metadata, which exposes potential performance or allows the
   use of a stand alone WMS caching service.
 - A stand alone tiled WMS server can operate without a full WMS server,
   providing data for only a limited set of clients. A tiled WMS server
   would be much easier to implement and deploy than a full WMS server,
   needs much lower computing resource and at the same time provides a
   higher performance level for certain applications. Such a server
   could just return a mostly empty Capability file to avoid breaking
   applications that do expect a full WMS server. This type of server
   could even be considered a WMS server itself.
 - It is intended to serve as the basis for an OGC WMS enhancement.

The one to which WMS-C doesn't apply:
  - The full set of WMS features is available for tiled application use,
    including any coordinate system and resolution, layer combination or
    use of styled layer descriptors (SLD).

Isn't important to me -- I don't know about the rest of the world.    

> It'd definitely be great if we made something compatible with what 
> they've done.  And it doesn't sound too far apart.

It's hard to know what they've done without access to a sample of their
metadata, unfortunately, but if we got one, I'd be happy to drop support 
for their metadata into TileCache, in case there are any clients out
there that support it. (Are there?) 

Regards,
-- 
Christopher Schmidt
Web Developer

From nhv at cape.com  Thu Dec 14 13:31:59 2006
From: nhv at cape.com (Norman Vine)
Date: Thu, 14 Dec 2006 16:31:59 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <4581B279.8020803@openplans.org>
Message-ID: <200612142131.kBELVwSI014058@smtp11.cape.com>

Chris Holmes  writes:
> 
> Just the contents of the page I linked to? 
> http://sigma.openplans.org/cholmes/tiled.html
> 
< snip >
> 
> Ian, if you've got the contact info of someone there that'd be great.

Contact info is on the bottom of the above page

Norman


From schuyler at nocat.net  Thu Dec 14 14:05:16 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Thu, 14 Dec 2006 14:05:16 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061214203212.GC4754@crschmidt.net>
References: <783BB96C25B79249A236DF62F559D6A503BF9A8B@onncrxms3.agr.gc.ca>
	<20061214200754.GB29263@metacarta.com>
	<4581B279.8020803@openplans.org>
	<20061214203212.GC4754@crschmidt.net>
Message-ID: <20061214220516.GU3838@vishnu.tridity.org>

* On 14-Dec-2006 at 12:32PM PST, Christopher Schmidt said:
> 
> The one to which WMS-C doesn't apply:
>   - The full set of WMS features is available for tiled application use,
>     including any coordinate system and resolution, layer combination or
>     use of styled layer descriptors (SLD).
> 
> Isn't important to me -- I don't know about the rest of the world.    

FWIW WMS-C *does* support these things, more or less, but not in the
default profiles. I don't think anyone is using it this way, though.

> > It'd definitely be great if we made something compatible with what 
> > they've done.  And it doesn't sound too far apart.
> 
> It's hard to know what they've done without access to a sample of their
> metadata, unfortunately, but if we got one, I'd be happy to drop support 
> for their metadata into TileCache, in case there are any clients out
> there that support it. (Are there?) 

I'd rather talk Lucian Plesea into supporting the WMS-C metadata
description. :-D

SDE

From yu.gotou at gtec-ni.com  Thu Dec 14 18:34:13 2006
From: yu.gotou at gtec-ni.com (YuGo)
Date: Fri, 15 Dec 2006 11:34:13 +0900
Subject: [tiling] tilecache-1.3 problem
In-Reply-To: <20061214125122.GA18410@crschmidt.net>
References: <4580F7DF.10402@gtec-ni.com> <20061214125122.GA18410@crschmidt.net>
Message-ID: <458209A5.4030708@gtec-ni.com>


Thanks Christopher Schmidt.

I followed your advice ,and succeced to display the sample layer.
But When I tried to include my GeoServer,no image returned.

tilecache.cfg is follows.
----------------------------------------------
[topp:tasmania_water_bodies]
type=WMSLayer
url=http://192.168.1.45:8080/geoserver/wms
extension=png
------------------------------------------------
And I changed layer name in 'index.html'.

When I right clicked on image to show propaties and access the url,
I received this error message.
--------------------------------------------------------------------------
An error occurred: 'topp:tasmania_water_bodies'
   File "/var/www/html/tilecache/TileCache/Service.py", line 398, in 
modPythonHandler
     host )

   File "/var/www/html/tilecache/TileCache/Service.py", line 377, in 
dispatchRequest
     tile = WMS(self).parse(params, path_info, host)

   File "/var/www/html/tilecache/TileCache/Service.py", line 118, in parse
     return self.getMap(param)

   File "/var/www/html/tilecache/TileCache/Service.py", line 122, in getMap
     layer = self.service.layers[param["layers"]]
----------------------------------------------------------------------------

Why can't display?


YuGo.

> Per the README, your <Directory> should look like:
> 
>      <Directory /var/www/wms-c/>
>          AddHandler python-program .py
>          PythonHandler TileCache.Service 
>          PythonOption TileCacheConfig /path/to/tilecache.cfg
>      </Directory>
> 
> That is: TileCache.Service should be used instead of "tilecache", and
> you need to include a PythonOption to determine the location of the
> TileCacheConfig. 

From crschmidt at metacarta.com  Thu Dec 14 18:43:27 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Thu, 14 Dec 2006 21:43:27 -0500
Subject: [tiling] tilecache-1.3 problem
In-Reply-To: <458209A5.4030708@gtec-ni.com>
References: <4580F7DF.10402@gtec-ni.com> <20061214125122.GA18410@crschmidt.net>
	<458209A5.4030708@gtec-ni.com>
Message-ID: <20061215024327.GA30840@metacarta.com>

On Fri, Dec 15, 2006 at 11:34:13AM +0900, YuGo wrote:
> 
> Thanks Christopher Schmidt.
> 
> I followed your advice ,and succeced to display the sample layer.
> But When I tried to include my GeoServer,no image returned.

For some reason, your request is not matching any layer in your
configuration.

I would try changing your config to:

[water]
type=WMSLayer
layers=topp:tasmania_water_bodies
url=http://192.168.1.45:8080/geoserver/wms
extension=png

Then changing the layers in OpenLayers (or other client)  to 'water'. 

I think that it's a possibility that ConfigParser doesn't correctly
support : in heading sections. This should determine if that is the
case.

Note, the config is cached across apache requests in mod_proxy: you
should restart apache to ensure that you're getting the most up to date
config file. 

Regards,
-- 
Christopher Schmidt
MetaCarta

From yu.gotou at gtec-ni.com  Thu Dec 14 20:01:31 2006
From: yu.gotou at gtec-ni.com (YuGo)
Date: Fri, 15 Dec 2006 13:01:31 +0900
Subject: [tiling] tilecache-1.3 problem
In-Reply-To: <20061215024327.GA30840@metacarta.com>
References: <4580F7DF.10402@gtec-ni.com> <20061214125122.GA18410@crschmidt.net>
	<458209A5.4030708@gtec-ni.com>
	<20061215024327.GA30840@metacarta.com>
Message-ID: <45821E1B.4000301@gtec-ni.com>

Thanks Christopher.
I changed layer name  and Python program seems to run.
But I can't find image in the map because this layer is too small polygon.
I tried to configure levels or bbox in 'tilecache.cfg' and recieved errors.

How to set boudaries on this map?

YuGo.


> For some reason, your request is not matching any layer in your
> configuration.
> 
> I would try changing your config to:
> 
> [water]
> type=WMSLayer
> layers=topp:tasmania_water_bodies
> url=http://192.168.1.45:8080/geoserver/wms
> extension=png
> 
> Then changing the layers in OpenLayers (or other client)  to 'water'. 
> 
> I think that it's a possibility that ConfigParser doesn't correctly
> support : in heading sections. This should determine if that is the
> case.
> 
> Note, the config is cached across apache requests in mod_proxy: you
> should restart apache to ensure that you're getting the most up to date
> config file. 

From mikel_maron at yahoo.com  Fri Dec 15 03:32:59 2006
From: mikel_maron at yahoo.com (Mikel Maron)
Date: Fri, 15 Dec 2006 03:32:59 -0800 (PST)
Subject: [tiling] Nasa WMS Tile server?
Message-ID: <20061215113259.26185.qmail@web30813.mail.mud.yahoo.com>

> > > It'd definitely be great if we made something compatible with what 
> > > they've done.  And it doesn't sound too far apart.
> > 
> > It's hard to know what they've done without access to a sample of their
> > metadata, unfortunately, but if we got one, I'd be happy to drop support 
> > for their metadata into TileCache, in case there are any clients out
> > there that support it. (Are there?) 
> 
> I'd rather talk Lucian Plesea into supporting the WMS-C metadata
> description. :-D

The onearth/tiled.html page used to have examples of the metadata,
I'm trying to recall what it looked like.

A cache description was actually a list of valid WMS requests. 
Each WMS request specified a tiling at a particular zoom level. 
The bbox of that request corresponded to the bbox of the origin tile (in the upper left hand corner). 
The latitude and longitude range of the bbox is used by the client to calculate the number of number of tiles. 
So each example WMS request corresponds to a different resolution.
The remainder of the parameters .. width/height/format/etc .. do not change across the resolution level.

Essentially it describes the same information as WMS-C, and a WMS-C metadata description could be created.

...Except, crucially, the origin is in the upper left hand corner rather then the bottom. This small detail makes
WMS-C incompatible with OnEarth. 

It also means that TMS as is could never be used to describe Google or Yahoo Maps tiles.

-Mikel






From crschmidt at metacarta.com  Fri Dec 15 04:56:06 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Fri, 15 Dec 2006 07:56:06 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215113259.26185.qmail@web30813.mail.mud.yahoo.com>
References: <20061215113259.26185.qmail@web30813.mail.mud.yahoo.com>
Message-ID: <20061215125606.GA32638@metacarta.com>

On Fri, Dec 15, 2006 at 03:32:59AM -0800, Mikel Maron wrote:
> > > > It'd definitely be great if we made something compatible with what 
> > > > they've done.  And it doesn't sound too far apart.
> > > 
> > > It's hard to know what they've done without access to a sample of their
> > > metadata, unfortunately, but if we got one, I'd be happy to drop support 
> > > for their metadata into TileCache, in case there are any clients out
> > > there that support it. (Are there?) 
> > 
> > I'd rather talk Lucian Plesea into supporting the WMS-C metadata
> > description. :-D
> 
> The onearth/tiled.html page used to have examples of the metadata,
> I'm trying to recall what it looked like.
> 
> A cache description was actually a list of valid WMS requests. 
> Each WMS request specified a tiling at a particular zoom level. 
> The bbox of that request corresponded to the bbox of the origin tile (in the upper left hand corner). 
> The latitude and longitude range of the bbox is used by the client to calculate the number of number of tiles. 
> So each example WMS request corresponds to a different resolution.
> The remainder of the parameters .. width/height/format/etc .. do not change across the resolution level.
> 
> Essentially it describes the same information as WMS-C, and a WMS-C metadata description could be created.
> 
> ...Except, crucially, the origin is in the upper left hand corner rather then the bottom. This small detail makes
> WMS-C incompatible with OnEarth. 

Where your origin is is also configurable under WMS-C -- and it
shouldn't have any affect anyway. If I start at the bottom and go up, or
start at the top and go down, so long as I have a rectangular area that
I'm viewing, the *bounding box* will be the same. 

(This might require a picture to prove, let me know if you want one.)

Regards,
-- 
Christopher Schmidt
MetaCarta

From mikel_maron at yahoo.com  Fri Dec 15 05:18:24 2006
From: mikel_maron at yahoo.com (Mikel Maron)
Date: Fri, 15 Dec 2006 05:18:24 -0800 (PST)
Subject: [tiling] Nasa WMS Tile server?
Message-ID: <20061215131824.65903.qmail@web30809.mail.mud.yahoo.com>



> > Essentially it describes the same information as WMS-C, and a WMS-C metadata description could be created.
> > 
> > ...Except, crucially, the origin is in the upper left hand corner rather then the bottom. This small detail makes
> > WMS-C incompatible with OnEarth. 
>
> Where your origin is is also configurable under WMS-C -- and it
> shouldn't have any affect anyway. If I start at the bottom and go up, or
> start at the top and go down, so long as I have a rectangular area that
> I'm viewing, the *bounding box* will be the same. 

Oh I didn't realize that the origin was configurable, and that the tiling could proceed down. 

I'm reading from this one .. http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation

"the bbox coordinates
must be equal to the grid origin, plus some non-negative integer multiple of
the tile size in pixels, multiplied by one of the supported resolutions listed
in the layer's tiling profile."



So the complication with OnEarth is that the tiles in lower resolution levels extend beyond the earth's extent.

At the top, the resolution is .5 degrees / pixel. The tile size is 512. So 256x256 degrees. So an "overhang" of 76 degrees of longitude.
If we were able to look at these tiles, the bottom 76 degrees is just black. Also on the eastern edge of the second tile.
At .125 degrees/pixel, each tile is 64x64 degrees, so there 12 degrees of longitude overhang.

So if the origin were to start at the bottom, the origin would need to be different for each resolution level.

Yes this is a bit strange. Somehow it simply worked when I implemented in worldKit, so I didn't complain. :)

-Mikel





From crschmidt at metacarta.com  Fri Dec 15 06:06:35 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Fri, 15 Dec 2006 09:06:35 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215131824.65903.qmail@web30809.mail.mud.yahoo.com>
References: <20061215131824.65903.qmail@web30809.mail.mud.yahoo.com>
Message-ID: <20061215140635.GB32638@metacarta.com>

On Fri, Dec 15, 2006 at 05:18:24AM -0800, Mikel Maron wrote:
> 
> 
> > > Essentially it describes the same information as WMS-C, and a WMS-C metadata description could be created.
> > > 
> > > ...Except, crucially, the origin is in the upper left hand corner rather then the bottom. This small detail makes
> > > WMS-C incompatible with OnEarth. 
> >
> > Where your origin is is also configurable under WMS-C -- and it
> > shouldn't have any affect anyway. If I start at the bottom and go up, or
> > start at the top and go down, so long as I have a rectangular area that
> > I'm viewing, the *bounding box* will be the same. 
> 
> Oh I didn't realize that the origin was configurable, and that the tiling could proceed down. 
> 
> I'm reading from this one .. http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
> 
> "the bbox coordinates
> must be equal to the grid origin, plus some non-negative integer multiple of
> the tile size in pixels, multiplied by one of the supported resolutions listed
> in the layer's tiling profile."

The 'non-negative integer' is probably unneccesary. It won't make a
difference in the real world. I'll talk to Schuyler and find out if he
thinks it's important.

> So the complication with OnEarth is that the tiles in lower resolution levels extend beyond the earth's extent.
> 
> At the top, the resolution is .5 degrees / pixel. The tile size is 512. So 256x256 degrees. So an "overhang" of 76 degrees of longitude.
> If we were able to look at these tiles, the bottom 76 degrees is just black. Also on the eastern edge of the second tile.
> At .125 degrees/pixel, each tile is 64x64 degrees, so there 12 degrees of longitude overhang.
> 
> So if the origin were to start at the bottom, the origin would need to be different for each resolution level.

Got it. Yeah, I assumed that they had picked a sane resolution:
apparently an unfair assumption :) However, if we remove the
'non-negative' from the WMS-C spec, then this shouldn't matter? 

Regards,
-- 
Christopher Schmidt
MetaCarta

From mikel_maron at yahoo.com  Fri Dec 15 06:15:46 2006
From: mikel_maron at yahoo.com (Mikel Maron)
Date: Fri, 15 Dec 2006 06:15:46 -0800 (PST)
Subject: [tiling] Nasa WMS Tile server?
Message-ID: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>


> Got it. Yeah, I assumed that they had picked a sane resolution:
> apparently an unfair assumption :) However, if we remove the
> 'non-negative' from the WMS-C spec, then this shouldn't matter? 

Yup that would do it.

For TMS (a different thing I realize) it has origin and tiling direction forced to the lower left.
Or is this possibly malleable? To cover Google for instance.

Mikel




From crschmidt at crschmidt.net  Fri Dec 15 06:21:15 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 15 Dec 2006 09:21:15 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
References: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
Message-ID: <20061215142115.GB6460@crschmidt.net>

On Fri, Dec 15, 2006 at 06:15:46AM -0800, Mikel Maron wrote:
> 
> > Got it. Yeah, I assumed that they had picked a sane resolution:
> > apparently an unfair assumption :) However, if we remove the
> > 'non-negative' from the WMS-C spec, then this shouldn't matter? 
> 
> Yup that would do it.
> 
> For TMS (a different thing I realize) it has origin and tiling direction forced to the lower left.
> Or is this possibly malleable? To cover Google for instance.

/me calls out to Paul

For the record, it's my plan to add a switch to the TMS layer in
OpenLayers to do this, whether TMS does it or not. The support for this
type of request is also already in TileCache (thought not released yet)
-- "?type=google" at the end of a TMS string will swap the order.

Regards,
-- 
Christopher Schmidt
Web Developer

From pramsey at refractions.net  Fri Dec 15 09:30:27 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 15 Dec 2006 09:30:27 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215142115.GB6460@crschmidt.net>
References: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
	<20061215142115.GB6460@crschmidt.net>
Message-ID: <4582DBB3.9080909@refractions.net>

What is the rationale behind making the TMS requests non-uniform? Can't 
the server re-write this stuff magically in the background?

Christopher Schmidt wrote:
> On Fri, Dec 15, 2006 at 06:15:46AM -0800, Mikel Maron wrote:
>>> Got it. Yeah, I assumed that they had picked a sane resolution:
>>> apparently an unfair assumption :) However, if we remove the
>>> 'non-negative' from the WMS-C spec, then this shouldn't matter? 
>> Yup that would do it.
>>
>> For TMS (a different thing I realize) it has origin and tiling direction forced to the lower left.
>> Or is this possibly malleable? To cover Google for instance.
> 
> /me calls out to Paul
> 
> For the record, it's my plan to add a switch to the TMS layer in
> OpenLayers to do this, whether TMS does it or not. The support for this
> type of request is also already in TileCache (thought not released yet)
> -- "?type=google" at the end of a TMS string will swap the order.
> 
> Regards,


From crschmidt at metacarta.com  Fri Dec 15 10:30:59 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Fri, 15 Dec 2006 13:30:59 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <4582DBB3.9080909@refractions.net>
References: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
	<20061215142115.GB6460@crschmidt.net>
	<4582DBB3.9080909@refractions.net>
Message-ID: <20061215183059.GA1075@metacarta.com>

On Fri, Dec 15, 2006 at 09:30:27AM -0800, Paul Ramsey wrote:
> What is the rationale behind making the TMS requests non-uniform? Can't 
> the server re-write this stuff magically in the background?

I'm not sure what you mean by 'non-uniform'. I was under the impression
that TMS had a goal of capturing the common use case of creating a
collection of files on disk and then serving them out without any server
side piece. 

One of the common use cases is accessing tiles via a Google Maps client,
which uses the same x and the same z, but a y that is "maxYTiles -
currentTMSYIndex". Being able to address this in the spec means the
addition of one piece of metadata, and a relatively tiny bit of math to
figure out a different tile index if it starts from there.

Could you explain a bit more of what you mean so I can try to
understand?

Regards,
-- 
Christopher Schmidt
MetaCarta

From schuyler at nocat.net  Fri Dec 15 10:48:45 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Fri, 15 Dec 2006 10:48:45 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215140635.GB32638@metacarta.com>
References: <20061215131824.65903.qmail@web30809.mail.mud.yahoo.com>
	<20061215140635.GB32638@metacarta.com>
Message-ID: <20061215184845.GW3838@vishnu.tridity.org>

* On 15-Dec-2006 at  6:08AM PST, Christopher Schmidt said:
> > I'm reading from this one ..
> > http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
> > 
> > "the bbox coordinates must be equal to the grid origin, plus some
> > non-negative integer multiple of the tile size in pixels,
> > multiplied by one of the supported resolutions listed in the
> > layer's tiling profile."
> 
> The 'non-negative integer' is probably unneccesary. It won't make a
> difference in the real world. I'll talk to Schuyler and find out if
> he thinks it's important.

It's not important. I think I was just being hyperspecific there.
Let's remove it.

SDE

From pramsey at refractions.net  Fri Dec 15 15:09:23 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 15 Dec 2006 15:09:23 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061215183059.GA1075@metacarta.com>
References: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
	<20061215142115.GB6460@crschmidt.net>
	<4582DBB3.9080909@refractions.net>
	<20061215183059.GA1075@metacarta.com>
Message-ID: <45832B23.5000601@refractions.net>

Christopher Schmidt wrote:
> On Fri, Dec 15, 2006 at 09:30:27AM -0800, Paul Ramsey wrote:
>> What is the rationale behind making the TMS requests non-uniform? Can't 
>> the server re-write this stuff magically in the background?
> 
> I'm not sure what you mean by 'non-uniform'. I was under the impression
> that TMS had a goal of capturing the common use case of creating a
> collection of files on disk and then serving them out without any server
> side piece. 

Right, and that implies a particular ordering scheme for those files. 
The fewer schemes, the easier it is for people to know what to expect.

> One of the common use cases is accessing tiles via a Google Maps client,
> which uses the same x and the same z, but a y that is "maxYTiles -
> currentTMSYIndex". Being able to address this in the spec means the
> addition of one piece of metadata, and a relatively tiny bit of math to
> figure out a different tile index if it starts from there.
> 
> Could you explain a bit more of what you mean so I can try to
> understand?

I guess I don't understand why you can't do that little bit of math 
(flipping your access) on the client side rather than re-organizing the 
server side.

The idea is that the server side has one organization scheme, so that 
all clients, google or otherwise, can use the same interface.

If this is an absolute requirement (being able to invert the y-axis) 
then I would suggest strongly that creating an inverted TileMap service 
and flagging it such in the metadata is preferable to starting to flag 
things at the back of the actual tile access URL.

P.

> Regards,


From crschmidt at metacarta.com  Fri Dec 15 21:46:26 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Sat, 16 Dec 2006 00:46:26 -0500
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <45832B23.5000601@refractions.net>
References: <20061215141551.52740.qmail@web30804.mail.mud.yahoo.com>
	<20061215142115.GB6460@crschmidt.net>
	<4582DBB3.9080909@refractions.net>
	<20061215183059.GA1075@metacarta.com>
	<45832B23.5000601@refractions.net>
Message-ID: <20061216054626.GA10601@metacarta.com>

On Fri, Dec 15, 2006 at 03:09:23PM -0800, Paul Ramsey wrote:
> Christopher Schmidt wrote:
> >On Fri, Dec 15, 2006 at 09:30:27AM -0800, Paul Ramsey wrote:
> >>What is the rationale behind making the TMS requests non-uniform? Can't 
> >>the server re-write this stuff magically in the background?
> >
> >I'm not sure what you mean by 'non-uniform'. I was under the impression
> >that TMS had a goal of capturing the common use case of creating a
> >collection of files on disk and then serving them out without any server
> >side piece. 
> 
> Right, and that implies a particular ordering scheme for those files. 
> The fewer schemes, the easier it is for people to know what to expect.
> 
> >One of the common use cases is accessing tiles via a Google Maps client,
> >which uses the same x and the same z, but a y that is "maxYTiles -
> >currentTMSYIndex". Being able to address this in the spec means the
> >addition of one piece of metadata, and a relatively tiny bit of math to
> >figure out a different tile index if it starts from there.
> >
> >Could you explain a bit more of what you mean so I can try to
> >understand?
> 
> I guess I don't understand why you can't do that little bit of math 
> (flipping your access) on the client side rather than re-organizing the 
> server side.

Because the clients are often hard to change. Many clients use Google's
X/Y/Z param with no knowledge of geography at all, or are hard to change
-- for example, I have no clue how I would change maemo mapper. 

> The idea is that the server side has one organization scheme, so that 
> all clients, google or otherwise, can use the same interface.
> 
> If this is an absolute requirement (being able to invert the y-axis) 
> then I would suggest strongly that creating an inverted TileMap service 
> and flagging it such in the metadata is preferable to starting to flag 
> things at the back of the actual tile access URL.

I have no strong requirement. Mikel, it sounds like this is the answer
to your statement "TMS can't describe Google Maps Tiles" -- "Correct, it
can't, and it probably shouldn't." (unless I'm not understanding
something.)

Regards,
-- 
Christopher Schmidt
MetaCarta

From mikel_maron at yahoo.com  Sat Dec 16 01:25:34 2006
From: mikel_maron at yahoo.com (Mikel Maron)
Date: Sat, 16 Dec 2006 01:25:34 -0800 (PST)
Subject: [tiling] Nasa WMS Tile server?
Message-ID: <20061216092534.37015.qmail@web30809.mail.mud.yahoo.com>



> > The idea is that the server side has one organization scheme, so that 
> > all clients, google or otherwise, can use the same interface.
> > 
> > If this is an absolute requirement (being able to invert the y-axis) 
> > then I would suggest strongly that creating an inverted TileMap service 
> > and flagging it such in the metadata is preferable to starting to flag 
> > things at the back of the actual tile access URL.
> 
> I have no strong requirement. Mikel, it sounds like this is the answer
> to your statement "TMS can't describe Google Maps Tiles" -- "Correct, it
> can't, and it probably shouldn't." (unless I'm not understanding
> something.)

I think Paul is saying that TMS metadata should be able to describe this?

Just to be clear, I'm thinking about servers describing their cache in a TileMapService document.

If Google were to someday want to publish a TMS description, they couldn't since
their origin is in the upper right, and tiling proceeds down, with positive numbering.
Microsoft and Yahoo are the same. OpenStreetMap is doing the same.

Not that I expect G-Y-M to make their raw tiles available like this. My point is that a
lot of implementations have thought of tiling from the NW origin, and it seems like a minor
change to the spec to support this. The question really would be how hard would it
be for a TMS client to support both .. and I don't think it's very hard at all, since both
OpenLayers and worldKit do so easily.

-Mikel





From pramsey at refractions.net  Sat Dec 16 11:12:31 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Sat, 16 Dec 2006 11:12:31 -0800
Subject: [tiling] Nasa WMS Tile server?
In-Reply-To: <20061216092534.37015.qmail@web30809.mail.mud.yahoo.com>
References: <20061216092534.37015.qmail@web30809.mail.mud.yahoo.com>
Message-ID: <E19DD8C4-BE61-4524-9147-A12ACBDE03F1@refractions.net>


On 16-Dec-06, at 1:25 AM, Mikel Maron wrote:

>
>
>>> The idea is that the server side has one organization scheme, so  
>>> that
>>> all clients, google or otherwise, can use the same interface.
>>>
>>> If this is an absolute requirement (being able to invert the y-axis)
>>> then I would suggest strongly that creating an inverted TileMap  
>>> service
>>> and flagging it such in the metadata is preferable to starting to  
>>> flag
>>> things at the back of the actual tile access URL.
>>
>> I have no strong requirement. Mikel, it sounds like this is the  
>> answer
>> to your statement "TMS can't describe Google Maps Tiles" --  
>> "Correct, it
>> can't, and it probably shouldn't." (unless I'm not understanding
>> something.)
>
> I think Paul is saying that TMS metadata should be able to describe  
> this?

As it stands right now, it can't, but a flag could be added to the  
metadata to do so.  I resist because adding another flag to the  
<TileMap> description just makes the whole thing yet more  
"modey" (hooray, another degree of freedom!).  However, if this is  
truly a make-or-break for a swathe of clients, I could add in that  
extra parameter.

Bear in mind that the request signature for a tile would still be  
http://blahblahblah/x/y.ext, which is not the signature any of GYM is  
using. If they decided to publish in TMS, would they not simply add  
the logic in their TMS to do the axis flip to match the TMS scheme?

Or, conversely, perhaps it is better just to flip the TMS axis scheme  
to match the majoritarian implementation? (call me crazy but I like  
that the TMS tiling numbers increment in the same directions as the  
underlying cartesian coordinates though)

P

>
> Just to be clear, I'm thinking about servers describing their cache  
> in a TileMapService document.
>
> If Google were to someday want to publish a TMS description, they  
> couldn't since
> their origin is in the upper right, and tiling proceeds down, with  
> positive numbering.
> Microsoft and Yahoo are the same. OpenStreetMap is doing the same.
>
> Not that I expect G-Y-M to make their raw tiles available like  
> this. My point is that a
> lot of implementations have thought of tiling from the NW origin,  
> and it seems like a minor
> change to the spec to support this. The question really would be  
> how hard would it
> be for a TMS client to support both .. and I don't think it's very  
> hard at all, since both
> OpenLayers and worldKit do so easily.
>
> -Mikel
>
>
>
>


From eshabtai at gmail.com  Wed Dec 20 14:47:58 2006
From: eshabtai at gmail.com (Ehud Shabtai)
Date: Thu, 21 Dec 2006 00:47:58 +0200
Subject: [tiling] WSGI handler for tilecache
Message-ID: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>

Hi,

I'm using lighttpd as my http server so I needed a better handler for
tilecache than CGI.
I have implemented a WSGI handler which is a common api for implementing web
services.
There are different server implementation for WSGI handlers such as: http
server, fastcgi ,scgi, etc'.
As such, this patch provides an http server, fastcgi server and scgi server.

I have only tested the http server and scgi (using lighttpd) and they seem
to work fine.

You will need to install the following python modules (just use
easy_install):
wsgiref - for the wsgi interface - it is already a part of the standard
python 2.5
flup - implements scgi and fastcgi servers
paste - for parsing the scgi environment


-- 
Ehud Shabtai
http://www.freemap.co.il/map/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061221/17d115f0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tilecache_wsgi.patch
Type: text/x-patch
Size: 3462 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061221/17d115f0/attachment.bin 

From cholmes at openplans.org  Wed Dec 20 16:09:16 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Wed, 20 Dec 2006 19:09:16 -0500
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
Message-ID: <4589D0AC.5070707@openplans.org>

Very cool.

We're making heavy use of WSGI in our other projects, and definitely 
desire mapping integration at some point, so this will definitely be 
useful to us in the future.

best regards,

Chris

Ehud Shabtai wrote:
> Hi,
> 
> I'm using lighttpd as my http server so I needed a better handler for 
> tilecache than CGI.
> I have implemented a WSGI handler which is a common api for implementing 
> web services.
> There are different server implementation for WSGI handlers such as: 
> http server, fastcgi ,scgi, etc'.
> As such, this patch provides an http server, fastcgi server and scgi server.
> 
> I have only tested the http server and scgi (using lighttpd) and they 
> seem to work fine.
> 
> You will need to install the following python modules (just use 
> easy_install):
> wsgiref - for the wsgi interface - it is already a part of the standard 
> python 2.5
> flup - implements scgi and fastcgi servers
> paste - for parsing the scgi environment
> 
> 
> -- 
> Ehud Shabtai
> http://www.freemap.co.il/map/ !DSPAM:1003,4589cbc3274141116498154!
> 
> 
> ------------------------------------------------------------------------
> 
> diff -Naur TileCache-1.3/Service.py TileCache/Service.py
> --- TileCache-1.3/Service.py	2006-12-21 00:29:55.000000000 +0200
> +++ TileCache/Service.py	2006-12-21 00:29:01.000000000 +0200
> @@ -407,6 +407,34 @@
>              "\n".join(traceback.format_tb(sys.exc_traceback))))
>      return apache.OK
>  
> +def wsgiHandler (environ, start_response, service):
> +    from paste.request import parse_formvars
> +    try:
> +        path_info = host = ""
> +
> +
> +        if "PATH_INFO" in environ: 
> +            path_info = environ["PATH_INFO"]
> +
> +        if "HTTP_X_FORWARDED_HOST" in environ:
> +            host      = "http://" + environ["HTTP_X_FORWARDED_HOST"]
> +        elif "HTTP_HOST" in environ:
> +            host      = "http://" + environ["HTTP_HOST"]
> +
> +        host += environ["SCRIPT_NAME"]
> +
> +	fields = parse_formvars(environ)
> +
> +        format, image = service.dispatchRequest( fields, path_info, host )
> +        start_response("200 OK", [('Content-Type',format)])
> +        return [image]
> +
> +    except Exception, E:
> +        start_response("200 OK", [('Content-Type','text/plain')])
> +        return ["An error occurred: %s\n%s\n" % (
> +            str(E), 
> +            "\n".join(traceback.format_tb(sys.exc_traceback)))]
> +
>  def cgiHandler (service):
>      try:
>          params = {}
> @@ -433,17 +461,24 @@
>              str(E), 
>              "\n".join(traceback.format_tb(sys.exc_traceback)))
>  
> -modPythonService = None
> +theService = None
>  
>  def handler (apacheReq):
> -    global modPythonService
> +    global theService
>      options = apacheReq.get_options()
>      cfgs    = cfgfiles
>      if options.has_key("TileCacheConfig"):
>          cfgs = (options["TileCacheConfig"],) + cfgs
> -    if not modPythonService:
> -        modPythonService = Service.load(*cfgs)
> -    return modPythonHandler(apacheReq, modPythonService)
> +    if not theService:
> +        theService = Service.load(*cfgs)
> +    return modPythonHandler(apacheReq, theService)
> +
> +def wsgiApp (environ, start_response):
> +    global theService
> +    cfgs    = cfgfiles
> +    if not theService:
> +        theService = Service.load(*cfgs)
> +    return wsgiHandler(environ, start_response, theService)
>  
>  if __name__ == '__main__':
>      svc = Service.load(*cfgfiles)
> diff -Naur TileCache-1.3/http_server.py TileCache/http_server.py
> --- TileCache-1.3/http_server.py	1970-01-01 02:00:00.000000000 +0200
> +++ TileCache/http_server.py	2006-12-21 00:02:22.000000000 +0200
> @@ -0,0 +1,9 @@
> +#!/usr/bin/python
> +from Service import wsgiApp
> +
> +if __name__ == '__main__':
> +    from wsgiref import simple_server
> +    print "Listening on port 8080"
> +    httpd = simple_server.WSGIServer(('',8080), simple_server.WSGIRequestHandler,)
> +    httpd.set_app(wsgiApp)
> +    httpd.serve_forever()
> diff -Naur TileCache-1.3/tilecache.fcgi TileCache/tilecache.fcgi
> --- TileCache-1.3/tilecache.fcgi	1970-01-01 02:00:00.000000000 +0200
> +++ TileCache/tilecache.fcgi	2006-12-21 00:12:02.000000000 +0200
> @@ -0,0 +1,6 @@
> +#!/usr/bin/python
> +from Service import wsgiApp
> +
> +if __name__ == '__main__':
> +    from flup.server.fcgi_fork  import WSGIServer
> +    WSGIServer(wsgiApp).run()
> diff -Naur TileCache-1.3/tilecache.scgi TileCache/tilecache.scgi
> --- TileCache-1.3/tilecache.scgi	1970-01-01 02:00:00.000000000 +0200
> +++ TileCache/tilecache.scgi	2006-12-21 00:22:26.000000000 +0200
> @@ -0,0 +1,6 @@
> +#!/usr/bin/python
> +from Service import wsgiApp
> +
> +if __name__ == '__main__':
> +    from flup.server.scgi import WSGIServer
> +    WSGIServer(application=wsgiApp).run()
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
> 
> 
> !DSPAM:1003,4589cbc3274141116498154!

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061220/f2f418e1/attachment.vcf 

From crschmidt at metacarta.com  Wed Dec 20 17:43:21 2006
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed, 20 Dec 2006 20:43:21 -0500
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
Message-ID: <20061221014321.GA12538@metacarta.com>

On Thu, Dec 21, 2006 at 12:47:58AM +0200, Ehud Shabtai wrote:
> Hi,
> 
> I'm using lighttpd as my http server so I needed a better handler for
> tilecache than CGI.
> I have implemented a WSGI handler which is a common api for implementing web
> services.
> There are different server implementation for WSGI handlers such as: http
> server, fastcgi ,scgi, etc'.
> As such, this patch provides an http server, fastcgi server and scgi server.
> 
> I have only tested the http server and scgi (using lighttpd) and they seem
> to work fine.
> 
> You will need to install the following python modules (just use
> easy_install):
> wsgiref - for the wsgi interface - it is already a part of the standard
> python 2.5
> flup - implements scgi and fastcgi servers
> paste - for parsing the scgi environment

Cool stuff. I'll pull this into the next release of TileCache (if you
approve) -- I don't know when that'll be out, but hopefully in the next
couple weeks.

Any caveats or things you're aware of not working?

Regards,
-- 
Christopher Schmidt
MetaCarta

From eshabtai at gmail.com  Thu Dec 21 00:23:25 2006
From: eshabtai at gmail.com (Ehud Shabtai)
Date: Thu, 21 Dec 2006 10:23:25 +0200
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <20061221014321.GA12538@metacarta.com>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
	<20061221014321.GA12538@metacarta.com>
Message-ID: <b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>

On 12/21/06, Christopher Schmidt <crschmidt at metacarta.com> wrote:

> Cool stuff. I'll pull this into the next release of TileCache (if you
> approve) -- I don't know when that'll be out, but hopefully in the next
> couple weeks.

That would be great.

> Any caveats or things you're aware of not working?

It seems to work fine. I mostly tested scgi using lighttpd and got to
the 300 req/s number you have talked about - though I've used a modest
Sempron CPU. I used ab2 for the tests.

The current implementation of the servers uses multi-threading. I have
not looked into tilecache to make sure it doesn't use any global
variables which might collide. I did follow the mod_python handler
implementation and I'm using one instance of: Service.load(*cfgs) for
all the threads. Is that ok?


-- 
Ehud Shabtai
http://www.freemap.co.il/map/

From schuyler at nocat.net  Thu Dec 21 00:25:52 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Thu, 21 Dec 2006 00:25:52 -0800
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
	<20061221014321.GA12538@metacarta.com>
	<b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>
Message-ID: <20061221082552.GC3092@vishnu.tridity.org>

* On 21-Dec-2006 at 12:23AM PST, Ehud Shabtai said:
> 
> The current implementation of the servers uses multi-threading. I
> have not looked into tilecache to make sure it doesn't use any
> global variables which might collide. I did follow the mod_python
> handler implementation and I'm using one instance of:
> Service.load(*cfgs) for all the threads. Is that ok?

That ought to be all right. Other than that, TileCache doesn't use any
global variables. It might be worth doing a quick audit to make sure
that the Cache classes are thread-safe. I think they ought to be, but
it can't hurt to check.

Thanks very much for your patch, Ehud! I love the work you've done on
freemap.co.il and I hope that TileCache will be of service to you.

SDE

From eshabtai at gmail.com  Thu Dec 21 01:32:19 2006
From: eshabtai at gmail.com (Ehud Shabtai)
Date: Thu, 21 Dec 2006 11:32:19 +0200
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <20061221082552.GC3092@vishnu.tridity.org>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
	<20061221014321.GA12538@metacarta.com>
	<b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>
	<20061221082552.GC3092@vishnu.tridity.org>
Message-ID: <b8dc1f520612210132ob8f45fbjb5ca4d411c7a724f@mail.gmail.com>

On 12/21/06, Schuyler Erle <schuyler at nocat.net> wrote:
> * On 21-Dec-2006 at 12:23AM PST, Ehud Shabtai said:
> >
> > The current implementation of the servers uses multi-threading.
>
> That ought to be all right. Other than that, TileCache doesn't use any
> global variables. It might be worth doing a quick audit to make sure
> that the Cache classes are thread-safe. I think they ought to be, but
> it can't hurt to check.

I'll take a look on it. A quick look shows that it currently uses file
locking to synchronize different processes of TileCache. I assume we
could implement a different locking mechanism which uses read/write
mutexes for multi-threaded servers. This should be more efficient than
file locking, but i wonder if it's worth the effort.

> Thanks very much for your patch, Ehud! I love the work you've done on
> freemap.co.il and I hope that TileCache will be of service to you.

Thanks a lot! I'm planning on using TileCache as my main tile engine
and everything would go through it.

-- 
Ehud Shabtai
http://www.freemap.co.il/map/

From crschmidt at crschmidt.net  Thu Dec 21 04:39:37 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Thu, 21 Dec 2006 07:39:37 -0500
Subject: [tiling] WSGI handler for tilecache
In-Reply-To: <b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>
References: <b8dc1f520612201447o765a15fai917d4ccc115d8ebe@mail.gmail.com>
	<20061221014321.GA12538@metacarta.com>
	<b8dc1f520612210023k42482c41x48091cb414f1193c@mail.gmail.com>
Message-ID: <20061221123936.GA7724@crschmidt.net>

On Thu, Dec 21, 2006 at 10:23:25AM +0200, Ehud Shabtai wrote:
> On 12/21/06, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> 
> > Cool stuff. I'll pull this into the next release of TileCache (if you
> > approve) -- I don't know when that'll be out, but hopefully in the next
> > couple weeks.
> 
> That would be great.
> 
> > Any caveats or things you're aware of not working?
> 
> It seems to work fine. I mostly tested scgi using lighttpd and got to
> the 300 req/s number you have talked about - though I've used a modest
> Sempron CPU. I used ab2 for the tests.
> 
> The current implementation of the servers uses multi-threading. I have
> not looked into tilecache to make sure it doesn't use any global
> variables which might collide. I did follow the mod_python handler
> implementation and I'm using one instance of: Service.load(*cfgs) for
> all the threads. Is that ok?

That fits with my expectation. The only probably I could think of would
be if somehow two requests tried to load the service object at the same
time -- but it shouldn't cause things to break, it'll just make those
first few requests a bit slower :)

We've had a couple of fastcgi requests, and I'm always happy to support
more different configurations, since I know that my way is not always
the best way :)  

Thanks again, and looking forward to pulling it in.

Regards,
-- 
Christopher Schmidt
Web Developer

From cholmes at openplans.org  Wed Dec 27 15:26:09 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Wed, 27 Dec 2006 18:26:09 -0500
Subject: [tiling] Changes In
In-Reply-To: <455E595B.6030203@jasonbirch.com>
References: <2CE73384-411A-44E8-AAE5-13E50660B801@refractions.net>	<455D38DA.5090504@jasonbirch.com>	<8777C6A0-0C84-4142-8163-DFF87798607B@refractions.net>
	<455E595B.6030203@jasonbirch.com>
Message-ID: <45930111.3050306@openplans.org>



Jason Birch wrote:
> Paul Ramsey wrote:
>> I already have the tiles, why would I want to regenerate them? :)
>> I'm trying to understand the use case. The suggestion sounds good  
>> from a "completeness" PoV, but there are lots of completeness things  
>> that have already gone over the side because they don't add value.
> 
> I was thinking more about being able to do something like GetFeatureInfo 
> rather than actually recreating the map... but I'm a bit fuzzy on 
> whether this is a real use case or a made-up one :)

Sorry, I'm painfully behind on this one.  But am cleaning out my unread 
email, and I think this would be a nice thing to have.  The use case for 
me would be for a client to know that two tile caches are exactly 
equivalent.  And indeed for others to be able to replicate a tilecache 
from a WMS server if the tilecache they're using goes down.

Say there's a WMS server with really nice global tiles, like OnEarth.  A 
bunch of different people are putting up their own tilecaches of it, for 
their user communities.  But if we don't have layer and style 
information, then users couldn't switch between the two transparently, 
and they wouldn't know if they could combine two different tilecaches in 
to one.

Indeed OpenLayers is already has a naive optimization that lets you draw 
tiles for the same map from more than one source.  If you don't have the 
style and layer information for the OnEarth layers they're sharing you 
won't know if they're actually equivalent.  And past speed, people may 
set up TMS for just their area of the earth, but a smart client could 
figure out that multiple TMS's were actually all the same dataset, and 
then combine them.


If these use cases are a bit too far off that's fine.  We could add the 
info when we actually get there.  I just see potential value in being 
able to know that tiles from two different TMS's are actually equivalent 
- since they're the same area and the same base WMS.

Chris

> 
> Jason
> 
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
> 
> !DSPAM:1003,455e59bd10581510810322!
> 

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061227/55a1b591/attachment.vcf 

From bob.basques at ci.stpaul.mn.us  Wed Dec 27 15:41:38 2006
From: bob.basques at ci.stpaul.mn.us (Bob Basques)
Date: Wed, 27 Dec 2006 17:41:38 -0600
Subject: [tiling] Changes In
In-Reply-To: <45930111.3050306@openplans.org>
References: <2CE73384-411A-44E8-AAE5-13E50660B801@refractions.net>	<455D38DA.5090504@jasonbirch.com>	<8777C6A0-0C84-4142-8163-DFF87798607B@refractions.net>	<455E595B.6030203@jasonbirch.com>
	<45930111.3050306@openplans.org>
Message-ID: <459304B2.8020605@ci.stpaul.mn.us>

Chris Holmes wrote:
>
>
> Jason Birch wrote:
>> Paul Ramsey wrote:
>>> I already have the tiles, why would I want to regenerate them? :)
>>> I'm trying to understand the use case. The suggestion sounds good  
>>> from a "completeness" PoV, but there are lots of completeness 
>>> things  that have already gone over the side because they don't add 
>>> value.
>>
>> I was thinking more about being able to do something like 
>> GetFeatureInfo rather than actually recreating the map... but I'm a 
>> bit fuzzy on whether this is a real use case or a made-up one :)
>
> Sorry, I'm painfully behind on this one.  But am cleaning out my 
> unread email, and I think this would be a nice thing to have.  The use 
> case for me would be for a client to know that two tile caches are 
> exactly equivalent.  And indeed for others to be able to replicate a 
> tilecache from a WMS server if the tilecache they're using goes down.
>
> Say there's a WMS server with really nice global tiles, like OnEarth.  
> A bunch of different people are putting up their own tilecaches of it, 
> for their user communities.  But if we don't have layer and style 
> information, then users couldn't switch between the two transparently, 
> and they wouldn't know if they could combine two different tilecaches 
> in to one.
>
> Indeed OpenLayers is already has a naive optimization that lets you 
> draw tiles for the same map from more than one source.  If you don't 
> have the style and layer information for the OnEarth layers they're 
> sharing you won't know if they're actually equivalent.  And past 
> speed, people may set up TMS for just their area of the earth, but a 
> smart client could figure out that multiple TMS's were actually all 
> the same dataset, and then combine them.
>
>
> If these use cases are a bit too far off that's fine.  We could add 
> the info when we actually get there.  I just see potential value in 
> being able to know that tiles from two different TMS's are actually 
> equivalent - since they're the same area and the same base WMS.
>
> Chris
>
I kinda like this idea too.  Sort of a dataset validator.   Could be 
some future uses for something like this I think.  Could check for 
disparate differences, like, resolution available, or Temporal stats, 
and/or both.

Multiple servers could be hit based on some basic settings, sort of a 
self feeding map viewer could be built with a fairly small list of 
available servers for an area.   Hmmm, very interesting, I still think 
that this should contain the Axis stuff too.(just to open that can of 
worms again, was that another list?? :c)

This could go in a few different directions over time too I think.

bobb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob.basques.vcf
Type: text/x-vcard
Size: 309 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061227/7a597015/attachment.vcf