[GeoSciML] RE : RE : TR : Queriability of QuantityRange

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Jun 25 11:10:13 EDT 2013


properties are now reachable by subset of xpath in WFS/FES spec.

________________________________________
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 Steve Richard [steve.richard at azgs.az.gov]
Date d'envoi : 25 juin 2013 10:45
À : 'Public: A mailing list for GeoSciML'
Objet : Re: [GeoSciML] RE : TR : Queriability of QuantityRange

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