[GeoSciML] RE : TR : Queriability of QuantityRange

Steve Richard steve.richard at azgs.az.gov
Tue Jun 25 10:45:56 EDT 2013


Looks like a viable solution in the long run, but will any of the WFS
implementations support it?


Stephen M Richard
Arizona Geological Survey
416 W. congress #100
Tucson, AZ
AZGS: 520-770-3500
Office: 520-209-4127
FAX: 520-770-3505

> -----Original Message-----
> From: geosciml-bounces+steve.richard=azgs.az.gov at lists.opengeospatial.org
>
[mailto:geosciml-bounces+steve.richard=azgs.az.gov at lists.opengeospatial.org]
> On Behalf Of Boisvert, Eric
> Sent: Monday, June 24, 2013 2:29 PM
> To: Public: A mailing list for GeoSciML
> Subject: [GeoSciML] RE : TR : Queriability of QuantityRange
> 
> wow - response from the wrong email to the wrong group..
> 
> way to go Eric..
> 
> this is in fact response from Alexandre.
> 
> 
> ________________________________________
> De : geosciml-bounces+eric.boisvert=rncan-
> nrcan.gc.ca at lists.opengeospatial.org
[geosciml-bounces+eric.boisvert=rncan-
> nrcan.gc.ca at lists.opengeospatial.org] de la part de Boisvert, Eric
> [Eric.Boisvert at RNCan-NRCan.gc.ca] Date d'envoi : 24 juin 2013 17:26 À :
> GeoSciml OGC mainling list Objet : [GeoSciML] TR : TR : Queriability of
> QuantityRange
> 
> réponse de Alain
> 
> ________________________________
> De : Alexandre Robin [alex.robin at sensiasoftware.com] Date d'envoi : 24
juin
> 2013 16:04 À : Boisvert, Eric Cc : Simon Cox; Mike Botts Objet : Re: TR :
> Queriability of QuantityRange
> 
> Hi Eric,
> 
> I actually got your email at my EADS address as well but did not have time
to
> answer earlier.
> 
> I understand your issue and I don't see any problem with adding the
following
> encoding to SWE Common :
> 
> <gsmlgu:proportion>
>       <swe:QuantityRange>
>         <swe:quality>
>            <swe:Text>
>              <swe:description>The numerical proportion ranges are just
indicative as
> we only record qualitative proportion terms such as "all", "predominant",
> "subordinate".</swe:description>
>             </swe:Text>
>          </swe:quality>
>         <swe:uom code="%"/>
>         <swe:lowerValue>95</swe:lowerValue>
>         <swe:upperValue>100</swe:upperValue>
>       </swe:QuantityRange>
> </gsmlgu:proportion>
> 
> 
> However, this would have to be submitted as a change request to be taken
into
> account in the next release of the standard. The good news is that it
could be
> done in the next minor revision (i.e. 2.1) since the change is trivial and
remains
> backward compatible with existing instances as long as we maintain the
other
> encoding.
> 
> Regards,
> 
> -----------------------------------------------------------
> Alexandre Robin
> Sensia Software LLC
> Innovation for the Geo-Sensor Web
> www.sensiasoftware.com<http://www.sensiasoftware.com>
> 
> 
> 
> 
> On Mon, 2013-06-24 at 11:46 +0000, Boisvert, Eric wrote:
> 
> Nous avons un peu de difficulté à vous rejoindre, Simon Cox m'a transmis
ces
> adresses courriels.
> 
> ---
> 
> Bonjour Alexandre
> 
> We are working on GeoSciML (OGC GeoSciML SWG) and we are using swe in
> several places.  We stumbled on a problem with QuantityRange that we are
not
> quite sure how to address..
> 
> QuantityRange values are represented as <swe:value>min max</swe:value>
> 
> for example:
> 
>  <gsmlgu:proportion>
>       <swe:QuantityRange>
>         <swe:quality>
>            <swe:Text>
>              <swe:description>The numerical proportion ranges are just
indicative as
> we only record qualitative proportion terms such as "all", "predominant",
> "subordinate".</swe:description>
>             </swe:Text>
>          </swe:quality>
>         <swe:uom code="%"/>
>        <swe:value>95 100</swe:value>
>       </swe:QuantityRange>
> </gsmlgu:proportion>
> 
> problem is that there are no easy ways to query this in FES:Filter (unless
we are
> missing something obvious)
> 
> For instance, we would like to filter out all proportion where the minimal
value >
> 25%.  This implies we must somehow isolate the first value of swe:value.
There
> are no FES filter operator to our knowledge that could do this (unless we
resort
> to invocation of backend SQL functions).
> 
> Would it be possible allow an extra encoding where each values would be in
> their individual properties (lowerValue and upperValue for instance) ?
> 
> We realise that there are other options, such as writing custom functions,
but
> we were told by some vendors that this functionality are unlikely to be
> implemented (or we are not guaranteed it will be supported by
off-the-shelf
> software)
> 
> Merci de votre aide
> 
> Cordialement
> Eric Boisvert
> 
> 
> 
> 
> 




More information about the GeoSciML mailing list