Difference between revisions of "Talk:Tile Map Service Specification"

From OSGeo
Jump to navigation Jump to search
(proposal to talk to OGC what they think about it)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
===Things To Discuss===
 
===Things To Discuss===
 +
 +
* Shouldn't this wiki page describe exactly how to get to the metadata of a given TMS?
 +
The examples currently describe:
 +
 +
'''Root Resource'''
 +
<pre>http://tms.osgeo.org/</pre>
 +
should we assume we got this URL from some other source, possibly a CSW? Could the Url just as well be something like <pre>"http://mytms.mydomain.tld/myservices/mytms/</pre> ?
 +
 +
Then
 +
<pre>http://www.osgeo.org/services/root.xml</pre>
 +
Where does the "/services/root.xml" part come from? Just append it to the root resource? If known, please describe.
 +
 +
Then the <TileMapService> resource:
 +
<pre>http://tms.osgeo.org/1.0.0/</pre>
 +
Where does this come from? Did we get this URL from the response to the Root Resource URL above?
 +
 +
Then
 +
<pre>http://www.osgeo.org/services/tilemapservice.xml</pre>
 +
Where does the "/services/tilemapservice.xml" part come from? Just append it to the root resource? If known, please describe.
 +
 +
Same questions for
 +
<pre>/vmap0</pre>, <pre>/1.0.0/landsat2000</pre>, <pre>/basemap.xml</pre> ?
 +
 +
Wouldn't it be nice if this Wiki page would use an internally consistent set of TMS metadata? If not, why bother storing metadata with the TMS at all? Please delete and forgive my ignorance if this comment should completely miss the point of this Wiki page.
  
 
* This specification is RESTful, but OGC specifications are not. Do we care?
 
* This specification is RESTful, but OGC specifications are not. Do we care?
Line 10: Line 34:
 
* 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
 
* 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
 
* 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
 +
* (user mmanzato) Several applications I am currently considering focus on a regional or urban context outside of which there is no cartographic coverage. Here UTM projection (or other local projections) are much more useful/meaningful than global-geodetic or global-mercator.
 +
** I understand that the "local" profile is there exactly for this purpose. Correct?
 +
** Bulletpoint 2  in local profile definition should read: "Must provide <TileSet>s with units-per-pixel meeting the following formula: units-per-pixel = 2^n, for '''some''' integral value of n greater than or equal to 0" (it is not necessary to provide all resolutions!)
 +
** Given what third bulletpoint says I would expect that tiles with units-per-pixel=2^n are in <ProfileUrl>/n, so:
 +
<pre><code>
 +
  <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/11" units-per-pixel="2048" order="0" />
 +
  <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/10" units-per-pixel="1024" order="1" />
 +
  <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/9" units-per-pixel="512" order="2" />
 +
  ...
 +
</code></pre>

Latest revision as of 02:04, 8 March 2010

Things To Discuss

  • Shouldn't this wiki page describe exactly how to get to the metadata of a given TMS?

The examples currently describe:

Root Resource 

http://tms.osgeo.org/

should we assume we got this URL from some other source, possibly a CSW? Could the Url just as well be something like 

"http://mytms.mydomain.tld/myservices/mytms/

 ?

Then 

http://www.osgeo.org/services/root.xml

Where does the "/services/root.xml" part come from? Just append it to the root resource? If known, please describe.

Then the <TileMapService> resource: 

http://tms.osgeo.org/1.0.0/

Where does this come from? Did we get this URL from the response to the Root Resource URL above?

Then 

http://www.osgeo.org/services/tilemapservice.xml

Where does the "/services/tilemapservice.xml" part come from? Just append it to the root resource? If known, please describe.

Same questions for 

/vmap0

, 

/1.0.0/landsat2000

, 

/basemap.xml

 ?

Wouldn't it be nice if this Wiki page would use an internally consistent set of TMS metadata? If not, why bother storing metadata with the TMS at all? Please delete and forgive my ignorance if this comment should completely miss the point of this Wiki page.

  • This specification is RESTful, but OGC specifications are not. Do we care?
    • We could ask OGC. There is a meeting in December, maybe some OSGeo folk is there to ask it ([[User:Arnulf Christl | Arnulf] is there).
  • 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
  • (user mmanzato) Several applications I am currently considering focus on a regional or urban context outside of which there is no cartographic coverage. Here UTM projection (or other local projections) are much more useful/meaningful than global-geodetic or global-mercator.
    • I understand that the "local" profile is there exactly for this purpose. Correct?
    • Bulletpoint 2 in local profile definition should read: "Must provide <TileSet>s with units-per-pixel meeting the following formula: units-per-pixel = 2^n, for some integral value of n greater than or equal to 0" (it is not necessary to provide all resolutions!)
    • Given what third bulletpoint says I would expect that tiles with units-per-pixel=2^n are in <ProfileUrl>/n, so:
<code>
   <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/11" units-per-pixel="2048" order="0" />
   <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/10" units-per-pixel="1024" order="1" />
   <TileSet href="http://tms.osgeo.org/1.0.0/landsat2000/9" units-per-pixel="512" order="2" />
   ...
</code>
Retrieved from "http://wiki.osgeo.org/w/index.php?title=Talk:Tile_Map_Service_Specification&oldid=45995"