[Auscope-geosciml] Proposed fix for GeologicEvent Numeric age

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Thu Oct 1 22:28:57 EDT 2009


I understand Simon's comments to suggest we should stay with TM_Period 
using TM_CoordinateSystem:

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. 

Bruce

GeoScience Victoria
EARTH RESOURCES DIVISION
Department of Primary Industries
Melbourne, Victoria
AUSTRALIA
Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155



stephen richard <steve.richard at azgs.az.gov> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au
26/09/2009 10:40 PM
Please respond to
steve.richard at azgs.az.gov; Please respond to
auscope-geosciml at lists.arcs.org.au


To
Oliver.Raymond at ga.gov.au
cc
auscope-geosciml at lists.arcs.org.au
Subject
[Auscope-geosciml] Proposed fix for GeologicEvent Numeric age






Thanks for sorting that out more completely Ollie!  Per Simon's question, 
it seems that the UnitOfMeasure element associated with Measure 
(CGI_NumericRange is based on ISO19103 Measure), can be used to describe 
the CRS with origin at 1950, positive older, measured in years? 

So the proposal on the table is to change the data type for numericAgeDate 
on GeologicEvent from TM_Period  to CGI_NumericAge.  I'll wait til a week 
monday (Oct 5) for any other discussion, then make the change in the v3 
trunk.

steve




Oliver.Raymond at ga.gov.au wrote: 
I agree. Time range for events is defined by 2 time positions, not a 
length of time.  This extract from the Nth American Stratigrapic Code 
suggests that the units (Ma) for these time positions are positive numbers 
with units = Ma:

"The age of a stratigraphic unit or the time of a geologic event, as 
commonly determined by numerical dating or by reference to a calibrated 
time-scale, may be expressed in years before the present. The unit of time 
is the modern year as presently recognized worldwide. Recommended (but not 
mandatory) abbreviations for such ages are SI (International System of 
Units) multipliers coupled with "a" for annum: ka, Ma, and Ga for 
kilo-annum (103 years), Mega-annum (106 years), and Giga-annum (109 
years), respectively. Use of these terms after the age value follows the 
convention established in the field of C-14 dating. The "present" refers 
to 1950 AD, and such qualifiers as "ago" or "before the present" are 
omitted after the value because measurement of the duration from the 
present to the past is implicit in the designation. In contrast, the 
duration of a remote interval of geologic time, as a number of years, 
should not be expressed by the same symbols. Abbreviations for numbers
 of years, without reference to the present, are informal (e.g., y or yr 
for years; my, m.y., or m.yr. for millions of years; and so forth, as 
preference dictates). For example, boundaries of the Late Cretaceous Epoch 
currently are calibrated at 63 Ma and 96 Ma, but the interval of time 
represented by this epoch is 33 m.y."

I had a play with making a CGI_NumericTimeRange element, defined by an 
upper and lower 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.

Another option was to utilise StratigraphicDateEstimate instead of 
TM_Coordinate, BUT... (i) the same problem with TM_CoordinateSystem arises 
and (ii) the StratigraphicDateEstimate inherits from TM_Position which 
allows more than just number age dates. (I think StratigraphicDateEstimate 
needs re-modelling.)

In summary, given the limitations of TM elements, Steve's proposal to use 
CGI_NumericRange to deliver numeric age values using the geologic 
timescale seems to be a good solution.

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 stephen 
richard
Sent: Saturday, 26 September 2009 3:30 AM
To: Simon Cox
Cc: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] boo-boo in GeologicEvent

I think we're talking about position on a timeline, with a CRS set up such 
that origin is 1950, and positive is older steve

Simon Cox wrote:
 
Yes - TM_Period is about a discrete interval, not uncertainty.

There is also the matter of whether 'age' means
- position on a timeline, a coordinate
   - the conventional origins make this a negative number for most
geological events
- amount of time embodied in (or 'since') the event, a quantity

I.e. interval- vs. ratio-scale.

Simon


--------------------------------------------------------
Simon Cox


-----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
stephen richard
Sent: Friday, 25 September 2009 14:00
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] boo-boo in GeologicEvent

There was some uncertainty on my part yesterday as to whether
TM_Period is the correct type for numericAgeDate. After studying the
ISO 19108 temporalSchema some more, I conclude its not; it only allows
a time coordinate specified by a single number, no uncertainty. I
recommend we change TM_Period to CGI_NumericRange; this is more
consistent with the rest of the model, represents what we want better,
and avoids another proxy for a
GML3.2 element for v. 3 testing.

steve
_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml 
<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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091002/cbcd3974/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25457 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091002/cbcd3974/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 14175 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091002/cbcd3974/attachment-0001.jpeg>


More information about the GeoSciML mailing list