Looked into this...

The handling/placement of IExprType is entirely broken in the JR code.

It should be an interface on the data returned by the GeoPointData container, not an
interface on the container itself.

This mis-coding was hidden due to the order if the instanceof tests in the XPathFuncExpr
class' implementations of toNumeric, toBoolean, toString.


The toBoolean and toString behaviors work as intended just by accident.

Should probably rework all the data types except int, numeric and string (e.g., all
the date and time types) to use IExprType and should test for this type first in the
XPathFuncExpr logic.

This is likely why the date-time logic remains completely broken w.r.t. type conversions.

Also faced this issue here needing to check GPS accuracy.  Came up with an ugly workaround
as:
number(substr(geopoint, string-length(geopoint)-5))

However this only works reliably for accuracy between 10 and 999m

Another work-around might be

selected-at(/data/geopoint, 3)

Assuming the geopoint value is converted early to a string, this should pick out the
accuracy value.