You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might be that using XmlRpc causes a loss of precision of the datum (8 digits quantised to 6 in my case), which was causing me issues. Looking into it, I wasn't able to quickly identify the cause (I got as far as looking into XmlRpc::XmlRpcValue::ValueArray), and so just overloaded nh_priv.getParam in geonav_transform.cpp with a vector<double>, which took about 2 minutes. I'm not sure if the loss of precision is a bug or an oversight but updating the source to overload getparam with a vector may be a good idea. This feature has been supported since groovy.
The text was updated successfully, but these errors were encountered:
Thank you for the comment. That is a little scary if XmlRpc is arbitrarily truncating datum values.
Can you provide any more details on the problem you were having? What were the issues that you observed, i.e., how was the loss in precision observed and can you provide some hints as to how to reproduce the problem?
Are you able to submit a pull request as a way to propose the change?
It might be that using XmlRpc causes a loss of precision of the datum (8 digits quantised to 6 in my case), which was causing me issues. Looking into it, I wasn't able to quickly identify the cause (I got as far as looking into XmlRpc::XmlRpcValue::ValueArray), and so just overloaded
nh_priv.getParam
ingeonav_transform.cpp
with avector<double>
, which took about 2 minutes. I'm not sure if the loss of precision is a bug or an oversight but updating the source to overload getparam with a vector may be a good idea. This feature has been supported since groovy.The text was updated successfully, but these errors were encountered: