Difference between revisions of "Talk:Tile Map Service Specification"
Jump to navigation
Jump to search
(added more discussion to origin) |
|||
| Line 6: | Line 6: | ||
* 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? | * 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. | * 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 | ||
Revision as of 07:57, 27 October 2006
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