nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ArcGIS Server Decimals elongated

MatthewRyan2

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

Find more posts tagged with

Accepted answers

BillDaigle

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.

All comments

BillDaigle

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.

MatthewRyan2

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)

BillDaigle

MatthewRyan2

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).

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.