In IOGP's P1/11 format geodetic transformation parameters are stored. Want to capture this information from proj.db
since PROJ is used to do transformations.
HC,1,1,0 is the Px/11 record defining the unit of measure. This record has a structure that mentions the base UOM of a UOM that is not the base unit. The EPSG database has a UnitofMeasure table that also has a reference to the base UOM. That field is TARGET_UOM_CODE.
In the proj.db database, the base UOM is hidden. It has a conversion factor, but to which UOM is not explicitly defined.
Add _AUTH_NAME and _CODE for the base of this UOM to the uint_of_measure table of proj.db
The EPSG UnitofMeasure table has two fields for conversion from/to the base UOM. It will be great if these fields can be kept in proj.db. They should be reflected in the Px/11 formats. Understand that it is inconvenient to have two fields instead of one for efficiency in calculations. It may be possible to add the two fields and keep the current conv_factor field.
In IOGP's P1/11 format geodetic transformation parameters are stored. Want to capture this information from proj.db
since PROJ is used to do transformations.
HC,1,1,0 is the Px/11 record defining the unit of measure. This record has a structure that mentions the base UOM of a UOM that is not the base unit. The EPSG database has a UnitofMeasure table that also has a reference to the base UOM. That field is TARGET_UOM_CODE.
In the proj.db database, the base UOM is hidden. It has a conversion factor, but to which UOM is not explicitly defined.
Add _AUTH_NAME and _CODE for the base of this UOM to the uint_of_measure table of proj.db
The EPSG UnitofMeasure table has two fields for conversion from/to the base UOM. It will be great if these fields can be kept in proj.db. They should be reflected in the Px/11 formats. Understand that it is inconvenient to have two fields instead of one for efficiency in calculations. It may be possible to add the two fields and keep the current conv_factor field.