[PROJ] (Angular/Linear/Scale) speed in C++ API
Even Rouault
even.rouault at spatialys.com
Wed Nov 27 15:19:24 PST 2019
Martin,
> But I find
> the following more surprising:
>
> * METRE_PER_YEAR declared of type LINEAR
> * ARC_SECOND_PER_YEAR declared of type ANGULAR
> * PPM_PER_YEAR declared of type SCALE
>
> I do not see an API for declaring that above units are rates of change
> (speed, angular velocity, etc.) rather than classic linear or angular
> units. Shouldn't the API contain something for that?
Yes, that's indeed odd. I just followed what EPSG does:
unit_of_meas_name (String) = metre per second
unit_of_meas_type (String) = length
target_uom_code (Integer) = 1026
unit_of_meas_name (String) = arc-seconds per year
unit_of_meas_type (String) = angle
target_uom_code (Integer) = 1035
unit_of_meas_name (String) = parts per million per year
unit_of_meas_type (String) = scale
target_uom_code (Integer) = 1036
As far as I can remember, there's no real functional impact of that arguable choice.
What matters for PROJ is that the factor_b/factor_c ratio is correct so that it
can normalize to the rate units it expects for the Helmert operator, which are,
unsurprisingly, the above ones :-) The only use of the unit type I can think
about now is when exporting to WKT: you need to know if you need to generate
a LENGTHUNIT[] vs ANGLEUNIT[] vs SCALE[] node.
Couldn't find in http://docs.opengeospatial.org/is/18-010r7/18-010r7.html an
example for a time-dependant operation nor more formal requirements, but
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::8070
uses those type of nodes for the units of the rate of changes
Could perhaps be worth a clarification in 18-010r7.
CC'ing Roger in case he has anything to add about that.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the PROJ
mailing list