ArcGIS 10.3.1 does not recognize Long Integer right

FilipKrál · ‎06-03-2015

Hi, I'm going through a puzzling experience with a shapefile that behaved as expected in 10.2 and which has a WBID column of type Long Integer storing values from 1 to 50235. In ArcMap 10.2.x on another machine and in Quantum GIS 2.2.0 this column loads as expected (Long Integer 1 to 50235).

However, In ArcMap 10.3.1 (on another machine) I can see the WBID column as Short Integer with values from -32767 to +-32767 (containing numbers from -32767 to -15301 and from 1 to 32767).

Have you ever experienced similar behaviour?

I'd be grateful for any hints.

Filip.

Message was edited by: Filip Král: Changed the title to better describe the issue.

XanderBakker · ‎06-03-2015

I haven't had this behavior... but what happens if you load the shapefile into a fgdb (on both machines) and revise the values of the field on the same and the other machine (so 4 tests). What do you see?

VinceAngelo · ‎06-03-2015

Your title is confusing. It seems you really want "10.3.1 mistakenly recognizes 32-bit integer column as 16-bit". How is the field defined in the dBase header? With width 5 I assume.

- V

FilipKrál · ‎06-05-2015

Hi, I changed the title to better describe the issue.

As far as I can tell, the width of the WBID column in the dbf header is undefined. This is how the dbf header looks in Notepad++:

Attached is a selection of some features with low and with high WBID and the issue persists:

In 10.1 and 10.2.2, it loads as Long Integer with only positive values. In 10.3.1, it loads as a Short Integer with some values positive and some negative.

To get around the issue I imported it to FGDB in ArcGIS 10.2.2, moved the FGDB to machine with 10.3.1 and exported it to Shapefile. That shapefile then worked correctly in 10.2.2 and 10.3.1. (Which partly addresses Xander's suggestion).

Can you see any problem?

Filip

LanceShipman · ‎06-05-2015

What you are seeing is a change to the behavior of dBase/Shapefiles introduced at 10.3.1. Normally a Short Integer can hold numbers from -32767 to +32767, but dBase doesn't store a Short. It stores an N type. Prior to 10.3.1 a Short was defined as a N 4. An N 4 can hold numbers from -999 to 9999. Not the full range of a Short. At 10.3.1 the Short definition (or our mapping of it) was changed to N 5 to allow a range of -9999 to +32767. In your case this changed the definition of a N 5, previously mapped as a Long, to a Short. This was change to fix a problem with silent truncation of -9999 to -999 in Short integer fields and to update the range allowed to be closer to what is normally allowed in a Short. This had some unintended consequences that we will be correcting in 10.4. .

FilipKrál · ‎06-08-2015

Thank you for the explanation Lance Shipman, it is good to understand what's going on.

I can't help myself from thinking that this is quite a serious issue. For many users possibly a show-stopper when it comes to migration from 10.2.x to 10.3.x. Do you know if there are any recommendations or knowledge-base articles related to this issue?

Any details and suggestions welcome!

Kind regards,

Filip.

MichaelVolz · ‎10-24-2015

Filip:

Does this mean that values get changed in the shapefile if used in ArcMap 10.3.x?

If so, could you give an example of how a value would be modified due to this change in how a shapefile is handled in ArcMap 10.3.x?

FilipKrál · ‎10-24-2015

Hi Michael Volz,

The exact problem I had is described in my original post. Basically, a shapefile created in 10.2.x had a WBID column of type LONG with values from 1 to 50235. When I loaded this to ArcMap 10.3.1 the WBID column properties indicated type SHORT and it had values from -32767 to -15301 and from 1 to 32767.

Note that 32767 is the upper bound of short integer.

I think 32768 changed to -32767, 32768 to -32766, ... and 50235 to -15301. I don't have ArcGIS on this PC but I attached a sample of that shapefile to my later post.

Filip.

MichaelVolz · ‎10-24-2015

Filip:

I have a shapefile with an OBJECTID field that is defined as Long Integer in ArcGIS Desktop v10.2.0 with a value of 40432. I updated this shapefile in ArcGIS Desktop v10.3.1 and it still showed this field as Long Integer and not Short Integer with the 40432 value intact. I thought according to your original post the Long Integer field would be converted to a Short integer field and the value would be modified.

Can you please help clarify these results with the results you are getting?

VinceAngelo · ‎10-26-2015

Basically, a shapefile created in 10.2.x had a WBID column of type LONG with values from 1 to 50235.

Let's be clear: Shapefiles do not support the concept of "long" or "short" types. All shapefiles can do is distinguish between numeric values with precision to the right of the decimal and those that don't. The mapping into types is done by ArcGIS. A "number with formatted width 5" is insufficient to determine whether it has a range of {-32768...32767} (a "short") or a range of {-9999...999999} (which would require a "long").

Attempting to encode "40432" into a short (16-bit) integer would result in numeric overflow. Thanks to the usual storage format ("twos complement"), I'd expect the overflowed value to be -25104 (40432 is 0x9DF0, which is interpreted as -32768 + 7664. Note that the values encoded into the shapefile aren't different (at least, upon read), they're just being interpreted differently.

- V