[georss] [Context.RWG] Non compliant services in Context

[Josh@oklieb]

Hi,

There was a discussion on a tiling scheme and alternative request  
type for WMS at FOSS4G in Lausanne. The result was that Schuyler Erle  
took an action to write up the tiling scheme, its identifier scheme,  
and a parameter scheme for WMS GetMap requests. This scheme needs to  
specify the geographic extent, the identifier (X,Y values for each  
tile), and the zoom value for each level of the tile pyramid. It also  
needs to specify a standard image size for the tile (I believe  
200x200 pixels is the accepted value) and whether the coarsest tile  
covers the possible extent with one, two, or four tiles.

Another aspect of the tiling scheme would be the generation of lookup  
tables / registers which link each tile to its geographic bounding  
box in each CRS of interest (starting of course with EPSG:4326 /  
WGS84). This has the interesting side effect of defining valid  
extents for projected coordinate systems such as UTM  and State Plane.

Adopting this tiling scheme then allows the entire content of a WMS  
to be represented by limited number of exact URL's which are amenable  
to any number of caching schemes for performance and bandwidth / load  
management. It would also be expected that a WMS should properly  
support HTTP headers for expiry and refresh in order to properly  
update tiles when needed. It could be either an addition to the  
normal BBOX capability of a WMS, or an alternative profile which  
could be implemented even by a file system of image tiles (using URL- 
encoded parameters).

This may introduce another item for OWS Context, allowing not just  
the extent but also the presented tile array to be encoded.

I'll try to see where Schuyler is with this. It's also the next  
priority of the GeoRSS "Coalition of them with time on their hands"  
for geospatial ubiquity.

Josh

On Oct 18, 2006, at 11:57 AM, Carl Reed OGC Account wrote:

> Just to put my oar in the water, we asked why Google has not made  
> their WMS
> interface available in all their products - not just GE Enterprise.  
> Their
> response was that even they did not have enough cycles to process  
> hundreds
> of thousands of WMS requests on any given day. Part of the issue is  
> that as
> the user scrolls/zooms, an inordinate number of WMS requests get  
> generated
> for processing by the server. So, WMS is not visibly offered as  
> normal GE.
>
> Cheers
>
> Carl
>
>
>
> ----- Original Message -----
> From: "Martin Daly" <Martin.Daly at cadcorp.com>
> To: "Cameron Shorter" <cameron.shorter at gmail.com>
> Cc: "Jeff Yutzler" <jeff at ionicenterprise.com>;
> <context.rwg at opengeospatial.org>
> Sent: Wednesday, October 18, 2006 5:47 AM
> Subject: Re: [Context.RWG] Non compliant services in Context
>
>
>>> Martin Daly wrote:
>>>>> From Google's point of view:
>>>>> * Google have basemaps, can cache tiles of the world, but it is  
>>>>> not
>>>>> economical to rebuild a map with every query as is required by  
>>>>> WMS.
>>>>> Google needs a Tiled WMS, and so far there is no OGC spec
>>> for a tiled
>>>>> WMS, so they write their own.
>>>>
>>>>
>>>> On what grounds is it "not economical" for them to provide
>>> a normal WMS
>>>> on top of their tiled data?
>>>
>>> The CPU load to build a WMS map, or transform an image is
>>> significantly
>>> larger than if the image requests are known to be a set tile size  
>>> and
>>> zoomLevel.
>>
>> Agreed.  But that does not make it uneconomic, just more CPU  
>> intensive.
>>
>> Indeed, this is precisely how the NASA JPL OnEarth WMS works, and I'm
>> guessing that JPL has significantly fewer CPU cycles available than
>> Google, etc.
>>
>> M
>>
>>
>> _______________________________________________
>> Context.rwg mailing list
>> Context.rwg at opengeospatial.org
>> https://mail.opengeospatial.org/mailman/listinfo/context.rwg
>
> _______________________________________________
> Context.rwg mailing list
> Context.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/context.rwg