1

Try to do this

enter image description here

and you'll get an error message. However you can easily get statistics on [FID] using Summary Statistics tool. Somebody has a good explanation of this? Also note that from within the table [FID] is treated like non-numeric 'field'.

Extended question:

Statistics on [FID] can be very quick way to complete many tasks. For example find duplicates stored in other field. In example below field [COORD] stores string equivalent of point coordinates: enter image description here

If I apply Summary Statistics tool, case field [COORD], statistics field [FID] and join resulting table back to original points table using [COORD]. I can find duplicate points using query

"pnts.FID" <> "st.FIRST_FID"

enter image description here

There are very many other tasks that can be accomplished using sequential record number.

My question is WHY one cannot perform statistics from TABLE VIEW(window), which is very fast way to perform statistics on the field, and at the same time this can be done using Summary Statistics tool. That is not so quick, because it is a long way down the tree System Toolboxes-Analysis Tools-Statistics.

  • 1
    The FID in a shapefile is not static, it changes all the time. When a shapefile is edited the FIDs are renumbered every time you save... why do you need a statistic on FID? Also, the FID is not actually in the table! Open a .dbf from a shapefile in Microsoft Excel (or equivalent) and you will see the field doesn't actually exist. – Michael Stimson Feb 5 '15 at 1:14
  • One of the things is finding duplicates in the table. Also can be very helpful with naming, e.g. multiple streams discharging to the same node. Yes I know that it is not in the table, this is why 'field' in my original Q – FelixIP Feb 5 '15 at 1:18
  • There shouldn't ever be a duplicate FID, they are managed by (in this case) Esri drivers. To use the FID for something meaningful create a field (I call mine bOID for beginning OID) and calc the field with your FID - now it's static. Refresh with a new copy whenever it's convenient or the values become too stale to trust. – Michael Stimson Feb 5 '15 at 1:22
  • 1
    It's treated like a non-numeric field because it's a special data type of 'Object ID' - it isn't a numeric. resources.arcgis.com/en/help/main/10.1/index.html#//… And in theory you can't have a duplicate FID, because the whole point is that FID/OIDs must be unique. If you do have duplicates, you've got an error. – Chris W Feb 5 '15 at 1:23
  • 1
    It may be better to ask a new question rather than extending this one, because to do so may invalidate the answer that @ChrisW has already expended effort into answering. – PolyGeo Feb 5 '15 at 2:16
3

An actual FID or OID field is not a numeric field. It is a special data type known as Object ID. See the help files

If you run some tool that outputs a table with an attribute field based on the FID, for instance Near, that field is of data type LONG.

If you perform a Summary Statistics on the actual FID field, the data is treated as a numeric type by the tool. If you attempt the same from the attribute table, it's treated as a string (hence the First and Last options, but none of the numeric). Actually, that's a somewhat faulty statement - it's more like a string. Since the FID is unique, you can get either the first or last value associated with each value in the field you're summarizing on. But math operations on such unique id values are meaningless, just like they would be for any text string values. So even though you can do it in Summary Statistics, the result doesn't mean anything. In much the same way Zip Codes aren't numbers, neither are FIDs even if they're represented by numeric characters.

I don't know for sure how it treats it with a join operation, but I believe it must be numeric based on the joins that are successful (doubt you can join based on the FID field to a string field even if the strings are matching numbers).

Depending on where you look at it, the OID can be converted to different data types (see last link) but within ArcGIS it is its own animal.

More info (including differences between OID and FID, including renumbering): http://support.esri.com/de/knowledgebase/techarticles/detail/37480 http://resources.arcgis.com/en/help/main/10.1/index.html#//019v00000002000000


So to summarize that big paragraph up there and answer why you can't run statistics on the FID field itself from the table is because those statistics are meaningless:

  • Count = number of records or that -1
  • Min = 0 or 1
  • Max = number of records or that -1
  • Sum is 1+2+3+4+5+6... + number of records or that -1

and so forth. Null might be useful, except in order to be an FID/OID the value cannot be Null, so that statistic would always be 0. Only your First/Last statistic, which can be accessed from either place, serves any purpose as you demonstrate in your example. But (and here I had an ah_HA! moment) you're right, that causes an error. The only explanation I can offer is that the attribute table Summarize and Summary Statistics are two different tools (hence you can use CASE with one but not the other) and must handle the Object ID data type in different ways. Technically, it shouldn't work in Summary Statistics (and even throws an error warning when you first set it, but does it anyway).

Similarly you cannot Summarize on the FID field because every value in FID is unique - hence the summary table will look exactly the same as the attribute table.

  • +1 from me simply because my question was not so clear, so you don't waste your efforts. I just think that ESRI should fix it and/or remove [FID] from the list. I mean TABLE VIEW – FelixIP Feb 5 '15 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.