[GeoSciML] FW: Updated Filter queries on age and lithology for GeoSciML v3 query client in 1GG portal

Duffy, Tim trd at bgs.ac.uk
Tue Aug 14 00:06:34 EDT 2012


For more detail on the OneGeology portal tool (to come 'this autumn') WFS age and lithology query profile referred to in the schematron checking email please see below.
regards
Tim

________________________________________
From: Duffy, Tim
Sent: 02 February 2012 17:07
To: Agnes Tellez-Arenas
Cc: Sen, Marcus A.; Laxton, John L.; Stephen M Richard; Francois Robida (f.robida at brgm.fr); Tertre Francois; Jean-Jacques Serrano (jj.serrano at brgm.fr); Perrier Pascal
Subject: FW: Updated Filter queries on age and lithology for GeoSciML v3 query client in 1GG portal

Dear Agnes - here at last is the proposed age and lithology filter queries to be used in the 1GG WFS query client. John , Marcus and myself have sat together for several hours to get this correct and implement the logically same queries (so as to minimise 'your' query client changes required) as possible using GeoSciML v3.0 and using the relevant CGI dictionaries CGI simplelithology201012.rdf for the lithology part and CGI2011TimeScale.rdf for the age part - both these dictionaries being (deliberately designed by the CGI's CDTG committee) supersets of what the 1GE service providers and query client users used so that 1GE services require only minor changes ( such as mapping urn's to uri's - Steve do we have that final 'name' based uri version for simplelithology imminently or do we continue with this version for now?) to their dictionary value mappings to work in the new 1gg (5 star) Geosciml v3.0 services.

Implicit in Marcus' description below are the following:

1). At the telecon  in October you asked that exOWS be asked to support WFS 1.1. only for now. Now it is clear that snowflake today, ESRI (for IGC34 in August - latest news) and geoserver (delayed until July - I suspect November) will be supporting WFS 2.0 1GG services 'this summer' so we ask that you provide a client user choice pull down menu  - like many other such clients - that offers 'apply your query to a WFS 1.1 service' and 'apply your query to a WFS 2.0' service before the queries are chosen/created. We have provided here filters for each type of query ( FES 1.1 for the first and FES 2.0 for the other) and you will see they are very nearly identical in every respect i.e. no extra programming required for the client side.

To test this client for you BGS will provide
a) an exOWS based WFS 1.1 service based on the BGS 625k standard exemplar 1gg dataset and a geoserver wfs 1.1 service (geoserver trunk was finally fixed to serve good gml 3.2.1 based geosciml v3.0 as a WFS 1.1 only on January 30th 2012!)
b) a snowflake wfs 2.0 service on the same dataset
The instance document that we have worked on to get right with the help of Steve that these services will offer as WFS collections is to be found here: https://www.seegrid.csiro.au/subversion/GeoSciML/branches/3.0.0/instances/BGS_MappedFeature_GeologicUnit_manualEdit.xml
We concluded that we did not need the source and target dictionaries and that the relationship value was affixed constant value from Steve's draft dictionary gsml:relationship xlink:href="http://resource.geosciml.org/classifier/cgi/featurerelation/geologicfeaturegeneticevent".


2). Your age choosing query client will simply have to offer for choosing all of the dictionary values in CGI2011TimeScale.rdf - which is equivalent to the 1ge age dictionary as it consists simply of the ICS 2009 values and the extra fennoscandian 1ge invented ones.
The key 1GG 'rules' (which will be documented in a cookbook John is writing in support of all of this) for setting up the age query is that the 'preferred age' to be relied on is the gsmlga:olderNamedAge  value and there must be only one GeologicEvent containing that oldernamedAge in the service being queried- equivalent to the 'preferred age' rule adopted in the 1GE Geosciml 2.1 age query.
Your simplelithology query client will have to be simply expanded downwards in a longer list to cover all the multiple roots  and hierarchy trees expressed in simplelithology201012.rdf to get to a single value, because the 1GE lithology query took a subset that avoided the issue that something like 'gabbro' can appear for choosing in more than on hierarchy tree in the full CGI dictionary. We have discussed this at length and it is clear that this is an issue of how data providers want to express their data i.e. if they want to express the parents of gabbro  according to the cgi dictionary hierarchies in more than one path then they can populate their service accordingly i.e. by implementing the full CGI dictionary in the client as it is expressed - there is no customisation required by you nor by the data providers  constraining where they map values.
Many thanks indeed,

