[PROJ] EPSG v10 update status

Even Rouault even.rouault at spatialys.com
Sun Oct 11 12:06:51 PDT 2020


Nyall,

> Is there any proj c api which can be used to determine whether or not
> a particular datum is dynamic? (i.e. to obtain this list without
> direct database querying).

proj_get_codes_from_database(
  ctx, "EPSG", PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME, false);

... which didn't work before you raised the question. I've added commits to the PR first part 
to fix that (and rebased part 2 on top of it)

On a given object proj_get_type() will also return 
PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME when appropriate

> 
> > for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the
> > frame reference epoch from the database and emit it in WKT. No/little
> > backward compatibility issue foreseen.
> 
> My interpretation of your PRs is that the answer is no, but just to
> confirm: does proj now have the capability to ingest coordinate
> metadata from a WKT string?

I assume you mean a construct like the below that associates a CRS and the coordinate epoch 
(2016.47), and also for understanding of other readers not familiar with it:

COORDINATEMETADATA[
	GEOGCRS["WGS 84 (G1762)",
		DYNAMIC[FRAMEEPOCH[2005.0]],
		DATUM["World Geodetic System 1984 (G1762)",
			ELLIPSOID["WGS 84",
6378137,298.257223563,LENGTHUNIT["metre",1.0]]
		],
		CS[ellipsoidal,3],
			AXIS["(lat)",north,ANGLEUNIT["degree",
0.0174532925199433]],
			AXIS["(lon)",east,ANGLEUNIT["degree",
0.0174532925199433]],
			AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",
1.0]]
	],
	EPOCH[2016.47]
]

The answer is no indeed. This is not something currently handled by PROJ.

I'm not clear if that construct is a solution for the need of storing a coordinate epoch. I don't 
think it would be legal for example to put it the gpkg_spatial_ref_sys table of a GeoPackage, 
which is to store CRS only, whereas we have here a tuple CRS + coordinate epoch (so there's 
no authority or code for the tuple itself). And that would be probably a bad design. For 
GeoPackage, I'd say that the gpkg_contents should have an addition column 
"coordinate_epoch" for that purpose, as this is fondamentally a property associated to the 
layer directly (assuming people don't need to store it per feature or per vertex !!!)

There would be interesting questions to how to deal with that WKT construct and the fact 
that a PROJ_COORD can also transmit a coordinate epoch... But the PROJ API is certainly not 
final regarding time-based transformation, as we don't have a proper way of asking "give me 
a tranformation from CRS A @ epoch T1 to CRS B @ epoch T2" (where CRS A == CRS B is a 
common case for "point motion operation"). I remember we discussed that a bit in a past 
thread.

> If so, is there any api in proj yet to
> retrieve the coordinate epoch from this metadata for a dynamic datum
> CRS?

In my updated pull request, for the sake of completness, I've added 
proj_dynamic_datum_get_frame_reference_epoch() that will return the 2005.0 of 
the DYNAMIC[FRAMEEPOCH[2005.0]] in the above example, which is something that 
characterize the definition of the dynamic datum itself, but not the coordinate epoch itself. 
I'm not sure if there is any use of that. It could potentially be used internally by PROJ for 
doing time-based transformations, but I'm not even clear if that would be really needed: for 
example time dependent Helmert transformations have an explicit reference epoch in them.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201011/90425bfa/attachment.html>


More information about the PROJ mailing list