[Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

Robert.Woodcock at csiro.au Robert.Woodcock at csiro.au
Mon Mar 1 21:32:15 EST 2010


> Fine with me, but this is more testing available mapping technologies than testing the model itself. Unless WFS and/or RDBMS constrains becomes model design requirements.

AuScope are keen to ensure that we have some decent tests for WFS serving GML application schemas. The current OGC cite tests in this regard are lacking. This is one of the drivers behind the "unit tests" Bruce Simons is referring too. GeoSciML being one of the more mature GML application schemas provides a useful basis for such testing for both WFS compliance and for the GeoServer technology. We hope to feed the test suite back into the OGC compliance process. So, yes, it is more about testing the standards and mapping technologies rather than the model itself though it will serve both purposes.

The second comment regarding the WFS or the RDBMS becoming constraints on the model design requirements is interesting. In my view these already are, or should be, lest the model itself become something that cannot be implemented or managed in practice. I include "managed" as the community of practice around GeosciML also uses HollowWorld for model management plus vocab management tools etc. It's a complete system that is required.

Please don't misunderstand me, the model itself in an ideal situation would not be constrained by implementation details. In practice though it is and whilst the WFS middleware is immature relative to the modelling process the model runs the risk of getting ahead of the implementations and becoming not implementable/manageable - my concerns about WFS CITE tests relates to this, so does the Geoserver development which we are earnestly trying to complete the foundation work for GeoSciML support before WFS 2.0 and GeoSciML 3 arrive. The separate, but related, developments that make up the community of practice that is using GeoSciML needs to remain in loose synchronisation and not get to far ahead or behind one another for the varying parts of the system. So far so good.

> Actually, this also begs the question.. Are we restricted to classical RDBMS or is it more about currently available softwares ?

In my view it is more about currently available software. I built a WFS using XMML (roughly an early version of GeoSciML Borehole) using an Object Oriented database some years back. Full 3D support, web delivery etc. Somewhat bespoke for that particular OO database but there was nothing in the XMML model that seems restrictive to RDBMS - in fact it was somewhat easier than the RDBMS mapping process used in Geoserver as the OO database was "Feature" based in the first place so a much closer match to the GML model.

Regards,

Rob

Dr Robert Woodcock
CSIRO
ARRC (Australian Resources Research Centre)
26 Dick Perry Avenue, Kensington WA 6151, Australia
PO Box 1130, Bentley WA 6102, Australia
Ph: 08 6436.8780 | E: Robert.Woodcock at csiro.au<mailto:Robert.Woodcock at csiro.au> | W: www.csiro.au<http://www.csiro.au/>

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Monday, 1 March 2010 6:12 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

> It will also serve for 'unit tests' when testing middkleware such as GeoServer for WFS1.1 compliance.  In order to test the mapping and transformation it shouldn't be a database that looks like GeoSciML, but rather like one of our pre-GeoSciML databases with any missing components added to it.

Fine with me, but this is more testing available mapping technologies than testing the model itself. Unless WFS and/or RDBMS constrains becomes model design requirements.  Actually, this also begs the question.. Are we restricted to classical RDBMS or is it more about currently available softwares ?

Eric

________________________________
De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Bruce.Simons at dpi.vic.gov.au
Date: dim. 2010-02-28 17:06
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED]

Hi all,
I'm happy to use instance documents to test the model if services aren't available. However, we need to be careful that the modelling does not get too far ahead of the implementation, which is what can happen with this strategy, and has in the past.  In order that we at least have a chance of setting up GeoSciML 3.0 services I repeat my request in Quebec that GeoSciML remain a GML 3.1 application, with additional 'placeholders' for GML3.2 properties if necessary.

Eric proposed:

My suggestion for this portion of the testbed is
1- Come with a series of legend descriptions, or stories for each of the relevant use cases. Different regions and languages is obviously encouraged. Agree. But I would also like to see a 'test' database established (see below).

2- Have people to generate instance document based on selected stories. The interesting bit is when more than one person attempts to serialise the same stories. We already know that there is a lot of assumptions in legend description and it will be interesting to see how this materialise on a rigid GeoSciML document.
Although this is is good it is not sufficient.  we also need to commit to ensuring that the different instance documents are compared to ensure consistency between them. We have not fully done this in previous testbeds, as it can be quite onerous and time-consuming.

An issue with this approach is that it will only include data we have in our production databases, or in a particular legend.  This does not fully test the model. I suggest that one of the Testbed participants (any volunteers?) also create a 'dummy' database which contains all properties that we wish to test (complete GeoSciML).  We then use this as a guide to craft the instance documents, and our own databases to establish the services.  It will also serve for 'unit tests' when testing middkleware such as GeoServer for WFS1.1 compliance.  In order to test the mapping and transformation it shouldn't be a database that looks like GeoSciML, but rather like one of our pre-GeoSciML databases with any missing components added to it.

Cheers
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155

<Oliver.Raymond at ga.gov.au>
Sent by: auscope-geosciml-bounces at lists.arcs.org.au

26/02/2010 08:50 AM
Please respond to
auscope-geosciml at lists.arcs.org.au


To

<auscope-geosciml at lists.arcs.org.au>

cc

Subject

Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED]







I agree too.

Personally, I am keen to see the process applied to geochemistry data too, mainly because O&M "result" is of type "Any", meaning that currently users can encode their assay data using any of several available methods (eg, swe:Quantity, gml:measure, etc).  Having a best practice XML example of a geochemistry 'story' is essential.

