Allow greater precision for control points in Geospatial Measures Dictionary
In the Adobe SDK Extension to the PDF (ISO32000) standard, Extension Level 3, there are several Array structures that encode a series of control points for Geospatial measurement.
In particular, we are interested in the /GPTS and /LPTS arrays in the Geospatial Measure Dictionary.
Since the elements of these arrays are PDF number objects, we can only expect a limited amount of floatingpoint precision to be preserved by PDF reader implementations (which typically represent PDF number objects as either 32bit integers or 32bit IEEE 754 singleprecision floating point). This amount of precision is often insufficient for workflows that involve recovering precise geospatial data from Geospatial PDFs.
For example, imagine we have a control point at the center of the court at Adobe Headquarters (latitude 37.33106, longitude 121.8937). Given that a 32bit float has ~7 digits of precision, we can expect to see at least some error in the last digit when we perform arithmetic using that control point and page point locations. In order to get a sense of the scale of the error, let's vary each coordinate by 1 on the last digit (eg. latitude 37.33105, longitude 121.8935): we get a location that is ~10 meters away from center of the court (nearby the southeast corner of the court). Thus, by commutativity, we could expect to be introducing error of that magnitude to all locations described by the Geospatial measurement frame.
In order to better preserve coordinate precision, it would be beneficial to amend the supplemental specification to allow a greater number of significant figures to be encoded in control point coordinates. This would eliminate the control points as a significant source of error (leaving only the page point coordinates, which could then at least be preserved in the maximum fidelity allowed by their own PDF number representation).
We suggest that this could be accomplished by allowing optional arrays, corresponding to the /GPTS and /LPTS arrays, that would store string objects instead of number objects. These objects could be parsed by the consuming application as floatingpoint values of arbitrary precision. These optional arrays would be included in addition to and in supplement to the /GPTS and /LPTS arrays, and could be ignored by applications that do not require that level of precision.

Jake Molnar commented
See the supplemental specification https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/adobe_supplement_iso32000.pdf at section 8.8.1 **Geospatial Features**