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

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Mon Mar 1 05:12:05 EST 2010


> 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 <http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp>  <http://www.ga.gov.au/geoscience/national>  

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 <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/org/quebec>  
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 <http://cgc.rncan.gc.ca/dir/index_f.php?id=4186>  / http://cgc.rncan.gc.ca/dir/index_e.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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 15959 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100301/8cbb4545/attachment.bin>


More information about the GeoSciML mailing list