[Auscope-geosciml] RE : RE : RE : RE : CGI Value SWE

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Sep 1 17:18:01 EDT 2009


https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/WFSUsabilityIssues#Possible_solution_and_proposal <https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/WFSUsabilityIssues#Filtering_complex_features> 
 

________________________________

De: Stephen M Richard [mailto:steve.richard at azgs.az.gov]
Date: mar. 2009-09-01 17:02
À: Boisvert, Eric
Cc: auscope-geosciml at lists.arcs.org.au
Objet : Re: RE : [Auscope-geosciml] RE : RE : CGI Value SWE


I thought there must be a problem!.  Is the separate query and response schema something like what csw does with its 'common queryable elements'? I've been thinking that might be a useful approach for some common geology queries --age and lithology. 
steve

Boisvert, Eric wrote: 

	oops. my example is not correct
	 
	this one is
	 
	<Feature gml:id="A">
	  <propertyA>
	    <DataType>
	        <propertyX>1</propertyX>
	        <propertyZ>2</propertyZ>
	     </DataType>
	   <propertyA>
	  <propertyA>
	    <DataType>
	        <propertyX>5</propertyX>
	        <propertyZ>10</propertyZ>
	     </DataType>
	   <propertyA>
	</Feature>
	
	
	________________________________
	
	De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Boisvert, Eric
	Date: mar. 2009-09-01 16:47
	À: steve.richard at azgs.az.gov
	Cc: auscope-geosciml at lists.arcs.org.au
	Objet : [Auscope-geosciml] RE : RE : CGI Value SWE
	
	
	
	  

		Could it work in a service that you might want to query for values inside the result elements?
		    

	good point. that makes those values similar to geometrie that can only be handled through special functions (such as WITHIN, DISTANCE, etc.).  argh.  I guess the question become, should GeoSciML be limited by what is implementable in WFS.  If it's a criteria, there are a couple of dark area to revisit in the model.
	Darn ogc:Filter was made to query simple literals.  For instance:  consider this example
	
	<Feature gml:id="A">
	  <propertyA>
	    <DataType>
	        <propertyX>1</propertyX>
	        <propertyZ>2</propertyZ>
	     </DataType>
	   <propertyA>
	  <propertyA>
	    <DataType>
	        <propertyX>1</propertyX>
	        <propertyZ>10</propertyZ>
	     </DataType>
	   <propertyA>
	</Feature>
	
	if you send a filter for typeName=Feature WHERE propertyA/DataType/propertyX = 1 AND propertyA/DataType/propertyZ = 10. It will return this feature (I bet it's not what you thought the query meant)
	
	Not sure Filter 2.0 provide a way to solve this one (Or I missed something obvious again)
	
	There is also the option of separating the query schema from the response schema (a.k.a: views) (I hear Boyan howling).
	
	Eric
	
	
	
	________________________________
	
	De: Stephen M Richard [mailto:steve.richard at azgs.az.gov]
	Date: mar. 2009-09-01 16:12
	À: Boisvert, Eric
	Cc: auscope-geosciml at lists.arcs.org.au
	Objet : Re: [Auscope-geosciml] RE : CGI Value SWE
	
	
	Eric-- looks like something good for data delivery. Could it work in a service that you might want to query for values inside the result elements? For example in the case of PlanarOrientation, ask for structures with planar orientation having dip greater than 50? Admittedly our current schema makes the xpath for that pretty heinous...
	
	If we were going to got towards the sort of encoding you show, we should use swe:DataArray (or something like that)
	
	steve
	
	Boisvert, Eric wrote:
	
	        > It would make things more complex
	        
	        I'm not sure it would.  Actually, we already discussed this: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/CgiValueDiscussionPreTucson
	        The nice thing (or maybe it's a deadly trap) about SWE encoding is that you can define encoding format outside the schema (call it soft-typing).
	       
	
	....
	
	
	        We could have a series of geology specific encodings defined as we do for vocabularies (in a registry). The rule to use those value encoding are essentially the same as the rule that follow when we use specific vocabularies.
	
	       
	         <gsml:CGI_Value>
	          <gsml:valueDefinition xlink:href="urn:cgi:...:...:PlanarMeasureWithDisplacement">
	          <gsml:result>123 15 23.5</gsml:result>
	        </gsml:CGI_Value>
	         
	
	        I find it less difficult than the CGI_Value contraption .  Compare this with a CGI_Value representation (granted, not the same kind of measure, but you got the picture)
	
	       
	        <gsml:CGI_PlanarOrientation>
	                        <gsml:determinationMethod>
	                                <CGI_TermValue>
	                                        <value codeSpace="urn:cgi:classifierScheme:CGI:DeterminationMethod">Brunton compass</value>
	                                </CGI_TermValue>
	                        </gsml:determinationMethod>
	                        <gsml:convention>dip dip direction</gsml:convention>
	                        <gsml:azimuth>
	                                <gsml:CGI_NumericValue>
	                                                <principalValue uom="degree">270</principalValue>
	                                </gsml:CGI_NumericValue>
	                        </gsml:azimuth>
	                                <gsml:dip>
	                                        <gsml:CGI_NumericValue>
	                                        <gsml:principalValue uom="degree">60</gsml:principalValue>
	                                                </gsml:CGI_NumericValue>
	                                </gsml:dip>
	                                <gsml:polarity>upright</gsml:polarity>
	        </gsml:CGI_PlanarOrientation>
	         
	        The whole set of conventions, units, etc.. are repeated for each measures.  This could be defined once and reused.
	        
	        Eric
	
	________________________________
	
	        De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Stephen M Richard
	        Envoyé : 1 septembre 2009 13:32
	        Cc : auscope-geosciml at lists.arcs.org.au
	        Objet : Re: [Auscope-geosciml] RE : CGI Value SWE
	       
	       
	        Eric--I agree, the wider use of SWE is the main reason to consider replacing CGI_Value with SWE elements. It would make things more complex, but if there are tools built for SWE, that would offset the added complexity. I don't think it would address the interop problem presented by the multiple possible value representations -- still need more restrictive app profiles.
	       
	        steve
	       
	        Boisvert, Eric wrote:
	
	                        but its not at all obvious to me that this would be any simpler or more interoperable than CGI_Value
	                           
	
	                I don't think it will. Actually, I saw CGI_Value reinventing a bit of the SWE wheel.  The only benefit I see from SWE is that there are a lot of other communities out there dealing with complex values representation using SWE, stuff we could reuse.  The other reason we might consider SWE is that O&M uses SWE and since GeoSciML (and GWML and EarthResourceML,etc.) are claiming to use O&M, we are potentially looking into two distinct values encoding models.
	               
	                Eric
	               
	                -----Message d'origine-----
	                De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Stephen M Richard
	                Envoyé : 1 septembre 2009 12:51
	                À : auscope-geosciml at lists.arcs.org.au
	                Objet : Re: [Auscope-geosciml] RE : CGI Value SWE
	               
	                I've never actually used SWE, but looking at the UML in HollowWorld, it looks like the elements in question are in the simpleTypes package. The conceptual setup makes sense, and I like the use of the Quality property.  However, as John L points out, the ability to add qualifiers is useful. This could be accounted for by using something like a SWE DataRecord, but its not at all obvious to me that this would be any simpler or more interoperable than CGI_Value. Interoperability will still depend on a more proscriptive application profile that restricts the possible encodings.
	               
	                steve
	               
	                Boisvert, Eric wrote:
	                 
	
	                        should we bring the swe encoding back to the table. it has been rejected in Tucson on the basis that we were not ready to deal with it.  Or is swe just CGI_Value in another dress ?
	                        
	                        Eric
	                       
	                        ________________________________
	                       
	                        De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Laxton,
	                        John L
	                        Date: mar. 2009-09-01 05:08
	                        À: auscope-geosciml at lists.arcs.org.au
	                        Objet : Re: [Auscope-geosciml] CGI Value abomination
	                       
	                       
	                       
	                        I think we have definitely over-used CGI_Value - as I recall it was put in almost ubiquitously on the basis that with experience of the use of GeoSciML we would have a better idea what type of data was actually being used for particular properties. We now have that experience for many, but by no means all, of the properties so we should definitely be able to reduce the use of CGI_Value.
	                       
	                        
	                       
	                        That said a couple of points need to be remembered:
	                       
	                        
	                       
	                        1. As well as allowing us to be imprecise about the basic type of a property CGI_Value allows us to add a qualifier to the value. I think given the nature of much geoscience data there is requirement for this for many properties, even where we can now allocate a precise data type - this doesn't just apply to field data.
	                       
	                        
	                       
	                        2. There are definitely some properties (eventAge springs to mind) where the ability to specify the property in a range of different ways is essential. 
	                       
	                        
	                       
	                        We should therefore be able to reduce the use of CGI_Value, but not eliminate it.
	                       
	                        
	                       
	                        Jo
	                           
	
	                --
	                Stephen M. Richard
	                Section Chief, Geoinformatics
	                Arizona Geological Survey
	                416 W. Congress St., #100
	                Tucson, Arizona, 85701 USA
	               
	                Phone:
	                Office: (520) 209-4127
	                Reception: (520) 770-3500
	                FAX: (520) 770-3505
	               
	                email: steve.richard at azgs.az.gov
	               
	                _______________________________________________
	                Auscope-geosciml mailing list
	                Auscope-geosciml at lists.arcs.org.au
	                http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
	               
	                 
	
	
	        --
	        Stephen M. Richard
	        Section Chief, Geoinformatics
	        Arizona Geological Survey
	        416 W. Congress St., #100
	        Tucson, Arizona, 85701 USA
	       
	        Phone:
	        Office: (520) 209-4127
	        Reception: (520) 770-3500
	        FAX: (520) 770-3505
	       
	        email: steve.richard at azgs.az.gov
	
	
	--
	Stephen M. Richard
	Section Chief, Geoinformatics
	Arizona Geological Survey
	416 W. Congress St., #100
	Tucson, Arizona, 85701 USA
	
	Phone:
	Office: (520) 209-4127
	Reception: (520) 770-3500
	FAX: (520) 770-3505
	
	email: steve.richard at azgs.az.gov
	_______________________________________________
	Auscope-geosciml mailing list
	Auscope-geosciml at lists.arcs.org.au
	http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
	
	
	
	  


-- 
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone: 
Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov



More information about the GeoSciML mailing list