[Proj] Time dependent coordinate transformations

[Chris Crook]

I'm wanting open a discussion around how to handle time dependent coordinate transformations.  These are becoming far more relevant to GIS data sets and positioning than they have historically been.

This is a growing issue for which I'd like to find the right forums and process to ultimately have have widely supported in coordinate transformation implementations, so please suggest or forward other appropriate forums.

I'm posting initially to the PROJ list as PROJ underlies much of the coordinate system transformations in the open source GIS stack, and does include datum transformations as well as projections.  However this is clearly a wider issue .. as I suggest below I think this affects the definition of spatial features generally - so I'd welcome suggestions for more appropriate or additional forums.


The background
==============

Coordinate systems are based on geodetic datums.  These are generally either international datums, such as WGS84 or ITRF realisation, or national datums defined by a country's geodetic authority.

Within international datums apparently fixed features (such as buildings) are moving due to plate tectonics at rates of typically 5 cm/year.  This means that the WGS84 coordinate of a "fixed" point in 2000 would now miss that point by 75cm.

National datums are generally referenced to fixed marks within the country and provide a stable coordinate system, such that the coordinates of fixed marks are constant.

Obviously the conversion between international datums and national datums cannot be done without taking account of when the coordinates are applicable.

Typically GIS systems are in terms of national coordinate systems.  Generally they contain spatial definitions in terms of the national datum, with no timestamp, and assume that this provides a consistent coordinate system for comparing coordinates and performing the various spatial analyses that characterise GIS systems.  Features are generally assumed to be fixed, and operations such as testing overlaps and adjacency assume that the spatial defintions are in a common spatial reference frame.

Historically most data has been derived by observations relative to the national coordinate system and this has worked.

Now however precise point positioning systems are increasingly generating data in terms of international reference frames.  Similarly global systems such as satellite based remote sensing will generate data in terms of international reference frames.

How are these data to be brought to a common system and used within GIS systems?

Clearly this cannot be accomplished to sub-metre accuracy without time dependent transformations that account for tectonic movement.

What do the time dependent transformations look like?

On stable continents they are simply an extension of the Bursa-Wolf 7 parameter transformation in which each parameter also has an additional term representing its rate of change. Also there is a further parameter which is the reference date at which the time dependent component is zero.

However many countries also include deforming areas near tectonic plate boundaries which require more special treatment.  For example North America has the HTDP model which describes the deformation of the western edge of the continent on the North American/Pacific plate boundary lies.  In New Zealand the entire country straddles a plate boundary, and so the national datum is related to ITRF96 by a complex deformation model including a gridded velocity model, and gridded components for significant earthquakes.

The issues for the GIS software stack
=====================================

I believe there are two issues facing GIS systems in handling time based transformations.

1) Where are the parameters of time based transformations defined

2) When transforming a coordinate how is the time parameter included in the transformation API

It seems fairly straightforward to expand the definitions of coordinate systems in PROJ and the EPSG registry to include additional parameters.  The to_wgs84 parameters could readily be extended to include the 14 parameter plus reference epoch time dependent Bursa Wolf transformation.  Some datum transformations already include nested grids, so extending this to include grids with associated time functions also seems feasible.

However to be widely supported this will need appropriate standards to be defined for the common parameter sets of time dependent transformations.  (There may also a question of what reference datum the transformations are defined in terms of, if any.  The to_wgs84 parameters implies a WGS84 based reference datum, but in fact WGS84 is a series of datum realisations)

The second question is how a time parameter is supplied to a transformation function.  Logically this is associated with a feature.  Where the feature is not fixed in terms of the coordinate system it is not really meaningful to define coordinates without specifying an epoch at which they apply.  For example the ITRF2008 coordinates of a survey mark on a tectonic plate are correct only at the time at which they are measured.  So properly the time is part of the coordinate definition of a feature.

Where a feature is considered to be fixed in terms of a coordinate system the time can be discarded - this is the case for nearly all features in GIS systems today.  Because the feature is considered fixed, any time can be associated with the spatial definition for the purposes of transforming to another coordinate system.

I suspect that providing for a time coordinate as part of the spatial definition of features would involve modifying the OGC standard defining spatial features, as well as the various software stacks using them.

Summary
=======

So to paraphrase:

* coordinate transformations between international and local datums at sub-metre accuracy requires time dependent transformations
* coordinate system definitions therefore need to be expanded to allow defining time dependent parameterization in standard ways that can be widely implemented
* spatial definitions of features need to be expanded to include a time component, again so that this can be accessed in a standard way

Does this conclusion seem correct, and if so what is the process of making this happen?

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.