[Auscope-geosciml] preferredAge

Stephen M Richard steve.richard at azgs.az.gov
Mon Mar 22 13:50:54 EDT 2010


John--
the age query wouldn't involve lithology, but it would be messy, 
something like:

GeologicUnit/geologicHistory[/eventProcess/cgiTerm="uri.cgi....deposition"]/youngerNamedAge/GeochronologicEra/localizedGenericName="uri.cgi...Cambrian"

with likewise for eruption, intrusion, and assuming concept expansion to 
include any child processes subsumed by deposition, eruption, intrusion...

Alternatively
GeologicUnit/geologicHistory/youngerNamedAge/GeochronologicEra/localizedGenericName="uri.cgi...Cambrian"

would result in any Unit that has a Cambrian event in its history, and 
maybe that's what you mean by 'all Cambrian GeologicUnits'.

I still suspect that dealing with this kind of complexity is best done 
on the server/application profile side, using standard stored queries 
with 'common queryable' names like 'preferredAge'.

steve

On 3/22/2010 10:12 AM, Laxton, John L wrote:
>
> I don't think we need eventType.
>
> Without a preferredAge flag it would be extremely difficult to 
> construct a simple query such as 'get all Cambrian GeologicUnits'. You 
> would need to match a lithology type with an appropriate eventProcess 
> for all possible lithologies. For example in SimpleLithology there are 
> seven direct children of compound_material and you would certainly 
> need to go lower in the hierarchy for some classes like 
> composite_genesis_material (impact_metamorphic_material anyone?) to 
> distinguish different appropriate eventProcess values. To filter for 
> 'all Cambrian GeologicUnits' would require an extremely complex query 
> which in all probability would not get 100% recovery. This isn't a 
> step forward….
>
> John
>
> *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:* 22 March 2010 16:42
> *To:* auscope-geosciml at lists.arcs.org.au
> *Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it 
> [SEC=UNCLASSIFIED]
>
> Having a preferredAge boolean would be a convenience for some, but to 
> be useful, it would probably need to be required at least at the level 
> of an application profile. If non-expert (or lazy) users come to 
> depend on its presence to use for age assignments, it will break 
> things if its not there. From the data provider point of view, it 
> might then add a little extra work figuring out how to flag one event 
> in each history as 'preferred'. The purpose of a WFS is not map 
> portrayal, but data delivery, so on balance, I think preferredAge is 
> superfluous. Each provider can provide a WMS that displays geologic 
> units based on their idea of preferred age. As far as a WFS filter 
> criteria, people are more likely to get what they expect if they have 
> to decide what they mean by 'preferredAge' when they compose the query.
>
> Are we in agreement that EventType does not serve any purpose that is 
> not already accounted for by eventProcess?
>
> steve
>
> On 3/21/2010 4:55 PM, Oliver.Raymond at ga.gov.au 
> <mailto:Oliver.Raymond at ga.gov.au> wrote:
>
> Hi Bruce, John et al,
>
> / /
>
> /> ...  is not to provide additional information, just opinion....../
>
> How the data is delivered is often a matter of opinion.  One 
> organisation may choose to deliver a simple WFS for one purpose, while 
> another may chose to deliver a highly complex and detailed WFS for a 
> different purpose.  I see John’s request as just another use case. 
>  It’s not wrong, it’s just wanting to use the data for a different 
> purpose (ie, map display for a basic ‘normal’ geological map)
>
> / /
>
> /> Clients like OneGeology should provide a view of 'age' based on 
> their criteria (presumably deposition, intrusion, extrusion, peak 
> meatamorphism, but since it uses 'preferredAge' I've no certainty what 
> this means)...../
>
> But I do have certainty of what it means, because the eventProcess 
> attribute tells me what the event is. And if we write very specific 
> scope notes for preferredAge, we can be certain how preferredAge is to 
> be used (John will need to provide very, very specific scope notes 
> here to satisfy Bruce I think!).
>
> /> ...Other portals may choose a different criteria (eg last 
> deformation age). Users who access the data directly can write their 
> own filters to meet their purpose..../
>
> By having both eventProcess and preferredAge attributes on 
> GeologicEvent, users can perform either of Bruce’s and John’s use 
> cases.  It doesn’t have to be one or the other.
>
> One world in harmony.... :)
>
>
> Kumbaya, kumbaya... sing it!
>
>
> Cheers,
>
> Ollie
>
> -----Original Message-----
> *From:* auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au> 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of 
> *Bruce.Simons at dpi.vic.gov.au <mailto:Bruce.Simons at dpi.vic.gov.au>
> *Sent:* Monday, 22 March 2010 10:24 AM
> *To:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>
> *Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it 
> [SEC=UNCLASSIFIED]
>
>
> As you would expect I object!
>
> >In spite of potential ambiguities age is something that is recorded on 
> pretty much all geological maps.
> Yes, but there is usually additional information, either in the legend 
> (eg depositional environment) or accompanying explanatory notes, to 
> indicate what this age means.
>
> > are the ones that we (as the experts in the geological survey) 
> consider represent the age of the GeologicUnit ... For 
> interoperability all information should be in the data, not embedded 
> in queries.
> To specify that this is a 'preferredAge' of someone in the survey 
> without saying why this age is preferred or what the age represents is 
> not to provide additional information, just opinion.
>
> >I don't think telling users to work it out for themselves is a 
> sufficient response (we are meant to be the experts), or telling them 
> they can only get this information if the service is accessed through 
> a portal controlled by us with queries constructed by us.
> Its not about telling users to work it out for themselves, its about 
> allowing users and clients to use the data for the purposes they 
> require and providing sufficient information so they can. Clients like 
> OneGeology should provide a view of 'age' based on their criteria 
> (presumably deposition, intrusion, extrusion, peak meatamorphism, but 
> since it uses 'preferredAge' I've no certainty what this means). Other 
> portals may choose a different criteria (eg last deformation age). 
> Users who access the data directly can write their own filters to meet 
> their purpose.
>
> I repeat:
> "The preferredAge property was deprecated because it has no real 
> meaning, it is one age from the rocks geologicHistory, but with no 
> capacity to say why this is the one chosen."
>
> 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> <mailto:Oliver.Raymond at ga.gov.au>*
> Sent by: auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au>
>
> 22/03/2010 09:56 AM
>
> Please respond to
> auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>
>
> 	
>
> To
>
> 	
>
> <auscope-geosciml at lists.arcs.org.au> 
> <mailto:auscope-geosciml at lists.arcs.org.au>
>
> cc
>
> 	
>
> Subject
>
> 	
>
> Re: [Auscope-geosciml] Event type vocabulary? what is it 
> [SEC=UNCLASSIFIED]
>
> 	
>
>
>
>
> How’s this for a compromise option.....
>
> If we add an attribute to GeologicEvent called “preferred” (type = 
> Boolean, 1..1, nillable), would that satisfy John’s needs without 
> having to create a whole new event element?  Then it would be easy to 
> identify which of a series of GeologicEvents is the one intended to 
> map display.
>
> Opinions please?
>
> Cheers,
> Ollie
>
> /----------------------------------------------------------------------------------------------------------------/ 
>
> /Ollie Raymond/
> */ /*
> */National Advice, Maps and Standards Project/*
> /Geoscience Australia/
> */ /*
> */GeoSciML Design Group/*
> /IUGS Commission for the Management and Application of Geoscience 
> Information/
> / /
> /----------------------------------------------------------------------------------------------------------------/ 
>
> *Address:* GPO Box 378, Canberra, ACT, 2601, Australia *|* *ABN:* 80 
> 091 799 039
> *Ph:* +61 2 62499575 *|* *Fax:* +61 2 62499992 *|* *Email: 
> *Oliver.Raymond at ga.gov.au <mailto:Oliver.Raymond at ga.gov.au> *|* 
> *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>* 
> *
> National geological maps 
> http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp 
>
> Geoscience Australia web services 
> http://www.ga.gov.au/resources/applications/ogc-wms.jsp
>
> /----------------------------------------------------------------------------------------------------------------/ 
>
>
>
> --- 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> 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of 
> *Laxton, John L*
> Sent:* Friday, 19 March 2010 11:04 PM*
> To:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>*
> Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it
>
> Bruce,
>
> In spite of potential ambiguities age is something that is recorded on 
> pretty much all geological maps. In GeoSciML age comes with 
> eventProcess and eventEnvironment which gives more information on what 
> the preferredAge represents than has been provided on maps in the 
> past, but maybe we do need to be able to state the reason for 
> selecting an age more specifically. In OneGeology-Europe we are 
> providing a preferredAge for all GeologicUnits as a term range. For 
> many GeologicUnits we will also provide a full geologicHistory. I am 
> not clear how we could do this when preferredAge has been deprecated 
> as there is no way we can say which GeologicEvent(s) in the 
> geologicHistory are the ones that we (as the experts in the geological 
> survey) consider represent the age of the GeologicUnit. I don't think 
> telling users to work it out for themselves is a sufficient response 
> (we are meant to be the experts), or telling them they can only get 
> this information if the service is accessed through a portal 
> controlled by us with queries constructed by us. For interoperability 
> all information should be in the data, not embedded in queries.
>
> What will happen I suspect is that people will simply use 
> geologicHistory as a preferredAge (ie with just one GeologicEvent), 
> but that is then throwing away the ability to record a proper 
> geologicHistory.
>
> John
>
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au> 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of 
> *Bruce.Simons at dpi.vic.gov.au <mailto:Bruce.Simons at dpi.vic.gov.au>*
> Sent:* 18 March 2010 22:24*
> To:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>*
> Cc:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>; 
> auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au>*
> Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it
>
>
> John,
> The Question "How old is the rock? is meaningless.  It is dependent on 
> the context. Within traditional paper maps we provide that context by 
> the 'type' of geological map and the legend. GSV has different maps 
> where the rocks that make up the Omeo Metamorphic Complex are 
> variously shown as Ordovician (age of deposition), Silurian (age of 
> regional metamorphism), Devonian (age of contact metamorphism) and 
> Tertiary (sic - age of recent uplift).  Which of these represent an 
> age of the rock depends on the end users requirements.
>
> Presumably a client like the OneGeology portal will want to display an 
> "age" map which represents depositional or intrusive age. The 
> eventProcess/eventAge couplet allows the client to derive this, or if 
> a WMS, derive a legend explaining what age means.
>
> The preferredAge property was deprecated because it has no real 
> meaning, it is one age from the rocks geologicHistory, but with no 
> capacity to say why this is the one chosen.
>
> 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
>
> *"Laxton, John L" <jll at bgs.ac.uk> <mailto:jll at bgs.ac.uk>*
> Sent by: auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au>
>
> 19/03/2010 03:42 AM
>
> Please respond to
> auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>
>
> 	
>
> To
>
> 	
>
> "steve.richard at azgs.az.gov" <mailto:steve.richard at azgs.az.gov> 
> <steve.richard at azgs.az.gov> <mailto:steve.richard at azgs.az.gov>
>
> cc
>
> 	
>
> "auscope-geosciml at lists.arcs.org.au" 
> <mailto:auscope-geosciml at lists.arcs.org.au> 
> <auscope-geosciml at lists.arcs.org.au> 
> <mailto:auscope-geosciml at lists.arcs.org.au>
>
> Subject
>
> 	
>
> Re: [Auscope-geosciml] Event type vocabulary? what is it
>
>
> 	
>
>
>
>
>
> Steve,
>
> At present data providers generally give a GeologicUnit an age and I 
> would be wary about moving from this to telling users 'these are the 
> ages of all the things that have happened to the rock, pick which age 
> you want'. The latter approach implies that all users wanting the age 
> of a rock will be aware of what the most significant event in the 
> geologicHistory is which I doubt is always the case. We have to assume 
> that our data is not just going to be accessed through clients under 
> our control and with queries created by us.
>
> Maybe asking how old a rock is isn't as simple a question as it 
> sounds, but it is one we have traditionally answered and I think we 
> need to continue to do so.
>
> John
> *
> From:* Stephen M Richard [mailto:steve.richard at azgs.az.gov] *
> Sent:* 18 March 2010 16:16*
> To:* Laxton, John L*
> Cc:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>*
> Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it
>
> John--I think the logic is that one would have to pose the 'how old is 
> the rock' question by specifying the process of interest that defines 
> what 'how old' means. For sedimentary and igneous rocks, the answer is 
> generally simple-- deposition, intrusion, or eruption, for altered or 
> metamorphic rocks (composite genesis), the answer could be cooling, 
> peak metamorphism, or protolith deposition, intrusion, or eruption.
>
> This issues is a good example of use of the interchange format for 
> information encoding vs. a geologist-friendly query language. Same 
> issue that was the basis for the recent geologic unit morphology 
> discussion. I think the stored query approach with a 'common 
> queryable' element (like CSW common queryables) for 'preferred age' is 
> a better solution to the problem, because preferred age depends on the 
> user in some cases (design decision is are there enough of these cases 
> to allow flexibility?).
>
> steve
>
> On 3/18/2010 8:56 AM, Laxton, John L wrote:
> Steve,
>
> I think we have got confused somewhere here!
>
> The v2 preferredAge was there to answer the question 'How old is the 
> rock?'. After deprecating preferredAge in order to answer the same 
> question there needs to be a way of flagging one of the events in the 
> geologicHistory as being the one that is deemed to represent the age 
> of the rock. I don't see how this can be achieved with a query on 
> eventProcess and numericAgeDate so I don't see how Action 15 from 
> Quebec follows from the decision to deprecate preferredAge. That said 
> I don't see how a query on eventType would either. I think eventType 
> may have been introduced simply to follow the typing pattern used 
> elsewhere (eg faultType), but faultType was introduced because of the 
> complexity of querying for commonly used concepts such as 'reverse 
> fault' without such a property. I'm not sure there is a similar use 
> case for eventType, and as you say there is a danger of confusion with 
> eventProcess and eventEnvironment. I think the requirement I 
> identified for the ability to relate local events to larger scale 
> events such as orogenies is best met through the use of  a classifier.
>
> So:
>
> 1. I'm unclear of the requirement for eventType and unless there is a 
> clear use case for it it might be best dropped
>
> 2. I'm unclear how we can replicate the preferredAge concept with 
> geologicHistory
>
> John
> *
> From:* auscope-geosciml-bounces at lists.arcs.org.au 
> <mailto:auscope-geosciml-bounces at lists.arcs.org.au> 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of 
> *Stephen M Richard*
> Sent:* 17 March 2010 17:46*
> To:* auscope-geosciml at lists.arcs.org.au 
> <mailto:auscope-geosciml at lists.arcs.org.au>*
> Subject:* Re: [Auscope-geosciml] Event type vocabulary? what is it
>
> Yikes-- We added Classifier on event as well. That would be the 
> logical place to have association of an event with a specific geologic 
> event that might be reused (like Hercynian Orogeny, K-T boundary 
> impact) and have its own GeologicEvent prototype description.
> So what use does that leave for EventType. The only one I can see that 
> doesn't create confusion with eventProcess -  eventEnvironment is to 
> use it in the sense of GeologicUnitType as a category that specifies 
> variations in the content model/intention of the actual GeologicEvent 
> element ('type' in the sense of data type). Examples --extended event 
> (orogeny), instantaneous event (bolide impact, volcanic eruption). 
> Maybe some coherent abstraction of the eventProcess vocabulary could 
> be made to categorize events that have different kinds of prototype 
> descriptions, but the danger is that if the eventTypes are just the 
> broader categories from the eventProcess vocabulary, then its unclear 
> which property to filter for those categories -- eventProcess or 
> eventType.
>
> steve
>
> On 3/17/2010 9:58 AM, Stephen M Richard wrote:
>
> EventType property on GeologicEvent feature scope notes currently 
> read: term 'to broadly categorise the type of event (e.g. 
> depositional, tectonic, biological, metallogenic)'. Figuring out what 
> should be in the EventType vocabulary opens a host of questions -- how 
> to categorize events?, what are the use cases?. Kinds of event would 
> be defined by process and environment by my reckoning, so it would 
> appear that EventType would act as a short cut for some combination of 
> eventEnvironment and eventProcess.
>
>
> ....snip...
>
>
>
> Does eventType implements this classifier concept?  That seems like a 
> potentially useful interpretation. In that case, something like the 
> OneGeologyEurope OrogenicEvent vocabulary is a gsml:EventType 
> vocabulary, and we get into the 'ontologic level' discussion about 
> names, classifiers, types etc. (see the Dec Twiki summary to review 
> that...). These categories are specific geologic events - they involve 
> geologic process, geologic environment, geologic age, and geographic 
> location.  This looks like a slippery slope. Does one look for the 
> depositional age by specifying the eventProcess or eventType?. Does 
> one look for structures related to the Laramide orogeny by specifying 
> the GeologicEvent/gml.name, or specifying the EventType...
>
> steve
>
>
>
> snip...
>
>
>
> -- 
> 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 <mailto:steve.richard at azgs.az.gov>
>
> -- 
> 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.
>
>
> -- 
> 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 <mailto:steve.richard at azgs.az.gov>
>
> -- 
> 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 
> <mailto:Auscope-geosciml at lists.arcs.org.au>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
> Notice:
> This email and any attachments may contain information that is 
> personal, confidential,
> legally privileged and/or copyright. No part of it should be 
> reproduced, adapted or communicated without the prior written consent 
> of the copyright owner.
>
> It is the responsibility of the recipient to check for and remove 
> viruses.
>
> If you have received this email in error, please notify the sender by 
> return email, delete it from your system and destroy any copies. You 
> are not authorised to use, communicate or rely on the information 
> contained in this email.
>
> Please consider the environment before printing this email.
>
>
>
> -- 
> 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 
> <mailto:Auscope-geosciml at lists.arcs.org.au>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
> "D卌#9ߓM4­Ÿԅ8Ԭ7㓽‑[1]8b隊Vu򪛚rۦk'(֢)ߢ*'ʞʧjW(z{bjPQ 
> 蚖\+╨‑uݾܢmSLSM��⪓h�.֞ꫡۜy֝j^vܢi'翔㓔㓽‑[1]*+¸霢{‑ڟm ޯ񎵿ŸԿ<񎵻"ͭ8ԟiǀ&"جzʨțXʇ 
> 텪޲*bz{mȞrG譩ݭ騽뢮랳񎵿ŸԿ<񎵷ڱૉl7!zz+޶آ隊Xz讙^jǧ؟ʘ^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮 
> '('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf񎵿ϼSM��⪗(��҈{c幫‑r쉗y֞~ަ)඘zf񎵿ϼSM��⪛"ͭ㓝)󧮊
>
>   
>   
> _______________________________________________
> Auscope-geosciml mailing list
> Auscope-geosciml at lists.arcs.org.au  <mailto: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  <mailto:steve.richard at azgs.az.gov>
>
> -- 
> 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. 

-- 
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/20100322/6dc5cea2/attachment.htm>


More information about the GeoSciML mailing list