[Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]

Simon Cox simon.cox at jrc.ec.europa.eu
Sun Sep 27 05:23:49 EDT 2009


Oh dear. 
There appears to be a misunderstanding here, and I completely disagree with
the conclusion: 

> 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. 

Simon

>-- Original Message --
>From: <Oliver.Raymond at ga.gov.au>
>To: <steve.richard at azgs.az.gov>, <auscope-geosciml at lists.arcs.org.au>
>Date: Sat, 26 Sep 2009 04:41:50 +1000
>Subject: Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
>Reply-To: auscope-geosciml at lists.arcs.org.au
>
>
>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
>>
>> 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/>
>> --------------------------------------------------------
>>
>> -----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 <http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml>
>
>
>
>Attachment: CGI_NumericTimeRange.jpg
>
>_______________________________________________
>Auscope-geosciml mailing list
>Auscope-geosciml at lists.arcs.org.au
>http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml





More information about the GeoSciML mailing list