PROJ C++ API defines an osgeo::proj::common::UnitOfMeasure::Type enumeration with the UNKNOWN, NONE, ANGULAR, LINEAR, SCALE, TIME and PARAMETRIC values. For example the METRE is declared of the LINEAR, which is fine. But the following are more problematic:
METRE_PER_YEAR declared of type LINEARARC_SECOND_PER_YEAR declared of type ANGULARPPM_PER_YEAR declared of type SCALE
The consequence is that METRE_PER_YEAR is created by PROJ-JNI as an Unit of type Length while it should be a unit of type Speed. Same apply to other rate of changes unit.
There is no clean fix at this time since PROJ does not provides an API for determining that a unit of measurement is actually a rate of change instead than directly the specified type. A possible workaround could be to parse the unit name.
PROJ C++ API defines an
osgeo::proj::common::UnitOfMeasure::Typeenumeration with theUNKNOWN,NONE,ANGULAR,LINEAR,SCALE,TIMEandPARAMETRICvalues. For example theMETREis declared of theLINEAR, which is fine. But the following are more problematic:METRE_PER_YEARdeclared of typeLINEARARC_SECOND_PER_YEARdeclared of typeANGULARPPM_PER_YEARdeclared of typeSCALEThe consequence is that
METRE_PER_YEARis created by PROJ-JNI as anUnitof typeLengthwhile it should be a unit of typeSpeed. Same apply to other rate of changes unit.There is no clean fix at this time since PROJ does not provides an API for determining that a unit of measurement is actually a rate of change instead than directly the specified type. A possible workaround could be to parse the unit name.