[OSGeo-Standards] OWS Context and others OGC interactions

[Allan Doyle]

On Oct 21, 2007, at 11:51 , Lorenzo Becchi wrote:

>
> Hi All,
> first of all I should apologize for my poor knowledge of OGC  
> standards.
> To be honest, I'm not sure that what I'm writing make totally  
> sense. But hope it does.
>
>
> In a recent debate bewteen OpenLayers (OL) and GeoNetwork (GN)  
> communities we have tried to face a practical scenario using OGC  
> standards.
>
> Playing with OL and GN, I've decided to create a CSW search  
> interface for OL to retrieve WMS or other kind of layers from a GN  
> Catalogue.
> That's all Javascript from OL client side while it's all XML what  
> I'm expecting from GN Catalogue (JSON output would be a dream).
> So I can receive a list of layers, with different flavored XML, and  
> even a OWS Context.
>
> 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.
>
> 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>
>

If you're thinking about WMS layers, there's the WMS Context, which  
is different from the OWS Context. Community MapBuilder uses WMS  
Context in a fairly interesting way.

>
> 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).

The problem with MIME types is that there's a bit of a lag in getting  
them defined and widely known. Furthermore, there's probably a bit of  
a specificity vs. generality tradeoff that has to be dealt with. Once  
you move away from the image types supported by WMS to vector types  
supported by OL, you can easily get hung up on whether you want to  
have named types for classes of things like Shapefiles, GeoJSON, etc,  
or whether you want to have named types for "Fred's GML profile for  
rollerblading trails". GML, in particular can lead you to an issue of  
typing, because "Pure GML" is not really what things get expressed  
in. GML data should always be expressed in an application schema, and  
if anyone ever figures out how to make those easy to define, they  
will proliferate like crazy.

> 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?

Google's answer is KML. KML could probably form the basis for a  
general context document. Maybe not totally general, but pretty general.

	Allan

-- 
Allan Doyle
Director of Technology
MIT Museum
+1.617.452.2111




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/standards/attachments/20071021/5ec46559/attachment.html