FOSS4G 2006 Tiling BOF
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.
Summary
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
(and about 20-25 others who showed up later)
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
Luis Seville: 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
END OF SESSION