[OSGeo-Standards] Re: How to extend OWS Context forseveralspecific cases

[Kralidis,Tom [Burlington]]

Hi,

I've uploaded a version 0.2.1 of OWS Context to:

http://www.ogcnetwork.net/schemas/owc/0.2.1/owsContext.xsd

Changes:

- allows for an extension within owc:ResourceListType
- adds @id to owc:AbstractResourceType
- add sld:MinScaleDenominator and sld:MaxScaleDenominator to
ows:GeneralType
- adds owc:MaxFeatures to owc:FeatureTypeType
- adds multiplicity to owc:ServerType, and @default to deal with
associations within an owc:AbstractResourceType

If I were to analogize this with a, say, MapServer mapfile, the OWS
Context as is would be to define remote data connections.  For local
data connections, this is where I think the community-based extension
definition would be handy:

<owc:Extension>
 <osgeo:LocalLayer>
   <osgeo:Name>foo</osgeo:Name>
   <osgeo:Data>/path/to/data.shp</osgeo:Data>
   <osgeo:Type>gml:Polygon</osgeo:Type>
   <osgeo:CRS>init=epsg:4326</osgeo:CRS>
   <osgeo:style>
    <osgeo:SLD>/path/to/style.sld</osgeo:SLD>
   </osgeo:style>
 </osgeo:LocalLayer>
</owc:Extension>

Make any sense?  I haven't worked with deegree (what did they do to
context?  Examples?) or GeoServer in awhile, but I do recall some
XML-based defs they had for configuration.

Cheers

..Tom


> -----Original Message-----
> From: standards-bounces at lists.osgeo.org 
> [mailto:standards-bounces at lists.osgeo.org] On Behalf Of 
> Kralidis,Tom [Burlington]
> Sent: 24 October, 2007 7:33 AM
> To: Lorenzo Becchi; Jody Garnett
> Cc: standards at lists.osgeo.org
> Subject: RE: [OSGeo-Standards] Re: How to extend OWS Context 
> forseveralspecific cases
> 
> 
>  
> 
> > -----Original Message-----
> > From: standards-bounces at lists.osgeo.org 
> > [mailto:standards-bounces at lists.osgeo.org] On Behalf Of 
> Lorenzo Becchi
> > Sent: 23 October, 2007 7:12 PM
> > To: Jody Garnett
> > Cc: standards at lists.osgeo.org
> > Subject: [OSGeo-Standards] Re: How to extend OWS Context for 
> > severalspecific cases
> > 
> > 
> > > Bleck too much; set up a wiki and track new context ideas
> > in the same
> > > manner as open street maps handles new feature types. Let 
> > > collaboration and composition sort out the good ideas and
> > leave OSGeo
> > > (and a process) out of it. When we feel we have something
> > good kick it
> > > over the wall to OGC (much like with the WMS tile idea).
> > 
> > why should I do twice an effort to prepare a document, when 
> OGC guys 
> > are here in this list?
> > and if we are going in two different directions while editing 
> > different documents?
> >
> 
> I don't see this as duplicate effort.
> 
> If I understand correctly, we are looking to develop a way to 
> share a web mapping application configuration, which includes 
> bindings to data sources, and maybe other items (styling, 
> templates, etc.) ?
> 
> If OWS Context suppports Extensions, then the goal here would 
> be to define an Extension grammar (in XML, GeoJSON, 
> whatever), which is then applied to OWS Context.
> 
> Having said this, I do know that OWS Context and KML are 
> being discussed as a possible harmonization item, but I'm not 
> aware of where that is at as far as a decision.
>  
> > if we don't have a Wiki to work together we can set up one or use 
> > OSGeo one.
> > 
> > process could be easy: public Wiki to mess up the Context, private 
> > Wiki for OGC internal documents.
> > 
> > make sense?
> > 
> > ciao
> > Lorenzo
> > 
> > _______________________________________________
> > Standards mailing list
> > Standards at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/standards
> > 
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards
>