[tiling] Tiling BOF at FOSS4G

[Christopher Schmidt]

Earlier this evening (or, in Swiss time, yesterday evening, since it's
now 2:35AM), there was a BOF for discussing WMS tiling, as previously
discussed on the OSGeo wiki, at
http://wiki.osgeo.org/index.php/WMS_Tile_Caching .

Participants represented all walks of the tiling rainbow, and the
discussion was lively and interesting and largely productive.

Schuyler has much more detailed notes that he plans to type up, but
since the affect of jet lag on me is apparently to become unable to
sleep for more than 4 hours a night, I'm going to type up a few notes
now:

Decisions:
 * The discussion began on the principle that the tiling requests should
   be built on top of WMS -- in other words, a compliant tile request
   is a GetMap request, for backwards compatibility reasons.
 * Metadata for WMS-C will be stored as additional WMS metadata,
   availble via getcapabilities requests. 
 * A number of parameters are required to define the caching scheme in
   use by the server serving the tiles. 
    * Geographic origin of tiles
    * A set of resolutions for which tiles are available
      Resolution is defined as the number of map units per pixel.
    * Tile Size
    * Layer name
    * Projection
    * Format
   Some of these are contrary to the earlier definition on the OSGeo
   wiki: specifically, scale is no longer used, and scale no longer must
   be defined as a specific 'top level', and a factor from there. The
   primary complaint against this comes from cartogrpahers, who
   explained that each country has 'default' scales which are in use.
   (Think 1:24K USGS quads in the US.) Preventing the tiling scheme from
   being able to descirbe these tiles would have been a mistake.
 * However, although it is possible to define these in any way,
   depending on the needs of your client, there will be established a
   set of 'default' parameters which create the first WMS-C profile. The
   exact values of these parameters was a topic of discussion -- agreed
   at the meeting was:
    * Tile Size of 256x256
    * Projection of EPSG:4326
    * Resolutions must contain 1.40625 as top, and must contain at least
      one resolution: resolutions below 1.40625 should be divisors of 2
      of this value.
   Not decided when we ran out of time were:
    * Geographic origin of tiles (but I think we were close to
      '-180,-90' as a decision.)

   The idea here is that if you want your tiles to be used alongside
   other map tiles, the easiest way to do it is to support these
   properties. I feel like there was something else we hadn't yet
   finished discussing, but I don't remember what.
 * Layer name for tiled requests must be a *single layer* -- grouping
   should be done by the provider, or the provider can provide multiple
   caches for different layers if they are prepared to suffer the
   caching properties from having clients request them all.

Possible ideas brought up:   
 * Handling errors. Because tiles are specified requests, it should be
   possible to create a static, non-WMS backed tile server
   (pre-generating the tiles and load balancing over lightweight
   servers). This brought up the case of error handling: an idea was
   suggested to use standard HTTP error codes, but also to encourage the
   content of the 404 to be an image with text in it, to mimic the
   inimage exception (supported by Mapserver at least)
 * Support for 3 different modes (stated somewhere in metadata): "No
   tiling" ( default WMS), "Some tiling" (I serve tiles, but will also
   serve other WMS requests) or "only tiling" (I don't support your
   silly non-tiled matching requests), which is useful for static
   servers.
 
Not yet tackled, but needs to be:
 * Rounding. In order to support the same boxes, a standard for how to
   round bbox requests should be established.

Postponed:

 * Implementation of changes in clients in order to better support
   cachability was put aside for the time being. Although setting up a
   tiling specification does *allow* easier cachability, it doesn't
   depend on it. 
 * Implementation of a "GetTile" request, which requests tiles based on
   a grid with a 'zoom level', was postponed.

Future plans: 
 * Several volunteers (Schuyler Erle, Paul Spencer, Paul Ramsey) offered 
   to help write the prose version of the spec -- I'm hoping some of
   what I typed out will help.
 * The plan is to have a draft implementation prepared in time for the
   next OGC meeting, October 2nd.
 * Hopefully, it will be possible to demonstrate an implementation of
   the tiling schema by that time. 

Possibilities once tiling spec is complete:
 * Create generally useful datasets with fully cached fast served
   tiles. (VMap0, TIGER, etc.) These can then be used by most clients,
   saving the need for repition of effort in generating these tiles
 * (Personal, not brought up at meeting) Tiled WMS directory listing. 
   This is a bit similar to the geodata committee catalog idea brought
   up for OSGeo... only simpler, since you need only provide a single
   WMS URL in order to add it to the catalog

Testing tools:
 * There should be a testing tool which allows you to enter a set of
   caching params, and choose a grid ref (0,0, 0,1, etc.) and a zoom
   level, and have the bbox be generated -- clients can then test
   conformance against this URL. 
 * Server implementations are laregely already complete in the form of
   WMS.

General Info: 
 * Attendence at the BOF was high, around 40-50 people in total. 
 * Developers of Ka-Map, MapBuilder and OpenLayers were in attendance
   (and I feel like I'm missing some other tiling mapping client
   somewhere, but I don't know.)
 * Developers of MapServer and GeoServer.
 * Many many other developers, interested parties, contributors, etc.

All in all, it was far more productive and enjoyable than I expected it
ot be. It was good to see everyone in one room and discussing things
rationally :) 

Many thanks to all participants. Looking forward to seeing work continue
in this thread.

Regards,   
-- 
Christopher Schmidt
Web Developer