[MetaCRS] Fwd: Re: [Proj] Time dependent coordinate transformations

Even Rouault even.rouault at spatialys.com
Mon Jan 5 13:36:50 PST 2015 

Re-adding metacrs.

----------  Message transmis  ----------

Sujet : Re: [Proj] Time dependent coordinate transformations
Date : lundi 05 janvier 2015, 22:23:50
De : Even Rouault <even.rouault at spatialys.com>
À : Chris Crook <ccrook at linz.govt.nz>
CC : "'proj at lists.maptools.org'" <proj at lists.maptools.org>, 
"'metacrs at lists.osgeo.org'" <metacrs at lists.osgeo.org>

Le lundi 05 janvier 2015 21:13:36, Chris Crook a écrit :
> 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.

https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 shows that 
there are 5 EPSG codes for the various NAD83 realizations in geodetic 
projections. Not sure that they all have associated corresponding projected 
systems though.

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

Agreed...

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

I meant that for HTDP, my impression with my limited testing is that you can 
actually specify one date for each of the both CRS and it will use each one, 
presumably using some pivot as a reference, to generate the final grid.

Transforming from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1991.0 gives a 
different result from NAD83(2011) at T=2011.0 into WGS84(G730) at T=1991.0, and 
different from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1986.0

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

Regarding proj4, there wouldn't be any particular difficulty to extend its API, 
being a string, to include a "+time=XXXX.YY" parameter. The difficulty would be 
more in the logic to make something usefull with that time parameter. For 
Bursa-Wolf with derivatives, this should be easy. For grids, less obvious.

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

The naive way of transforming/warping a raster dataset is to consider the 
coordinate of the center of each pixel and to transform it into the target 
reference coordinate and build an image from that, which is an already solved 
problem. So if we know how to do a time-dependant transform for a feature, no 
particular difficulty transposing that to the raster side. But I just wanted to 
mention it for the sake of completeness as a "user" of such transforms.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


-------------------------------------------------------
-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

More information about the MetaCRS mailing list