[Proj] Time dependent coordinate transformations

[Chris Crook]

Even

Thanks for the quick response and thanks for the suggestion of the MetaCRS list.

Comments below...

> -----Original Message-----
> From: Even Rouault [mailto:even.rouault at spatialys.com]
> Sent: Tuesday, 6 January 2015 12:32 a.m.
> To: proj at lists.maptools.org
> Cc: Chris Crook
> Subject: Re: [Proj] Time dependent coordinate transformations
>
> Chris,
>
> > 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 can imagine MetaCRS (http://trac.osgeo.org/metacrs /
> http://lists.osgeo.org/pipermail/metacrs) could also be associated
>
> >
> > The background
> > ==============
> >
>
> > 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.
> >
> [...]
> > However many countries also include deforming areas near tectonic
> > plate boundaries which require more special treatment.
>
> When you mention those national datums with fixed marks, how does
> NAD83 and its multiple realisations work with that ? I'm clearly not a
> geodesist,  but looking a bit on various sites, it seems that the coordinates of
> a fixed mark vary between the different NAD83 realisations, so can we speak
> of a national datum for the US (or New Zealand) ?

Sorry - the "with fixed marks" was a bit simplistic.

There certainly is an issue with versions  of datums, and this is another area which I'm not sure is
well handled with the current coordinate system registries.

For example in New Zealand each update of the deformation model (which relates
NZGD2000 to ITRF96) effectively defines a new version of NZGD2000.  Should this be treated as a new
coordinate system in EPSG and other registries.  If so, then all 30+ projections based on NZGD2000 will
also need to be recreated.   For most users of NZGD2000 this would just be a nuisance, but for some
it would be preferred I think.

> > 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.
>
> Regarding HDTP, Frank Warmerdam had implemented a tool to make them
> available for proj.4 use : https://trac.osgeo.org/proj/wiki/HTDPGrids . But
> this is clearly more a ad-hoc solution than the more general/automated
> solution you're looking for.

I have seen that, and a similar approach could be used for one-off transformations
in New Zealand.  However that doesn't feel like the right approach in the long term.
On the other hand any systematic change to handle time dependent transformations
will doubtless take a long time to be widely implemented, so it is great to have work
arounds in the mean time!

> >
> > 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.
>
> Agreed although in the case of HTDP, the production of grids result from the
> result of a (apparently complex) computation process where you have to
> provide
> src_crs, src_crs_date, dst_crs and dst_crs_date. Regarding proj.4 one could
> have a fixed (dst_crs, dst_crs_date) by convention, but one would still have
> varying src_crs_date for a given src_crs. Perhaps pre-generate grids for each
> year and linearly interpolate between them ?

I believe that there is just one one date for these transformations.  This is not
about predicting where a feature might be at another time, it is about transforming
between coordinate systems which are related by a time dependent function.  Of
course if the feature is considered to be fixed in one of those coordinate systems then
the effect of transforming at different dates is to track it's trajectory in the other.

Also many national datums (including New Zealand) are defined in terms of a reference
epoch, so calculating coordinates in terms of that datum can be thought of as
converting coordinates to that epoch.   In New Zealand that is how we have described
NZGD2000 until recently.

I think that is a bit misleading though - after we may be defining the coordinates of
a building that did not even exist at the reference epoch.    And clearly it is not possible to
access the features at any time other than the present.

I believe it is more correct to think of the reference epoch as a time at which the
national coordinate system coincided with some international system it was defined
in terms of.  However at other times it is offset from the international system by an
approximately known amount representing the total movement of the tectonic plate
on which the nation lies.  Hence the time dependent transformation.

> >
> > 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)
>
> I can imagine that the "pivot" WGS84 could be an arbitrarily chosen WGS84
> realization (hoping that the use of 2 successive shifts will not harm too much
> precision)

I think an approach like this is possibly the best that can be done practically.
There are multiple published relationships between different international datums, and
between them and national datums, which means that the relationships are not
unambiguously defined.  I'm not sure how this could usefully be included in coordinate
system registries and transformations.

> >
> > The second question is how a time parameter is supplied to a
> transformation
> > function.  Logically this is associated with a feature.
>
> Yes, if you consider that a dataset can contain a collection of features whose
> coordinates have been collected at different times. But one could also
> assume
> that within a dataset, they all refer to the same time (this would be similar
> to considering that in a dataset you don't mix features with coordinates in
> different SRS, which is the usual practice), couldn't we ? In which case the
> time parameter could be a property of the SRS, or presumably next to the
> SRS
> (since SRS can be transported by codes, and you can't code each different
> time).
>
> There's also the topic of raster maps (for high precision mapping) that could
> also be affected by time dependant transformations. But in that case it is
> obvious that a single time must be considered for the whole map.

I'm not thinking that datasets will generally have different times (even if the data
were originally collected that way).  More that the transformation API's ultimately
work on coordinates.  So even if a feature's coordinates are not stored with a time,
the dataset time could be assigned to the feature in preparation for the transformation
(in the same way as we might set a SRS id to a feature).

The question here is whether to have a separate API for transformations that require
a time, or whether to use the same API and embed the time within the
feature/coordinate being transformed.

In terms of implementation I guess there will be efficiencies in preparing a transformation
for a specific epoch - in effect defining a transformation object which is used for transformations
and which can cache prepared transformations.  I'm not sure how this will sit with existing API's.

I'm not familiar with transforming raster maps, though I imagine the process would be
to transform a set of reference coordinates that are used to morph the raster?

> > 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.
>
> If we include it in WKT/WKB representation of geometries yes. I'd note that
> currently WKT/WKB doesn't even include SRS ID, but PostGIS extended
> variants
> do.
>
> Which brings also the interesting topic of how existing GIS formats could
> transport the time information...
>
> >
> > 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?
>
> Perhaps approaching the various OGC working groups of the related
> standards to
> see if there have been thoughts/work related to that ?
>
> Best regards,
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com

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.