Datum for geologic time is 1950

[ghobona]

Conventionally the datum for geologic time is 1950. This does not matter for big times, but becomes important for more recent times, including some carbon-14 dates. http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime

Reported 2019-04-26 via e-mail

[ghobona]

At the Leuven TC, the OGC-NA passed a motion to task the Temporal DWG with considering this proposal and making a recommendation for a way forward.

[ghobona]

@chris-little has accepted the task, on behalf of the Temporal DWG.

[dr-shorthair]

A little more digging: there are two timescales commonly in use for geology.

For most of the geological record, use millions-of-years-ago with a datum sometime around the present, precision doesn't support difference between 2000 or 1950 or 1CE. https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers mind you there was a lot of digruntlement when SI gazumped geology community, and grumbling around the fact that the symbol Ma confuses an amount with a coordinate.

For the last 100,000 years or so, use B.P. https://en.wikipedia.org/wiki/Before_Present Now the precision does require the datum 1950. Count in whole years.

So now I'm not so sure that the Ma scale should be changed. But we need to add the BP scale.

[ghobona]

At the 2019 TC meeting in Banff, the TC approved this motion from the Temporal DWG.

The Temporal DWG recommends that the OGC Naming Authority register both geological timescales as discussed:

Change the datum on  http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime to match http://resource.geosciml.org/classifier/cgi/geologicage/ma IUGS Commission for Geoscience Information “Geologic time - millions of years” 

Add a new CRS for ‘BP’, starting at 1950, and counting backwards in years

[ghobona]

Based on the motion approved by the TC, I propose we update the TemporalDatum element in http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime as shown below.

<TemporalDatum gml:id="geologic-time-crs_yz-td">
<description>
Temporal position expressed numerically scaled in millions of years increasing backwards relative to 1950.

Positions in geologic time are conventionally denoted in millions of years, measured backwards from the present, which is fixed to 1950 when the precision requires it.
</description>
<identifier codeSpace="http://www.ietf.org/rfc/rfc3986">%yz-td%</identifier>
<remarks>
Previous versions of this datum used the year zero as the origin, as by astronomical year numbering (1 BC in the proleptic Gregorian calendar).
</remarks>
<scope>not known</scope>
<origin>1950-01-01T00:00:00Z</origin>
</TemporalDatum>

We will also need to update the <remarks> element to say 'version 2'

[chris-little]

@ghobona The Datum for the "geologic-time-crs_yz-td" should be changed as you proposed for a version 2 and for consistency with the authoritative reference proposed by @dr-shorthair at http://resource.geosciml.org/classifier/cgi/geologicage/ma . The use of 1950 as datum is recommended by that source, and is intuitive to use if precision requires it.

The downside is there may be more opportunities for silly conversions: "Tyrannosaurus Rex lived 65 998 050 years ago" instead of "Tyrannosaurus Rex lived 66 000 000 years ago".

What does 'Evaluate and negotiate' mean?

[ghobona]

@chris-little Evaluate and negotiate means we iteratively create, revise and discuss the proposal until we arrive at an acceptable definition.

My attempt at a version 2 datum is shown in the comment above (https://github.com/opengeospatial/NamingAuthority/issues/8#issuecomment-548345732).

Would the shown datum work?

[chris-little]

@ghobona I am happy with your change. Not sure I have anything to hand to test it. I would like @dr-shorthair to agree too.

[dr-shorthair]

Does <origin> require an xsd:dateTimeStamp value? For the millions-of-years scale the precision is irrelevant and misleading.

[ghobona]

<origin> requires an xsd:dateTime. I note that xsd:dateTime would drop the time zone. Given the precision over millions of years, that would be fine.

datums.xsd has this.

<complexType name="TemporalDatumType">
<complexContent>
<extension base="gml:TemporalDatumBaseType">
<sequence>
<element ref="gml:origin"/>
</sequence>
</extension>
</complexContent>
</complexType>

...

<element name="origin" type="dateTime">
<annotation>
<documentation>
gml:origin is the date and time origin of this temporal datum.
</documentation>
</annotation>
</element>

[chris-little]

@dr-shorthair, @ghobona, I realised that having a Datum with high precision does leave open the possibility of silly and misleadng usage when the timescale is millions of years, but is a compromise to fit into the existing framework and not be too different from the other geological (carbon dating) timescale whree the precision is relevant.

Until dateTime type entities are replaced by more consistent CRSs, perhaps we can mitigate silly usage with some good examples somewhere?

[ghobona]

Related to https://github.com/opengeospatial/NamingAuthority/issues/17

[ghobona]

@chris-little To complete the action stated by the Motion passed by the 2019 TC meeting in Banff, we need access to the definition specified by http://resource.geosciml.org/classifier/cgi/geologicage/ma

Unfortunately, the definition is not accessible (i.e. currently returns a 400 error).

We have contacted the geosciml Website Admin.

[ghobona]

We have now received confirmation from the geosciml.org team that “there is no MA Concept or even Geologic Time vocab in CGI” and consequently http://resource.geosciml.org/classifier/cgi/geologicage/ma does not exist.

Based on this feedback, the definition of http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime will therefore be left unchanged.

If there is no objection by 2021-12-15 to leaving the definition of http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime unchanged, this GitHub Issue will be closed.