Tim



Agnes,

we've had a look at updating the filter query you use in the 1GE portal so that it can be used with a 1GG profile of GeoSciML v3 as served by either a WFS 1.1.0 or WFS 2.0.0. As WFS 2.0.0 software is still not widely available the GeoSciML v3 WFS cookbook will show use of WFS 1.1.0 as well as WFS 2.0.0, ignoring the slight issue that a WFS 1.1.0 should strictly be able to support a GML 3.1.1 based response as well. The updated portal should be able to send the queries to both WFS 1.1.0 and WFS 2.0.0 GeoSciML 3 services.

I've taken the 1GE_filterGSML.xml file you sent Tim on 13th January and made equivalent FES 1.1.0 and FES 2.0.0 versions which are attached to this message as fes1_1GEfilter.xml and fes2_1GEfilter.xml respectively. The FES1 file is basically the same as yours with the new property paths for age and lithology for GeoSciML v3 final release and with example HTTP-URI values taken from the latest CGI dictionaries. The FES2 file uses the new Filter Encoding Standard elements to express the query which changes several element names but there is a 1-1 mapping between old and new names.

You didn't include a bounding box query in your email but I think we will need those as well so I've included the following files:

- fes1_gml311_1GEBBOXfilter.xml
- fes2_gml311_1GEBBOXfilter.xml
- fes2_gml321_1GEBBOXfilter.xml

fes1_gml311_1GEBBOXfilter.xml is more or less what I think you are currently sending except that I noticed that the 1GE portal is actually sending WFS 1.0.0 requests at the moment which I think uses some older version of the FES. I don't think there is any difference, however, and I don't think I'm going to try to see if we can support GeoSciML v3 with WFS 1.0.0 so please could you update the portal to sending v1.1.0 WFS requests?

For a WFS1 you will have to use FES1 which only allows gml v3.1.1. In theory this wouldn't work with GeoSciML 3 which is based on GML 3.2.1. However, the GML element names used in the BBOX query are exactly the same except for the namespace and the namespace isn't declared in GET queries so I think we will get away with this working.

For a WFS2 service you should send an FES2 query like fes2_gml321_1GEBBOXfilter.xml with GML 3.2.1. The FES element names are changed but there is a 1-1 mapping between FES1 and FES2 element names. The GML element names are exactly the same as the FES1 query except for the namespace. (I made fes2_gml311_1GEBBOXfilter.xml just to check that it was valid using GML3.1.1 inside FES2 but I don't think we'll have a use for it.)

The other small difference is that I've described the srs using srsName="urn:ogc:def:crs:EPSG::4326" format in the FES2 version and srsName="EPSG:4326" in the FES1 version. Those are the standard methods for each version but I think actual server software will probably understand EPSG:4326 in all cases, and maybe several different formats for specifying the SRS.

Marcus
------------------------------------------------------------------------------------------------ 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fes1_1GEfilter.xml
Type: application/xml
Size: 1957 bytes
Desc: fes1_1GEfilter.xml
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fes2_1GEfilter.xml
Type: application/xml
Size: 1909 bytes
Desc: fes2_1GEfilter.xml
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fes1_gml311_1GEBBOXfilter.xml
Type: application/xml
Size: 738 bytes
Desc: fes1_gml311_1GEBBOXfilter.xml
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fes2_gml311_1GEBBOXfilter.xml
Type: application/xml
Size: 721 bytes
Desc: fes2_gml311_1GEBBOXfilter.xml
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment-0003.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fes2_gml321_1GEBBOXfilter.xml
Type: application/xml
Size: 741 bytes
Desc: fes2_gml321_1GEBBOXfilter.xml
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment-0004.xml>
-------------- next part --------------
An embedded message was scrubbed...
From: Tellez-Arenas Agnes <a.tellez-arenas at brgm.fr>
Subject: 1GE WFS tools
Date: Fri, 13 Jan 2012 15:52:26 +0000
Size: 14692
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120814/5d159530/attachment.eml>


More information about the GeoSciML mailing list