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

[Kralidis,Tom [Burlington]]

All,

Good discussion.

For me, I strongly prefer to stay away from non-OGC specifications in an
OGC specification.  If we are chasing the new
defacto/cool-web-mapping-api all the time, something like OWS Context
will become so bloated that we may be revisiting years after in a
"refactoring" effort to make things more unified.

Isn't this what OGC:WMS 1.0.0 did back in 1999 to provide a standard API
to visualize webmaps?

I am not discounting the value of defacto APIs out there, which have
proven useful to the community.

This is precisely why, in OWS Context 0.0.13, we defined Extension
elements in both the Global area and the AbstractResourceType (Extension
provides xs:any capability).

..Tom


> -----Original Message-----
> From: 
> context.rwg-bounces+tom.kralidis=ec.gc.ca at opengeospatial.org 
> [mailto:context.rwg-bounces+tom.kralidis=ec.gc.ca at opengeospati
> al.org] On Behalf Of Josh at oklieb
> Sent: 18 October, 2006 12:16 PM
> To: Carl Reed OGC Account
> Cc: georss at lists.eogeo.org; Jeff Yutzler; 
> context.rwg at opengeospatial.org; George Percivall; Martin Daly
> Subject: Re: [Context.RWG] Non compliant services in Context
> 
> 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
> 
> _______________________________________________
> Context.rwg mailing list
> Context.rwg at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/context.rwg
>