Talk:Tile Map Service Specification

Things To Discuss

• This specification is RESTful, but OGC specifications are not. Do we care?
• How much of the WMS capabilities metadata do we want to replicate? Some looks interesting, some not.
• Does the pre-amble need to be fluffed up a bit with some pictures and diagrams to explain some tiling basics to those not already acquainted (probably).
• On IRC, mloskot worries that the XML resources might be overly verbose for what they are transmitting. pramsey wonders if, since we have gone this far from the OGC mothership, jettisoning XML altogether for something like json might not be better. ianturton thinks that xml is easier to work with but maybe we can support both?
• The use of various elements needs description, in particular the <Origin> and <BoundingBox> which appear redundant. IanT changed the Origin of one of the examples to (-180,-90) from (-180,-180). The original origin (which makes no sense in lat/lon as spherical coords, but is acceptable if you are pretending they are cartesian, as mapping apps do) was placed there to allow for 2x2 256x256 tiles to fit into the plane at the top zoom level. Another equally acceptable layout though, is to have IanT's origin and use 2x1 256x256 tiles. I cannot recall why the BoF didn't like that as much as having a square initial extent.
• I can sort of see the basis for this, but it looks like I have to download twice as many tiles as I need when I veiw the whole world which is likely to be the most common view requested. IanT
• Only at very zoomed out views, so it's not that big an imposition. At zoomed in views, presumably you are more interested in looking at actual data than the blank spaces between the Origin and the BoundingBox. PaulR
• What about 304 (unmodified) should be documented? the whole request/response thing is a little complex, and it's not an errorcode per se... PaulR