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

Kralidis,Tom [Burlington] Tom.Kralidis at ec.gc.ca
Thu Oct 25 08:30:35 EDT 2007


Cameron: should a CHANGES.txt file go in each revision/directory as you
mention below?  Or should it go in the parent dir, i.e.:

http://www.ogcnetwork.net/schemas/owc/CHANGES.txt

..Tom


 

> -----Original Message-----
> From: Cameron Shorter [mailto:cameron.shorter at gmail.com] 
> Sent: 24 October, 2007 4:26 PM
> To: Kralidis,Tom [Burlington]
> Cc: standards at lists.osgeo.org
> Subject: Re: [OSGeo-Standards] Re: How to extend OWS Context 
> forseveralspecific cases
> 
> Thanks Tom for the update.
> Any chance you could put the changes information you list 
> below somewhere public.
> Eg:
> 
> http://www.ogcnetwork.net/schemas/owc/0.2.1/CHANGES
> 
> This is very useful for someone upgrading to a new version of 
> the spec.
> Typically a CHANGES file looks like:
> 
> version 3:
> summary of changes
> list of changes, often a copy from an issue tracker
> 
> version 2:
> ...
> 
> version 1:
> ...
> 
> Kralidis,Tom [Burlington] wrote:
> > 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
> >>
> >>     
> > _______________________________________________
> > Standards mailing list
> > Standards at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/standards
> >
> >   
> 
> 
> --
> Cameron Shorter
> Geospatial Systems Architect
> Tel: +61 (0)2 8570 5050
> Mob: +61 (0)419 142 254
> 
> Think Globally, Fix Locally
> Commercial Support for Geospatial Open Source Software 
> http://www.lisasoft.com/LISAsoft/SupportedProducts.html
> 
> 


More information about the Standards mailing list