FOSS4G 2006 Tiling BOF

Summary

The map tiling Bird of a Feather (BOF) session at FOSS4G 2006 met from 1730 - 1930 on Tue 12 Sep 2006, with the intention of elaborating a way of being able to efficiently tile and cache map images on the web for use in dynamic clients.

ChristopherSchmidt has written up a summary of the Tiling BOF on the EOGEO tiling list. If you want to find out what we all discussed and agreed on at the BOF, read that summary. The rest of this page is a ridiculous pseudo-transcript with more detail than anyone probably wants.

In the aftermath of the BOF, several of us agreed that we should additionally write up a "Web Tile Service" or GetTile specification in addition (and based on the work of) the WMS compatibility recommendation discussed at the BOF.

Attendees

Some of the attendees are missing surnames or are absent completely. If you were there but not here, please add yourself!

Steven Ottens Lorenzo Becchi Andrew Turner Paul Spencer Justin ? Just van den Broecke Mike Adair Paul Ramsey (voice of reason) Andrea Aime Brent Owens Steve Lime Chris Holmes Allan Doyle Thaijs ? Christopher Schmidt Schuyler Erle

Rough Transcript

The following are SchuylerErle's rough notes on the discussion. People are probably misquoted or misattributed. Please take this as a guide only (or fix it, if you were there and remember differently). ;-)

Allan: WMS profile. "You have to give something up." Backwards compatibility. * Canonical parameter ordering, use to fill up Squid caches. only need to recognize bad requests.

Paul S.: Getting a map is getting from getting a tile that's part of a map, the server has different expectations of behaviors at map/tile edges (labels, line ends). Shouldn't use GetMap; use GetTile instead.

Allan: use vendor specific param "tiling=true"

Paul S.: Squid works great for raster imagery. How to expire stuff from it dynamically? Use vendor specific "tile_version"?

Allan: How about an out of band "ExpireTile" WMS request?

Paul R.: Corner issues with floating point numbers dictate rules for rounding.

Paul S.: We should have a standard projection and coordinate system and extents; put other projections in other profiles. One standard is Google Mercator (whole world fits on one 256x256), the other is EPSG 4326 (two tiles at zoom 0).

crschmidt: Mercator = EPSG 41001

Paul S.: Leaning on an undersupported EPSG doesn't support backwards compatibility

Allan/cholmes: Every compliant server will have to support EPSG 4326 for universal compatibility

Paul S.: The advantage comes from combining tiles from multiple servers

Paul R.: That just leaves cutting the thing up into pieces... How many tiles do we start with and how do we split them up after that? How do we get them to line up?

Steven: They don't have to line up in the client, the client can line them up.

Paul S.: We just have to choose a standard origin. In ka-Map we use 0,0 in the projection becomes 0,0 in the tile grid.

Paul R.: That just leaves scale. In 4326 we start at the top because we know the max extents.

Paul S.: The other option is to start with a scale of 1:1 and double it, rather than trying to start at the top.

Andrea: In Italy if we don't support the list scales, hmm

crschmidt: why don't we support a list of scales?

sderle: other profiles will have to do that... but we should define a core profile that specifies something that everyone will have to support. if they wan to support other profiles as well, they can advertise that.

crschmidt: we need a standard way of publishing that metadata for profiles. if you have those parameters is calculate how to use the tiles.

Allan: which is an opportunity for new bugs. sderle: essentially we are trying to do two things, one a subset of the other: define all the metadata needed to use a tile server, and define a single consistent global profile with default values for each. we should do both.

Paul S.: caching is not really a requirement for this spec, then, so much as

• cacheability*.

Josh: No fixed param ordering. Breaks HTTP.

Paul S.: what about rendering multiple layers into a single tile set?

Paul R.: Doesn't the WMS layer group support that?

allan: it's not part of the spec, but the spec supports thinking of things that way.

Josh: because layers can be grouped under a single name, the spec should require only a single name in the layer parameter.

Josh Lieberman: You want a flag that specifies "base layer" versus "overlay"...

sderle: is it the privilege to throw a standard exception if it receives a request that doesn't match its advertised profiles?

cholmes/Paul S.: Yes.

crschmidt: But it should be okay for a WMS to return an image that doesn't

allan: or just return a standard HTTP error

Raj: it might be better to always return an image

Joshua: The "tiled" GetCapabilities should be "doesn't support"/"supports both"/"only supports tiling"

Paul R.: if it's tiled only, you may have no choice about what you return, so you get what the web server returns (a 404)

crschmidt: you can return an image as the content of the HTTP error

Josh: say "should but doesn't have to"

Paul S.: in that case the browser will resize it... so the error image size doesn't matter

Paul S.: what about the canonical image format?

Allan / Raj: PNG

Paul R.: actually so long as the server is consistent it doesn't matter

Steven: for profile #0, use PNG, but it should be part of the profile definition

Paul R.: the server has to pick one

cholmes: I don't want to have to change my GetCapabilities to pick just one

Allan: the cache should live in a different URL and have its own GetCapabilities

cholmes: but what we're trying to do is limit the client, not the server

Steve Lime: if you don't want to change your server, you're going to have to cache every format it spits out... or limit that at the cache

Paul R.: the global profile is about interoperability... they need to agree on lots of things, but image file formats is not one of them

generally: format is *not* specified

Paul S.: what about a standard "dots per inch"?

Paul R.: i.e. what does the list of scales mean? if those values are cartographic scale, you need to specify a formula to calculate it

Allan: I don't care what we do, but don't use the word "scale"... doesn't mean anything any more

crschmidt: OpenLayers has always used "resolution" i.e. map units per pixel

Allan / Paul S.: we should use that

Allan: how do we deal with other vendor specific parameters? just throw them out?

Paul S.: is there going to be tiling information in GetCapabilities? want to see supports tiling=true. can we add fixed vendor specific parameters there?

Jody Garnett: just put it in the OnlineResource response for GetMap

sderle: should also allow WMS to say "my tiled version is over here"

Paul S.: the tiling profile needs to be able to say in GetCapabilities: here's my magic string -- my list of additional vendor parameters

Jody: and it needs to be called "magic string" also

(spanish guy): GetTile returns tile (X, Y, L)

crschmidt: that needs to be a different spec... everything goes through GetMap

Jody: for version 2, we'll add a GetTile

Josh/Allan: actually a WTS

Paul S.: default tile size should be 256x256

crschmidt: so the maximum resolution per tile is 1.46025

sderle: and zoom level 0 is the whole world

crschmidt: we don't want to render things outside the world, so we need two tiles at the top level... factor of two zooms okay?

Paul S.: Makes the most sense

Steven: How many zoom levels are we going to get?

Paul S.: Theoretically it's infinite... list it in the GetCapabilities

crschmidt: how many are going to be in that list?

Allan/Paul S.: one. or more.

generally: Creative Commons ShareAlike license

Paul S., Paul R., Raj and Schuyler volunteer to sketch out spec by Sep 29

Paul S.: and let's code an implementation ASAP

Jody: or two