[OSGeo-Standards] OWS Context and others OGC interactions

Jody Garnett jgarnett at refractions.net
Mon Oct 22 19:01:54 EDT 2007


Hi Lorenzo; just want to make sure I understand the goal here ... if I 
understand the goal here is how to add more stuff (specifically support 
for additional protocols) to these documents?

One thing I liked about a lot of the OGC specs is their respect for 
"vendor specific extentions"; the idea is to create a schema with a well 
known place for people to dump in additional content; after a while (if 
the need is common enough) you can promote the solution to a first class 
element in your schema.

You list a couple of options:
- mess with additional mime types (credit Jeroen ); am I to assume that 
these would be mime types for the <Layer> element?
- create more types of content

It would be more in the spirit of the document to create additional 
kinds of contents; for some types of content (A google layer) enough web 
applications have the need that you can probably bang up something now. 
The advantage is you do not have to worry about tripping over the "rest" 
of the WMS specific stuff like named style that would otherwise conflict 
with a google satellite backdrop.
> <Extension queryable="0" hidden="0" group="Layers">
>    <ows:Title>Background</ows:Title>
>    ....
>    <Server service="google" version="2.0" title="Google Maps">
>        <OnlineResource xlink:type="simple" 
> xlink:href="http://maps.google.com/api/"/>
>     </Server>
>    <sld:MinScaleDenominator>5000</sld:MinScaleDenominator>
>    <sld:MaxScaleDenominator>50000</sld:MaxScaleDenominator>
>    <StyleList>
>     <Style current="1">
>        <Name>default</Name>
>        <Title>satellite</Title>
>       </Style>
>    </StyleList>
> </Extension>
The advantage of the version is to let applications know what version of 
the API the context document was prepared against; etc... For us poor 
desktop applications we can try stubbing in appropriate content if we 
can recognize what content is being served up.

Cheers,
Jody


Lorenzo Becchi wrote:
> I've never seen the OWS Context draft before Cameron Shorter's post 
> sent yesterday... now I'm surprised to see "FeatureType" or "Coverage" 
> inside the ResourceList, but it seems a good way to offer a better 
> service.
>
> A possible problem of OGC standards is that they relate normally to 
> OGC standards. That's ok to me, I'm getting older.  But think about 
> what Chris Schmidt (OL Core Developer) always says about standards: "I 
> don't need standards". That's because he's always a step forward in 
> the future.
And when you want to communicate between a couple of applications we 
will at least need a a small S "standard" (wiki page fine). We can leave 
a captial "S" Standard up to people in the past ;-)
> Jeroen Ticheler's idea, he's GN director,  was to include mime-types 
> in the type definition of a layer or its server,
> ex:
> <URI mimetype="application/vnd.ogc.wms" title="National boundaries of 
> Africa" 
> name="national_boundaries_africa">http://geonetwork3.fao.org/ows/1</URI>
>
> let's try to be creative:
> <URI mimetype="application/google.satellite" title="Google Satellite 
> Images from Google Maps" 
> name="satellite">http://maps.google.com/api/</URI>
>
> some more creativity:
> <URI mimetype="application/osm.streets" title="Open Street Maps - 
> Streets" name="street">http://www.osm.org/api/5.0/</URI>
> we could use this solution instead of FeatureType and Coverage or 
> joint with them.
> Adopting mime type, the client application will be able to decide to 
> use or not a kind of service (layer) if it has an interface to support 
> it. Otherwise it will be able to throw it away or return an exception.
> Every client will be free to support standards layers but add as many 
> new features as Chris Schmidt can invent in one month (means many).
> Ex: OpenLayers and Mapbuilder can easily support GoogleMaps today, why 
> we should avoid uDIG to support it tomorrow? Maybe Google has a clear 
> answer about it... Anyway, same thing about OSM but OSM has already a 
> public API; why should we not make it an OGC indexable resource?
>
>
> ciao
> Lorenzo
>
>
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards



More information about the Standards mailing list