SHAPE_area and SHAPE_length are typically esri internal/reserved fields that hold you features geometry and other info. If you want to calculate an area and control the format and display, I would recommend creating a new field (e.g. I create a sqmi field for my area) and than calculatig from the SHAPE_area field as needed. This new field however will not update automatically if the geometry changes.
Thank you Rebecca for your reply.
I think that your suggestion can not be valid due to updated that can happen for the geometry as you mentioned above.
However, I guess it is much better to change the display for decimal number in ArcGIS server.
Is there an option or method to change the display of decimal number for ArcGIS server level?
All the Best,
The ArcGIS Server neither respect the number of decimal places nor showing the comma separator when it comes to Area and Length fields! Why does it fail to do so?
However, other web application doesn’t respect this neither!
It's interesting that ArcMap would honor the setting, but that may be because you're consuming the service in the same client that you previously configured the field in. The service is really just being rendered from an mxd type file anyway.
This is still a client side problem, though. In ArcGIS Online, by configured the attributes for the data, the display is changed for the data throughout the application:
Might be difficult to see but the Shape_Length field, (red outline), is not configured to use 1000 separators, and the Shape_Area field, (blue outline) is. In a popup and the attribute table, those settings are respected. ArcGIS Online by default set the Use 1000 Separator option to true.
Again, thank you for your kind replies.
These issues are a known limitation of float and double field types (esriFieldTypeDouble).
In fact, the bug logged for this issue was closed as a known limitation.
Map service query operation does not retrieve formatting.
This happens because the query operation returns raw data values and does not honor table formatting applied in ArcMap.
Floating-point numbers are represented in computer hardware as binary fractions.
Unfortunately, most decimal fractions cannot be represented as exact binary fractions.
The result of that is the decimal floating-point numbers entered into a double field are only approximated by the binary floating-point numbers actually stored in the machine. The cause of the issue is Double field type.
This is a limitation of Floating Point Arithmetic - https://docs.python.org/2/tutorial/floatingpoint.html#tut-fp-issues
I hope information above is helpful.