[PROJ] EPSG v10 update status

[Nyall Dawson]

On Mon, 12 Oct 2020 at 05:06, Even Rouault <even.rouault at spatialys.com> wrote:

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

Thanks!


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

That's correct.

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

Ok - thanks for the confirmation.

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

I believe this will need to be handled differently on a
format-by-format basis, depending on the constraints of the various
formats and their underlying standards (if any). But I strongly
suspect that specifying the epoch through the coordinate metadata will
eventually be adopted as the approach for at least those formats which
natively store CRS definitions as WKT strings. Like you've pointed
out, those formats which rely on a database lookup using a numeric key
(such as postgis) will need some other way/metadata table to store the
per-dataset coordinate epoch.

But if we take a step backwards and don't even consider any spatial
data formats themselves, on a conceptual level it definitely sits
within proj's "area of responsibility" to be able to read these epochs
from CRS WKT and utilise it when constructing coordinate operations
involving dynamic datums. (Hopefully we see some of the relevant
authorities from countries who are moving toward dynamic CRSes step up
and sponsor this support!)

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

Thanks again! I'm planning on exposing both the "is dynamic datum"
flag and the frame epoch information as part of a CRS'es metadata, so
that end users have a way to identify these without manually reading
the WKT strings...

Nyall



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