[GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Steve Richard steve.richard at azgs.az.gov
Tue Jul 2 20:21:15 EDT 2013


Looks good to me. 

 

Stephen M Richard

Arizona Geological Survey

416 W. congress #100

Tucson, AZ

AZGS: 520-770-3500

Office: 520-209-4127

FAX: 520-770-3505

 

From: GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] On Behalf
Of Boisvert, Eric
Sent: Tuesday, July 02, 2013 9:17 AM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

 

Draft CR attached for your perusal 

 

 

De : GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] De la part
de Oliver.Raymond at ga.gov.au
Envoyé : 30 juin 2013 20:34
À : geosciml at lists.opengeospatial.org
Objet : Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

 

Hi Eric,

 

I would still proceed with the CR, and I am more than happy for you to frame
it  :-)   The current situation is messy and the SWECommon SWG should clean
it up.

 

Unfortunately in GSML v3.2 we are stuck with the situation of having
“swe:value”, “upperValue” and “lowerValue” all as valid options if we want
to do this change as a v3.x change.  To remove swe:QuantityRange from the
model altogether and replace it with our own QuantityRange is a
non-backwardly-compatible change.  So, yes, it must be Schematron rules for
v3.2 “gsmlu:GSML_QunatityRange”.  

 

My feeling is that we need a Schematron rule that states “both lowerValue
and upperValue should be present”.  In v3.1, we had to provide both upper
and lower values because swe:value will not validate without two numbers.
So I think we should stick with that same intent.

 

As far as the ongoing use of swe:value goes, is there any use for swe:value
at all if we can’t query it?  If someone can give me a use case for
requiring its presence in a serialisation, then we can add it to the
Schematron rule, but at the moment I’m happy to have the optional use of
swe:value at the discretion of the data provider.

 

Cheers,

Ollie

 

____________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |   <http://www.ga.gov.au/>
GEOSCIENCE AUSTRALIA
Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971
Email:   <mailto:Oliver.Raymond at ga.gov.au> Oliver.Raymond at ga.gov.au    Web:
<http://www.ga.gov.au/> www.ga.gov.au
Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT
GPO Box 378   Canberra   ACT   2601   Australia

 

-----Original Message-----
From: GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] On Behalf
Of Boisvert, Eric
Sent: Monday, 1 July 2013 12:36 AM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

 

This pretty much solves the problem.    Do we still need to a CR then ? (I
was looking into this)

 

 

Minor point though..

 

The way it's implemented, a GSML_QuantityRange can be either a swe:value
and/or a lowerValue and/or a upperValue so this

 

...

<swe:value>90 100</sweValue>

<gsml:lowerValue>90</gsml:lowerValue>

...

is valid.

 

(I assume that missing upperValue or lowerValue means that the range is
open)

 

proably need a bit a schematron to constrain here ?.  Since the whole point
of this class is to expose FES friendly properties (sigh) I suppose the rule
is that either one or both of lowerValue and upperValue should be present.

 

Do we let swe:value serialization as valid representation ?  For instance,
can someone build a FES filter over lowerValue/upperValue but receive a
response only using swe:value ? This is the problem when we have multiple
representations..  If lowerValue and upperValue is just a query
representation, we can state that the serialisation uses swe:value.

 

My 2 cents

 

________________________________

De :
<mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatia
l.org>
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 Laxton, John L. [jll at bgs.ac.uk] Date d'envoi : 26 juin 2013
04:15 À : Public: A mailing list for GeoSciML Objet : Re: [GeoSciML]
QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

 

Hi Ollie,

 

That looks good to me and is what we discussed/agreed in St Petersburg.
Putting GSML_QuantityRange in the Utilities package would seem the most
logical as you say (it’s where the old CGI_Value etc were).

 

John

 

From:  <mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org>
geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org [
<mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org>
mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org] On Behalf Of
<mailto:Oliver.Raymond at ga.gov.au> Oliver.Raymond at ga.gov.au

Sent: 26 June 2013 03:48

To:  <mailto:geosciml at lists.opengeospatial.org>
geosciml at lists.opengeospatial.org

Subject: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

 

Hi all,

 

If the SWECommon SWG cannot publish a quick change to swe:QuantityRange as
SWECommon v2.1 (unlikely?), then I propose the following changes for
GeoSciML version 3.2:

 

 

1.       Create a new class called GSML_QuantityRange

 

a.       a child of swe:QuantityRange

 

b.      contains two attributes – lowerValue and upperValue, both 0..1

 

c.       maintains access to the other SWE QuantityRange attributes like
uom, description, etc

 

2.       Put the new GSML_QuantityRange class in the CGI_Utilities package.

 

