Time dependent coordinate transformations
Chris Crook <ccrook <at> linz.govt.nz>
2015-01-05 08:01:25 GMT
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
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.
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.
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.
Proj mailing list
Proj <at> lists.maptools.org