[OSGeo-Standards] Re: [tiling] OGC Tiled WMS Discussion Paper

Thu Sep 13 21:05:01 EDT 2007

Martin Vivian from Lisasoft had the following comments to make regarding 
the OGC Tiled WMS discussion paper. His comments refer to specific 
paragraphs in the document. My appologies to those who don't have access 
to this document yet.

Martin  has been writing a java version of Tile Cache which to date has 
been based upon the python TileCache developed by Chris Schmidt and 
others at Metacarta.
Our hope is that Lisasoft's JTileCache will eventually be merged into 
the Geoserver or Geotools codebase.

Martin Vivian wrote:

I've written my spew, have a read. I'd like some of my questions 
answered by cubewerx and the like but I believe were not really to 
discuss this in full yet...

On Thu, 6 Sep 2007 09:30:31 am you wrote:

>  Have either of you read the Cubewerx draft spec?

>  I'd like to get an overview of our opinion.

I have read and agree mostly with all of the ideas in the discussion paper

My main issues concern "Annex B: Discussion of alternatives". Pages 20 - 22

Some of these alternatives I happen to agree with.

1 Overloading the GetMap operation

I agree with the discussion paper. Keep em separate

2 Allowing background color and/or transparency

I agree that this is very trivial for a client to achieve. But I dot not 
believe that including it in the specification will make the application 
unscalable. The service need only do what clients would do, use a solid 
background and paste the tile on top. I can see that a tile map server 
be able to pipe the image file directly to the user if it didn't have to 
manipulate the image,but this could simply be optimised to do so if the 
transparency property is set to true. But I really don't see it as such 
a big deal, so that's all I'll say.

3 Reporting the background colors in the DescribeTiles response

I mostly agree that this information is useless. What I do believe to be 
more useful is that the DescribeTiles response indicate if the tile have 
transparency or i they were rendered with a background colour. That way 
they will know if they can overlay those tiles on others, effectively 
distinguishing base layers from others.

4 Allowing more than one layer to be requested

Same argument as number 2 essentially. But I agree more with the paper 
on this one. If you got the server to do this it would be faster for the 
client as the operation is done close to the source, and this is the 
name of the game. However it could get ridiculous if tonnes of layers 
are requested, so there needs to be a limit and a limit of one is as 
good as any. If the client wants more data in less requests the two 
layers should be merged into a new tile layer.

5 Specifying pixel sizes rather than scales

I have to say I completely disagree with the paper on this one. I think 
the use of scales is a bad idea. I will discuss each of the papers 
objections one at a time

5.1

"If pixel sizes were used instead, a set of recommended scales would 
have to be defined for each coordinate system". This being due to scales 
being independent of the projections units.

Its only a "recommend" set any way. Every client is going to need to 
find out from a capabilities which "zoom levels" are supported any way. 
Recommended scales mean nothing to clients and therefore to the service 
and therefore to the specification.

Not only that, there is going to be one (maybe two) recommended 
projection for all WMST's so why do you need more than one recommended 
set of recommended resolutions

5.2

"...using scales is ... already in common use in the WMS and SLD 
specifications"

Every other specification deals with raw data as apposed to images. 
Resolution far better represents the image than scale. SLD's will have 
no purpose with tiles. You cant style a tile, and if you could, you 
wouldn't, because of the scalability issues already raised.

5.3

"It is the industry-standard way of specifying the size of a map 
relative to the size of the area it represents"

But its terrible at doing so! The scale of an image is not consistent 
across the whole picture, such as where poles are stretched and where 
curved projections meet the edge of the viewable earth.

There "seems" (from my limited experience) to be no standard way of 
calculating it. Sure the pixel size is 0.28mm but calculating a scale 
requires calculating a size measurement (in meters) of the represented 
area. Such calculations are very ambiguous, also requiring complex 
trignomometric functions and will cause inaccurate scales and thus lead 
to services having to tolerate some inaccuracy. There is absolutly no 
inaccurate way of calculating Resolution. Resolutions are not 'very 
accurate', they are absolutly precise.

5.4

