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

Stephen M Richard steve.richard at azgs.az.gov
Fri Oct 2 20:26:16 EDT 2009


Please see discussion of this on TWIKI at 
https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/NumericAgeDate
steve



Simon Cox wrote:
> 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
>>     
>
>
>
>
>   

-- 
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/20091002/3620f6bb/attachment.htm>


More information about the GeoSciML mailing list