I have noticed that there are values in my feature services that have been modified somehow from the time of submission of the survey to when it is written in to the feature service. For example:
We fill in decimal fields that are an esriFieldTypeSingle (Float in feature service). We only ever fill in x.xx to the hundredth place, yet when I look at the value in pro and click to edit or export the data, there are a ton more decimal places. This is a huge problem for data integrity.
We enter 8.6 for a pH result and the value that is stored in the feature service is 8.60000038. Our pH meters only read out 8.6 or 8.60 that is all there is no way we would have entered 8.60000038. this is not happening for one record or just but all. This is also across different surveys that write to this service. I have also looked at the other services I have and the same thing is happening.
This does not happen to fields that are decimal fields that are an esriFieldTypeDouble (Double in feature service)
Any ideas what is going on here?
This is a known issue with databases and the way that decimal values get stored when using single point float types. The problem occurs due to the way the data is stored as 32 bits in computer memory and only certain combinations of numbers can fit into the 32 bits. Here is some more very technical background information: https://en.wikipedia.org/wiki/Single-precision_floating-point_format
The best way to avoid this is to use the esriFieldTypeDouble field type as you have found, as this is based on double precision floating point format which allows a much wider range of values that are valid: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
I had no idea this was the case. I will only use Double moving forward. Thank you! Perhaps this type of information can be included in the types tab of the xls form, or perhaps a hotlink to where they can find more about types of selections. There are likely more people out there that do not have great database understanding that are building surveys and would like to understand better the ramifications of choices they make.
We have a similar issue with the number of decimal places being displayed in both explorer and survey123. In ArcGIS Pro, a number value will display in the pop-up with a small number of decimals but will contain many more when the Pro project has been saved as a mobile map package. Consequently, any numeric data passed from explorer to survey123 (via url) will contain many decimal places and is not ideal. I have already tried limiting the number of decimal places in the field properties (ArcGIS Pro).
Again, this is not an issue with limiting the number of decimal values being entered by a user in a survey123 form or how a number gets stored in the feature class, this is an issue with how numeric data is being passed from explorer (and I assume Collector) and displayed in survey123.