Re: (Angular/Linear/Scale) speed in C++ API

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
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj