[Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
Oliver.Raymond at ga.gov.au
Oliver.Raymond at ga.gov.au
Sun Oct 11 20:03:27 EDT 2009
Sorry for the delay. I got sidetracked by geologic specimens, and getting my head around ISO DQ and oXygen xml editor problems.
1. Some pedantic xml pickiness in StratigraphicDateEstimate/quality. DQ_ThematicAccuracy is abstract, so I think the quality element should look something like this?
<errorStatistic>2 sigma</errorStatistic> <!-- Should put error statistic here instead of in <nameOfMeasure>? -->
2. My vote is to go with StratigraphicDateEstimate, but with several comments:
i) GeologicTime schema needs to be upgraded from GML3.1 to 3.2
ii) Make sure there are no querying problems with this looong xpath: GeologicUnit/geologicHistory/GeologicEvent/numericAgeDate/CGI_NumericAgeRange/reportingAge/StratigraphicDateEstimate/position/TM_Coordinate/coodinateValue
iii) We investigate remodelling StratigraphicDateEstimate so that it is a specialisation of TM_Coordinate, not TM_Instant. This would better constrain it by avoiding the union options in TM_Instant/position/TM_Position (we don't need calendar and clock times in geology do we?). And, coincidentally, this would shorten the xpath by 2 elements.
iv) We state that the "Quality/../value/Record" element should be of type "Measure" for geological ages.
v) Quality/../frame and valueUnit look like they can be done by reference.
vi) We write scope notes for StratigraphicDateEstimate (what is meant by "status"?)
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Saturday, 10 October 2009 4:53 AM
To: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
My vote is to go for the full thing IIF we can provide stored queries. If the query is bound to the serialisation , I'd rather have the simpler form than having to explain user they have to write 1 yard long xpath to filter by age.
Eric (who still has to write a stored query implementation strategy for WFS 1.1.0)
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é : 9 octobre 2009 12:33
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
The silence has been resounding!
So, any opinions about whether to use the simpler, but home-brewed CGI_NumericAge or the existing, more complex StratigraphicDateEstimate for CGI_NumericAgeRange?
CGI_Numeric age provides simpler approach, but less inherited architecture for detailed linkages with metadata and GeologicTime elemetns for connection to geologic and observation foundation of age estimate.
StratigraphicDateEstimate is more complex, requires overlay of schematron or profile rules to really be interoperable, but allows much richer data content and linkage to GeologicTime model. May require GML 3.2....?
Stephen M Richard wrote:
Please see discussion of this on TWIKI at https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/NumericAgeDate
Simon Cox wrote:
There appears to be a misunderstanding here, and I completely disagree with
TM_Coordinate. BUT... there is a mandatory association with TM_CoordinateSystem
which involves defining a timescale based on clock and calendar. (See attached
picture to see the TM classes involved). Not very applicable to defining
the geological time frame.
TM_OrdinalReferenceSystem, TM_CoordinateSystem, TM_Clock and TM_Calendar
are the four different kinds of TM_ReferenceSystem.
I.e. they are alternatives - there is no dependency from TM_CoordinateSystem
to TM_Clock or TM_Calendar.
TM_CoordinateSystem is _exactly_ what you need to define the scale described
in the quote from the NAm Strat Code - i.e. an origin and a standard unit.
Perhaps missing is the ability to say 'positive backwards' but this would
be a minor extension to the ISO TM_CoordinateSystem class.
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA
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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GeoSciML