[Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]

Stephen M Richard steve.richard at azgs.az.gov
Fri Sep 4 11:21:22 EDT 2009


This, and Eric's following comment in this thread are a good example of 
interplay of data model and service architecture.
steve

Laxton, John L wrote:
>
> I think once we start having specific placeholders for codes things 
> are going to get complicated quite quickly. For example we have two 
> codes, one used as a primary key in the StratigraphicLexicon and the 
> other for map symbolisation. I guess other folk may use different 
> codes for different things. As all these codes are generally 
> referenceable through the StratigraphicLexicon (as in the example 
> below) wouldn't it be best to simply use the Stratigraphic Name as the 
> only name for GeologicUnit and anyone who wants the various codes can 
> go to the StratigraphicLexicon to get them?
>
>  
>
> John
>
>  
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of 
> *Oliver.Raymond at ga.gov.au
> *Sent:* 04 September 2009 00:35
> *To:* auscope-geosciml at lists.arcs.org.au
> *Cc:* Alexandre.Robin at spotimage.fr
> *Subject:* Re: [Auscope-geosciml] RE : RE : CGI Value abomination 
> [SEC=UNCLASSIFIED]
>
>  
>
>  
>
> So... as I understand it, I can't write a WFS filter to specifically 
> query, for instance, Map_symbol or GeologicalUnitName in the instances 
> below....
>
>  
>
> <gsml:GeologicUnit gml:id="*GA_GeologicUnit_Stratno_134*">
>
> <gml:name 
> codeSpace="*urn:cgi:classifierScheme:GA:StratigraphicLexicon:Stratname*">*Adelong 
> Norite*</gml:name>
>
> <gml:name 
> codeSpace="*urn:cgi:classifierScheme:GA:StratigraphicLexicon:Map_symbol*">*Sgad*</gml:name> 
>
>
>  
>
> <gsml:GeologicUnit gml:id="*gu.26931319*">
>
> <gml:name 
> codeSpace="*urn:cgi:classifierScheme:GSV:GeologicalUnitName*">*Bacchus 
> Marsh Formation*</gml:name>
>
> <gml:name 
> codeSpace="*urn:cgi:classifierScheme:GSV:GeologicalUnitCode*">*Pxb*</gml:name> 
>
>
>  
>
> Does the community see a need for a more GeoSciML-specific encoding of 
> the geological unit name and map_symbol/unit_code/map_code, as opposed 
> to the current use of the generic gml:name for both of these 
> descriptors? 
>
>  
>
> A suggestion might be that gml:name be reserved strictly for the name 
> of the unit (eg: Adelong Norite, Bacchus Marsh Formation), and we 
> create a specific GeoSciML placeholder for map_symbol/unit_code/map_code?
>
>  
>
> Any thoughts?
>
>  
>
> /------------------------------------------------------------------------------------------------/
>
> /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: Thursday, 3 September 2009 7:51 PM
> To: auscope-geosciml at lists.arcs.org.au; 
> auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
> Cc: Robin, Alexandre
> Subject: [Auscope-geosciml] RE : RE : CGI Value abomination 
> [SEC=UNCLASSIFIED]
>
>  
>
> Actually, you can't, or at least not to the point that codeSpace is of 
> any use.  Filter sees the world in denormalised form.
>
>  
>
> consider this instance
>
>  
>
> <Feature>
>
>   <gml:name codeSpace="urn:1">concept_a</gml:name>
>
>   <gml:name codeSpace="urn:2">concept_b</gml:name>
>
> </Feature>
>
>  
>
> We want to select concept_a of codeSpace urn:2 (this instance should 
> not match)
>
>  
>
> <ogc:And>
>
>    <ogc:PropertyIsEqualTo>
>
>      <ogc:PropertyName>gml:name</ogc:PropertyName>
>
>      <ogc:Literal>concept_a</ogc:Literal>
>
>    </ogc:PropertyIsEqualTo>
>
>    <ogc:PropertyIsEqualTo>
>
>      <ogc:PropertyName>gml:name/@codeSpace</ogc:PropertyName>
>
>      <ogc:Literal>urn:2</ogc:Literal>
>
>    </ogc:PropertyIsEqualTo>
>
> </ogc:And>
>
>  
>
> will match the instance
>
>  
>
> This problem has been reported some times ago.
>
>  
>
> This means that we can't really target specific codeSpace when we 
> query a term, codeSpace are useless in filter.
>
> I know it is unlikely that many codeSpace for the same property are to 
> be present in the same feature (gml:name is the only one I can think 
> of), but just to point out that codeSpace can't be use to tell term 
> apart in WFS/Filter.  You might as well ignore codeSpace filtering 
> altogether. and hope that the term is unique.
>
>  
>
> I don't think it's a show stopper, it will return false positive in 
> the worst case scenario.
>
>  
>
> Eric
>
>  
>
>  
>
>  
>
>  
>
>  
>
> ________________________________
>
>  
>
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
>
> Date: jeu. 2009-09-03 05:31
>
> À: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
>
> Cc: 'Robin, Alexandre'
>
> Objet : Re: [Auscope-geosciml]RE : CGI Value abomination 
> [SEC=UNCLASSIFIED]
>
>  
>
>  
>
>  
>
> Yes - I still strongly urge y'all to attempt a 'cull' of the soft-typed
>
> values,
>
> and replace them with ScopedName (this _is_ ControlledConcept Steve!) or
>
> Measure wherever possible.
>
> As Eric points out, you can actually write filters against those.
>
>  
>
>  
>
> --------------------------------------------------------
>
> Simon Cox
>
>  
>
> European Commission, Joint Research Centre,
>
> Institute for Environment and Sustainability,
>
> Spatial Data Infrastructures Unit, TP 262
>
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>
> Tel: +39 0332 78 3652
>
> Fax: +39 0332 78 6325
>
> mailto:simon.cox at jrc.ec.europa.eu
>
> http://ies.jrc.ec.europa.eu/simon-cox
>
>  
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/
>
> IES Institute: http://ies.jrc.ec.europa.eu/
>
> JRC: http://www.jrc.ec.europa.eu/
>
> --------------------------------------------------------
>
>  
>
> -----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: Thursday, 3 September 2009 11:21
>
> To: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov;
>
> auscope-geosciml at lists.arcs.org.au
>
> Cc: Robin, Alexandre
>
> Subject: [Auscope-geosciml] RE : CGI Value abomination [SEC=UNCLASSIFIED]
>
>  
>
> There still the WFS issue.
>
>  
>
> If one of the requirement is to be WFS (Filter) queriable, I don't 
> think we
>
> can go sweCommon. At least not with any softtyping solutions.  This said,
>
> there are already many GeoSciML reasonnable queries that we can't do in
>
> ogc:Filter.
>
> Eric
>
>  
>
> ________________________________
>
>  
>
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
>
> Date: jeu. 2009-09-03 04:43
>
> À: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
>
> Cc: 'Robin, Alexandre'
>
> Objet : Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]
>
>  
>
>  
>
> Steve, Eric, John -
>
>  
>
> I think you have a strong understanding of the requirements.
>
> Can I suggest you engage with Alex Robin directly.
>
> I'm sure he would be very pleased to assist, if it led to the adoption of
>
> sweCommon in GeoSciML.
>
> Right Alex?
>
>  
>
> Simon
>
>  
>
>  
>
> --------------------------------------------------------
>
> Simon Cox
>
>  
>
> European Commission, Joint Research Centre Institute for Environment and
>
> Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 
> 2749,
>
> I-21027 Ispra (VA), Italy
>
> Tel: +39 0332 78 3652
>
> Fax: +39 0332 78 6325
>
> mailto:simon.cox at jrc.ec.europa.eu <mailto:simon.cox at jrc.ec.europa.eu>
>
> http://ies.jrc.ec.europa.eu/simon-cox
>
> <http://ies.jrc.ec.europa.eu/simon-cox>
>
>  
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/ <http://sdi.jrc.ec.europa.eu/> IES
>
> Institute: http://ies.jrc.ec.europa.eu/ <http://ies.jrc.ec.europa.eu/>
>
> JRC: http://www.jrc.ec.europa.eu/ <http://www.jrc.ec.europa.eu/>
>
>  
>
> --------------------------------------------------------
>
>  
>
>  
>
>  
>
>  
>
> ________________________________
>
>  
>
>         From: auscope-geosciml-bounces at lists.arcs.org.au
>
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M
>
> Richard
>
>         Sent: Wednesday, 2 September 2009 21:10
>
>         To: auscope-geosciml at lists.arcs.org.au
>
>         Subject: Re: [Auscope-geosciml] CGI Value abomination
>
> [SEC=UNCLASSIFIED]
>
>  
>
>  
>
>         The swe abstract data components all have a Quality property, 
> which
>
> is a union that includes a categoryQuality and textQuality. Can the 
> kind of
>
> qualifiers we're using (always, common, never, sometimes, rare, equalTo,
>
> greaterThan, lessThan, approximate, quadratic mean, ...mode, median) be
>
> accounted for using categoryQuality? CategoryQuality appears in the 
> sensorML
>
> v.1.0 uml in HollowWorld, but a search of the pdf for SensorML (OGC 
> 07-000)
>
> gets no hits on categoryQuality, so there's not any discussion of the
>
> intention of the quality category.
>
>  
>
>         can swe:singleConstraint account for greaterThan, lessThan type
>
> bounding value declarations?
>
>         the quadratic mean, harmonic mean, geometric mean, arithmetic 
> mean,
>
> mode, median have to do with the observation procedure, but how does swe
>
> attach those to data?  Using abstractDataComponent.definition URI?
>
>         always, common, sometimes seem like possible quality categories.
>
>         'Never' is only necessary for defining descriptions where the
>
> presence of some property precludes membership in a category -- I don't
>
> think it would appear in any kind of occurrence description. This kind of
>
> information should be encoded with OWL or something like that anyway, so
>
> maybe we can deprecate it.
>
>  
>
>         So maybe don't need to change swe?
>
>  
>
>         BUT...
>
>         SWE does not appear to have a CategoryRange that would account for
>
> CGI_TermRange.
>
>         We still have the case brought up by Bruce or Ollie of geophysical
>
> data for which there is a value range and a typical or preferred value
>
>  
>
>         Maybe these could be accounted for with some elements derived from
>
> swe:dataArray?
>
>  
>
>         steve
>
>  
>
>  
>
>         Simon Cox wrote:
>
>  
>
>                 But if it is a common requirement, there should be a 
> common
>
> slot for it,
>
>                 rather than making it part of the tuple definition.
>
>                 The latter is pretty much back to free-text.
>
>  
>
>  
>
>                 --------------------------------------------------------
>
>                 Simon Cox
>
>  
>
>                 European Commission, Joint Research Centre,
>
>                 Institute for Environment and Sustainability,
>
>                 Spatial Data Infrastructures Unit, TP 262
>
>                 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>
>                 Tel: +39 0332 78 3652
>
>                 Fax: +39 0332 78 6325
>
>                 mailto:simon.cox at jrc.ec.europa.eu
>
>                 http://ies.jrc.ec.europa.eu/simon-cox
>
>  
>
>                 SDI Unit: http://sdi.jrc.ec.europa.eu/
>
>                 IES Institute: http://ies.jrc.ec.europa.eu/
>
>                 JRC: http://www.jrc.ec.europa.eu/
>
>                 --------------------------------------------------------
>
>  
>
>                 -----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: Wednesday, 2 September 2009 19:22
>
>                 To: auscope-geosciml at lists.arcs.org.au
>
>                 Subject: Re: [Auscope-geosciml] CGI Value abomination
>
> [SEC=UNCLASSIFIED]
>
>  
>
>                 Can't the qualifier be modelled as a part of the complex
>
> value
>
>  
>
>                 Eg:
>
>  
>
>                 <gsml:result>123 15 23.5 APPROX</gsml:result>
>
>  
>
>                 Just a thought
>
>  
>
>  
>
>                 -----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 Simon Cox
>
>                 Envoyé : 2 septembre 2009 12:26 À :
>
> auscope-geosciml at lists.arcs.org.au
>
>                 Objet : Re: [Auscope-geosciml] CGI Value abomination
>
> [SEC=UNCLASSIFIED]
>
>  
>
>                 I was responding to John's mail, where he appeared to be
>
> saying 'some fields
>
>                 will never be interoperable' (because of institutional
>
> reasons). If we
>
>                 really think they aren't (and he may have a point here),
>
> then there is zero
>
>                 benefit and only cost in forcing a data provider to coerce
>
> their
>
>                 non-ineroperable data into complex structures.
>
>  
>
>                 Eric brought up SWE Common as a (more broadly accepted)
>
> alternative, though
>
>                 he pointed out that in practice SWE Common is as 
> permissive
>
> as CGI_Value
>
>                 (but probably has more code to support it - though I think
>
> it is only
>
>                 maintained by one person (Alex Robin) who does not 
> keep his
>
> documentation
>
>                 up-to-date).
>
>  
>
>                 If there is interest in looking at SWE Common as a
>
> replacement (I agree that
>
>                 it probably has more momentum, and Alex is very 
> diligent in
>
> publicizing it),
>
>                 but are concerned about the absence of _qualifiers_ (or
>
> anything else in
>
>                 fact) then can I suggest that this requirement is URGENTLY
>
> brought to the
>
>                 SWE Common v2.0 revision working group in OGC - they are
>
> actively working on
>
>                 v2.0, and my guess is it will be wrapped up in a matter of
>
> months.
>
>  
>
>  
>
>                 --------------------------------------------------------
>
>                 Simon Cox
>
>  
>
>                 European Commission, Joint Research Centre, Institute for
>
> Environment and
>
>                 Sustainability, Spatial Data Infrastructures Unit, TP 262
>
> Via E. Fermi,
>
>                 2749, I-21027 Ispra (VA), Italy
>
>                 Tel: +39 0332 78 3652
>
>                 Fax: +39 0332 78 6325
>
>                 mailto:simon.cox at jrc.ec.europa.eu
>
>                 http://ies.jrc.ec.europa.eu/simon-cox
>
>  
>
>                 SDI Unit: http://sdi.jrc.ec.europa.eu/
>
>                 IES Institute: http://ies.jrc.ec.europa.eu/
>
>                 JRC: http://www.jrc.ec.europa.eu/
>
>                 --------------------------------------------------------
>
>  
>
>                 -----Original Message-----
>
>                 From: auscope-geosciml-bounces at lists.arcs.org.au
>
>                 [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On
>
> Behalf Of Stephen M
>
>                 Richard
>
>                 Sent: Wednesday, 2 September 2009 18:15
>
>                 To: auscope-geosciml at lists.arcs.org.au
>
>                 Subject: Re: [Auscope-geosciml] CGI Value abomination
>
> [SEC=UNCLASSIFIED]
>
>  
>
>                 Simon--Interoperability is defined by some community of
>
> practice. Sure, some
>
>                 group could agree to some free text format for data
>
> interchange, but then
>
>                 they'd dispense with xml and OGC services entirely and 
> pass
>
> around
>
>                 tab-delimited text files.  We've been there, and know how
>
> well or poorly
>
>                 that works.
>
>  
>
>                 What is the problem with leaving the xml schema quite
>
> general, allowing for
>
>                 different value quantification schemes, with the
>
> understanding that
>
>                 communities wishing to share data using GeoSciML services
>
> will have to
>
>                 develop an application profile restricting some of the
>
> possibilities?
>
>                 The benefit of the model is in establishing patterns 
> for how
>
> this is done,
>
>                 so that each solution to the same problem is not 
> different.
>
>  
>
>                 To me the important question for Quebec is how much we can
>
> do using SWE,
>
>                 since the value quantification issue is certainly not 
> only a
>
> geoscience
>
>                 problem! Maybe replace CGI_Value with some element
>
> (swe:DataArray?) or
>
>                 elements from SWE. We need to analyze the places CGI_Value
>
> is used in
>
>                 GeoSciML (see list below), and figure out if there is more
>
> than one pattern,
>
>                 and decide if we need to change it.
>
>  
>
>                 steve
>
>  
>
>  
>
>  
>
>                         CGI_Value is used for:
>
>                         Bedding thickness
>
>                         Event age
>
>                         part proportion (GUPart, composition, rock
>
> constituent part) several
>
>                         geophyscial properties (magnetic susceptibility,
>
> permeability,
>
>                         porosity, CGI_PhysicalDescription) mapped feature
>
> position accuracy
>
>                         trend, plunge, azimuth and dip on orientation 
> values
>
> particle geometry
>
>                         description properties (grain size, sorting, 
> shape,
>
> and aspect ratio)
>
>  
>
>  
>
>  
>
>                 Simon Cox wrote:
>
>  
>
>  
>
>                         In that case you can make everything that is 
> not an
>
> 'interoperable'
>
>                         field just free-text.
>
>                         This would still say that CGI-Value could be
>
> dispensed with.
>
>  
>
>  
>
>  
>
> --------------------------------------------------------
>
>                         Simon Cox
>
>  
>
>                         European Commission, Joint Research Centre,
>
> Institute for Environment
>
>                         and Sustainability, Spatial Data Infrastructures
>
> Unit, TP 262 Via E.
>
>                         Fermi, 2749, I-21027 Ispra (VA), Italy
>
>                         Tel: +39 0332 78 3652
>
>                         Fax: +39 0332 78 6325
>
>                         mailto:simon.cox at jrc.ec.europa.eu
>
>                         http://ies.jrc.ec.europa.eu/simon-cox
>
>  
>
>                         SDI Unit: http://sdi.jrc.ec.europa.eu/ IES
>
> Institute:
>
>                         http://ies.jrc.ec.europa.eu/
>
>                         JRC: http://www.jrc.ec.europa.eu/
>
>  
>
> --------------------------------------------------------
>
>  
>
>                         -----Original Message-----
>
>                         From: auscope-geosciml-bounces at lists.arcs.org.au
>
>                         
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au]
>
> On Behalf Of
>
>                         Laxton, John L
>
>                         Sent: Wednesday, 2 September 2009 11:39
>
>                         To: auscope-geosciml at lists.arcs.org.au
>
>                         Subject: Re: [Auscope-geosciml] CGI Value
>
> abomination
>
>                         [SEC=UNCLASSIFIED]
>
>  
>
>                         The snag with limiting users to the number of
>
> formats they can use is
>
>                         that the chosen format may not match the user's
>
> database. We recently
>
>                         hit this with unitThickness defined as 
> CGI_Numeric.
>
> Fair enough you
>
>                         might think but in our database unit thickness 
> is a
>
> string with
>
>                         comments like 'c23m in Grantham area'. The
>
> unfortunate reality is that
>
>                         in lots of cases different data providers hold the
>
> same property in
>
>                         different formats. We could remodel them as 
> distinct
>
> properties for
>
>                         different formats (Ollie's option (b)) but this is
>
> only going to be
>
>                         worthwhile where we wish to query against the
>
> property. In most cases
>
>                         all we wish to do is deliver a property value and
>
> I'm not convinced it
>
>                         matters if the way BGS delivers something like
>
>                         ParticleGeometryDescription.sorting is different
>
> from the way AZGS
>
>                         does - we need to be realistic about the level of
>
> interoperability
>
>                         needed. Particular services can always specify 
> more
>
> restrictive
>
>  
>
>  
>
>                 requirements if needed as OneGeology-Europe is doing.
>
>  
>
>  
>
>                         John
>
>  
>
>                         -----Original Message-----
>
>                         From: auscope-geosciml-bounces at lists.arcs.org.au
>
>                         
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au]
>
> On Behalf Of
>
>                         Oliver.Raymond at ga.gov.au
>
>                         Sent: 02 September 2009 05:49
>
>                         To: Rob.Atkinson at csiro.au;
>
> auscope-geosciml at lists.arcs.org.au
>
>                         Subject: Re: [Auscope-geosciml] CGI Value
>
> abomination
>
>                         [SEC=UNCLASSIFIED]
>
>  
>
>                         I agree with Simon's sentiments.  But Rob's 
> comments
>
> have me confused.
>
>                         I can't see how making CGI_Value a 
> specialisation of
>
> another class is
>
>                         going to make the model more interoperable.  It
>
> still leaves users
>
>                         able to deliver some attribute values as 
> either term
>
> values, number
>
>                         values
>
>  
>
>  
>
>                 or ranges.
>
>  
>
>  
>
>                         The aim here is to:
>
>  
>
>                         a) limit users in the number of formats they 
> can use
>
> to deliver
>
>                         attribute values, and
>
>  
>
>                         b) redefine some model elements (eg: Age) so that
>
> they explicitly
>
>                         state, for example, "this attribute is for a
>
> numerical Age only" or
>
>                         "this attribute is for a term Age only", 
> rather than
>
> the existing
>
>                         "this attribute can be a numeric Age, or a 
> term Age,
>
> or a range of
>
>                         numeric
>
>  
>
>  
>
>                 and term Ages".
>
>  
>
>  
>
>                         Cheers,
>
>                         Ollie
>
>  
>
>  
>
>  
>
>  
>
>                 ...clipped...
>
>  
>
>                 --
>
>                 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
>
>  
>
>                 _______________________________________________
>
>                 Auscope-geosciml mailing list
>
>                 Auscope-geosciml at lists.arcs.org.au
>
>  
>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>                 _______________________________________________
>
>                 Auscope-geosciml mailing list
>
>                 Auscope-geosciml at lists.arcs.org.au
>
>  
>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>  
>
>                 _______________________________________________
>
>                 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
>
>  
>
> _______________________________________________
>
> Auscope-geosciml mailing list
>
> Auscope-geosciml at lists.arcs.org.au
>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>  
>
> _______________________________________________
>
> Auscope-geosciml mailing list
>
> Auscope-geosciml at lists.arcs.org.au
>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>  
>
>  
>
> _______________________________________________
>
> Auscope-geosciml mailing list
>
> Auscope-geosciml at lists.arcs.org.au
>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>  
>
>
> -- 
> 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.
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090904/1c881362/attachment.htm>


More information about the GeoSciML mailing list