"The conversion between scale and pixel size for a particular coordinate 
system is trivial so the complexity of the calculations involved it not 
an issue either way."

As per the same reasons in 5.3 I completly disagree in its triviality. 
Specifically, how do you deal with calculating scale for a flat 
representation of the earth where one tile (say on the equator) is going 
to not be at the same scale as another tile (say at a pole). What about 
pseudo 3d projections (even though I can't see how you could tile a 
non-2d projection).

Sophia Parafina wrote:
> I heard back from Carl Reed and he says that it will be available after
> the Technical Committee meeting on Sept. 20th.
>
> sophia
>
> Edric Keighan wrote:
>> Keith,
>>
>> FYI ...
>>
>> How our proposal fits with OpenLayers recommendations referenced at 
>> the following site: 
>> http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
>>
>> Regards,
>>
>> Edric
>>
>> Sophia Parafina wrote:
>>> I've asked Carl Reed at OGC to make it available for comment.
>>>
>>> sophia
>>>
>>> Christopher Schmidt wrote:
>>>> On Fri, Sep 07, 2007 at 10:47:27AM -0400, Frank Warmerdam wrote:
>>>>  
>>>>> Folks,
>>>>>
>>>>> I was contacted by Edric Keighan about a discussion paper that was
>>>>> recently submitted to OGC (with Cubewerx as the editor) titled:
>>>>>
>>>>>    07-057r2 OpenGIS Tiled WMS Discussion Paper
>>>>>     
>>>>
>>>> I'm guessing this would be a continuation of OGC 07-057? The 
>>>> editors of
>>>> that were not Cubewerx, but from uab.cat, if my records serve. I'd be
>>>> interested in seeing either of the two documents, and would ask that 
>>>>> I believe it is roughly comparible in goals to this work:
>>>>>
>>>>>    http://wiki.osgeo.org/index.php/WMS_Tile_Caching
>>>>>
>>>>> I believe Edric is interested in feedback on the paper and support 
>>>>> for the
>>>>> proposal (for those of us who are OGC members) and perhaps more 
>>>>> importantly
>>>>> he is interested in implementations of the specification within 
>>>>> our projects
>>>>> with OpenLayers being the most obvious candidate.
>>>>>     
>>>>
>>>> OpenLayers is unlikely to add support for further tiled WMS
>>>> specifications through the work of its current set of developers.
>>>> Additional layers would need to be created, tested, and supported by
>>>> some other person who would accept 'ownership' of the layer type: I've
>>>> already avoided including some functionality in OpenLayers simply
>>>> because no one was willing to take on the task of supporting it.
>>>> If some person or organization is willing to take on the task of
>>>> supporting a layer, then in general, OpenLayers is open to the task of
>>>> adding that functionality. However, I'm somewhat hesitant to include
>>>> yet-another way of accessing pre-cached WMS information: especially if
>>>> it has not taken into account the design goals of the 
>>>> Recommendation we
>>>> created at the last FOSS4G, which is described at:
>>>>
>>>>   http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
>>>>
>>>> An example of things we explicitly discussed and discarded:  * 
>>>> GetTile requests -- we wanted to stick with GetMap, and simply allow
>>>>    for matching the map request to a tile when appropriate.
>>>>  * Using anything other than the standard GetCapabilities for 
>>>> describing    functionality: GetCapabilities allows for vendor 
>>>> extensions, and this
>>>>    seemed the right way to pass the information back to the client
>>>>  * Starting the tiles at the '0,0' point of the world  (Instead 
>>>> choosing    to go for the lower left corner). Note that this is 
>>>> different from
>>>>    Google's tiles, but the same as WorldWind's.  * Creating any new 
>>>> form of requests -- it's easiest for client
>>>>    functionality to simply extend the existing requests rather than
>>>>    creating new formats.
>>>> Again, I don't know what's in the document: if someone could tell me
>>>> more specifically how to get a copy of it, I could offer a more formal
>>>> review from the point of view of an implementor of a tile map server.
>>>>
>>>> Thanks for the heads up, Frank.
>>>> Regards,
>>>>   
>>>
>>
>
>
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards
>

-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254