Has anyone come across an issue where ArcGIS server changes the number it serves out?
Here is my example. Just a normal boat infrastructure table record:
FACILITY_NAME: North Wall Ramp
FACILITY_TYPE: Boat Ramp
LATITUDE: -27.517116 <------ this is float(126)
LONGITUDE: 153.006977 <------ this is float(126)
OBJECTID: 254
ArcMap will give me _EXACTLY_ that^ but when I publish it as a service ArcGIS server and query the endpoint it gives me this:
FACILITY_NAME: North Wall Ramp
FACILITY_TYPE: Boat Ramp
LATITUDE: -27.517115999999999998
LONGITUDE: 153.006976999999998
OBJECTID: 254
See how longitude and latitude are not right on ArcGIS server but they are right in ArcMap?
Does anyone know how to fix this? I believe this is a bug with ArcGIS server? Could ESRI get this on their to fix list if it can be confirmed as a bug?
Oracle 11g
ArcGIS Server 10.3.1
ArcMap 10.3.1
Solved! Go to Solution.
You're right, it's not just a python issue. It's just how computers work. Here's a page describing the overall problem with a few ways to fix it: The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
I generally round number value before displaying them in web applications. I use 5 decimal places for lat/long fields and 3 (or fewer) decimal places for most other data types. This is plenty accurate for the work my agency does. I've been know to do the same when passing data back to the ArcGIS server as well.
I suspect what you're seeing is a known issue associated with floating point arithmetic in python: 14. Floating Point Arithmetic: Issues and Limitations — Python 2.7.11 documentation
Just guessing here, but I suspect you're seeing this in server because python is being used to convert to result to a json object.
Very astute Bill! The issue mentioned in your post isn't only present in Python but other languages as well. For example there is this: http://stackoverflow.com/questions/7127114/net-floating-point-comparison
Unfortunately the system test team will not see "our computers and programming languages are dumb" as an excuse to pass a test case
Maybe there is a fix ESRI could do in storing the value as a string or something instead of a float to avoid a mismatch of the number in the database? (Understanding that this is just a good guess as the problem and may not be the issue with further investigation)
You're right, it's not just a python issue. It's just how computers work. Here's a page describing the overall problem with a few ways to fix it: The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
I generally round number value before displaying them in web applications. I use 5 decimal places for lat/long fields and 3 (or fewer) decimal places for most other data types. This is plenty accurate for the work my agency does. I've been know to do the same when passing data back to the ArcGIS server as well.
Bill Daigle, you've got me convinced since I've been looking around and finding the symptoms match every single mismatch of the data.
Would still like this to be addressed by ArcGIS Sever but will change the MXD to round at 6 decimal places. The number will still be mismatched to the database for decimals at 5 precision and will fail test cases but as least those at 6 should always be right since rounding is intelligent (I hope).