Cheers,
Ollie



------------------------------------------------------------------------------------------------
Ollie Raymond
National Advice,  Maps and Standards Project
Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au
Web:  http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp

Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>

-- This message was created with 100% recycled electrons --


-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Friday, 26 February 2010 1:39 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] Testbed proposition

> I really like the idea of adding real XML examples to a specification document.

Ditto for me, I think it's the most readable form.

If I understand the current trend up there at ISO/OGC, looks like the UML spec and XML encoding will now be published in two separates documents (to avoid making amendment to the UML+XML spec when only changes to XML is needed and to have UML spec independent of implementation).  The "instance" in the UML spec are often shown as UML instance diagram that all looks like a freak accident in Legoland if you ask me.

Eric

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Guillaume.Duclaux at csiro.au
Envoyé : 25 février 2010 09:34
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition
I really like the idea of adding real XML examples to a specification document.

<<Some specification document (O&M "banana" examples come to mind) had those examples and they were extremely useful to 'grasp' the concept, specially when showing them to non-technical people. >>
+1 --> The example helped me probably more than the spec document itself for the NVCL o&m work I started and improved with Bruce and Alistair.

Gilly
________________________________________________

Dr Guillaume Duclaux
CSIRO Earth Science and Resource Engineering
Visiting address: ARRC, 26 Dick Perry Av., Kensington WA 6151
Postal address: PO Box 1130, Bentley WA 6102, Australia
Ph: + 61 8 6436 8728    Fax: + 61 8 6436 8555    Web: www.csiro.au<http://www.csiro.au/>




________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Thursday, 25 February 2010 9:05 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] Testbed proposition

Guys,
A significant portion of use cases we have listed in Quebec is about testing new and altered elements of GeoSciML v3. In the past we tested those changes with instance documents and created a series of testbed to test the serialisation from a database. I think it's important to emphasise the difference between testing the model and testing the serialisation. Instance document allowed us to test the model with real cases. Creating WFS from a database allowed us to test the feasibility of turning our respective databases into GeoSciML (we tested the mapping between our databases and GeoSciML and its queriability using WFS). In principle, when we are testing the serialisation, the model should already be tested.

In NADM, we tested the model with a real case example from a legend description of a geological map of Arizona:
Harald Drewes. 1998,. ARIZONA. Geologic map of the Bartlett Mountain Quadrangle, Pima and Santa Cruz counties, Arizona, I-2624. Lat 31 deg 22'30" to 31 deg 30', long 111 deg 15' to 111 deg 22'30". Scale 1:24,000 (1 inch = 2,000 feet). Sheet 43 by 39 1/2 inches.

The text of the legend read as follow :
Dacitic Vent Breccia (Miocene) -Light-medium-gray, finely porphyritic dacitic rock containing inclusions of Jurassic or Proterozoic granite and Jurassic rhyolite (welded tuff?) as much as 20 m in diameter. The subcircular outcrop mass of breccia probably is a volcanic vent or throat. A halo of strongly saussuritized rock 0.3 -0.5 km wide (delineated on map) surrounds this vent. The dacitic matrix consists of phenocrysts (25-35%, as much as 2 mm in length) set in a cryptocrystalline granular groundmass. Phenocrysts included albitized(?) plagioclase (12-18%), chloritized biotite (2-5%), uralized amphibole (2-10%), magnetite (trace to 2%), and apatite (trace). Quartz is present as a secondary mineral, filing vugs.

At that time, the data model was a RDBMS implementation, therefore the 'instance' document was a description of the table content: see: http://ngmdb.usgs.gov/www-nadm/dmdt/pdf/CORDLink_Variant_Example.pdf

What I found interesting in this exercise was that we tested the model from a real case. Some specification document (O&M "banana" examples come to mind) had those examples and they were extremely useful to 'grasp' the concept, specially when showing them to non-technical people. What I propose as a testbed (at least for that portion of the use cases that are relevant) is to have similar exercises. The added benefit is to produce material, coupled with an updated document like OneGeology Cookbook #2, that can be used in discussion with new comers and non-technical people.

My suggestion for this portion of the testbed is
1- Come with a series of legend descriptions, or stories for each of the relevant use cases. Different regions and languages is obviously encouraged.

2- Have people to generate instance document based on selected stories. The interesting bit is when more than one person attempts to serialise the same stories. We already know that there is a lot of assumptions in legend description and it will be interesting to see how this materialise on a rigid GeoSciML document.

Eric

================================================================
Eric Boisvert
Spécialiste TI-GI / IT-IM specialist
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur
418-654-2615
490, rue de la Couronne, Québec (Québec), G1K 9A9
490, rue de la Couronne, Quebec, Quebec, G1K 9A9

Laboratoire de cartographie numérique et de photogrammétrie (LCNP)
Digital Cartography and Photogrammetry Laboratory (DCPL)
Commission géologique du Canada (Québec) / Geological Survey of Canada (Quebec)
Ressources naturelles Canada / Natural Resources Canada
Gouvernement du Canada / Government of Canada
http://cgc.rncan.gc.ca/org/quebec
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 / http://cgc.rncan.gc.ca/dir/index_e.php?id=4186

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100302/06f0d38f/attachment.htm>


More information about the GeoSciML mailing list