a.       this appears to be the logical place to put a GSML_QuantityRange
class.  The EarthMaterial and GeologicUnit packages would need to be amended
so that they import CGI_Utilities.

 

b.      alternatively, put GSML_QuantityRange in GeoSciML-Core. Then there
is only one change to package imports --> CGI_Utilities must import
GeosciML-Core.

 

c.       to avoid changing package imports at all, we would have to create a
GSML_QuantityRange class in the CGI_Utilities, EarthMaterial, and
GeologicUnit packages.

 

The nice thing about creating a child class of swe:QuantityRange is that we
don’t have to change any of the attributes in the model which use the
swe:QuantityRange property type.  Data providers will be presented with the
option to use either swe:QuantityRange or gsmlu:GSML_QuantityRange. This is
not ideal, but existing v3.1 services that use swe:QuantityRange would still
be valid in v3.2.

 

An example v3.1 XML instance (this would still validate in v3.2):

 

<gsmlst:planeOrientation>

                <gsmlu:CGI_PlanarOrientation>

                                


                                <gsmlu:azimuth>

                                                <swe:QuantityRange>

 
<swe:description>The azimuth of the strike of the fault, measured in
degrees</swe:description>

                                                                <swe:uom
code="degree" xlink:href=" <http://www.opengis.net/def/uom/OGC/1.0/degree>
http://www.opengis.net/def/uom/OGC/1.0/degree" xlink:title="degree"/>

 
<swe:value>110 130</swe:value>

                                                </swe:QuantityRange>

                                </gsmlu:azimuth>

                                


                </gsmlu:CGI_PlanarOrientation>

 

An amended example v3.2 XML instance:

 

<gsmlst:planeOrientation>

                <gsmlu:CGI_PlanarOrientation>

                                


                                <gsmlu:azimuth>

                                                <gsmlu:GSML_QuantityRange>

 
<swe:description>The azimuth of the strike of the fault, measured in
degrees</swe:description>

                                                                <swe:uom
code="degree" xlink:href=" <http://www.opengis.net/def/uom/OGC/1.0/degree>
http://www.opengis.net/def/uom/OGC/1.0/degree" xlink:title="degree"/>

 
<swe:value>110 130</swe:value>

 
<gsmlu:lowerValue>110</gsmlu:lowerValue>

 
<gsmlu:upperValue>130</gsmlu:upperValue>

                                                </gsmlu:GSML_QuantityRange>

                                </gsmlu:azimuth>

                                


                </gsmlu:CGI_PlanarOrientation>

 

Please let me know what you think.

 

Cheers,

Ollie

 

_________________________________________________________________

 

Ollie Raymond

Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA<
<http://www.ga.gov.au/> http://www.ga.gov.au/>

 

Oceania Councillor & Interoperability Working Group IUGS Commission for the
Management and Application of Geoscience Information<
<http://www.cgi-iugs.org/> http://www.cgi-iugs.org/>

 

Chair, GeoSciML Standards Working Group

Open Geospatial Consortium<
<http://www.opengeospatial.org/projects/groups/geoscimlswg>
http://www.opengeospatial.org/projects/groups/geoscimlswg>

____________________________________________________

 

Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971

Email:   <mailto:Oliver.Raymond at ga.gov.au%3cmailto:Oliver.Raymond at ga.gov.au>
Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:
<http://www.ga.gov.au%3chttp:/www.ga.gov.au/>
www.ga.gov.au<http://www.ga.gov.au/>

Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT

GPO Box 378   Canberra   ACT   2601   Australia

 

Applying geoscience to Australia’s most important challenges

 

 

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it)
is intended only for the person or entity to which it is addressed. If you
are not the intended recipient, then you have received this e-mail by
mistake and any use, dissemination, forwarding, printing or copying of this
e-mail and its file attachments is prohibited. The security of emails
transmitted cannot be guaranteed; by forwarding or replying to this email,
you acknowledge and accept these risks.

----------------------------------------------------------------------------
---------------------------------------------

 

________________________________

This message (and any attachments) is for the recipient only. NERC is
subject to the Freedom of Information Act 2000 and the contents of this
email and any reply you make may be disclosed by NERC unless it is exempt
from release under the Act. Any material supplied to NERC may be stored in
an electronic records management system.

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it)
is intended only for the person or entity to which it is addressed. If you
are not the intended recipient, then you have received this e-mail by
mistake and any use, dissemination, forwarding, printing or copying of this
e-mail and its file attachments is prohibited. The security of emails
transmitted cannot be guaranteed; by forwarding or replying to this email,
you acknowledge and accept these risks.
----------------------------------------------------------------------------
---------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130702/0cf56bad/attachment-0001.html>


More information about the GeoSciML mailing list