[Proj] Time dependent coordinate transformations

[Even Rouault]

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) ?

> 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.

> 
> 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 ?

> 
> 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)

> 
> 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.

> 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