4

The shapefile specification (http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf) only says "Record numbers begin at 1." (page 5), which doesn't specify what the field actually is. As per page 25, each shape feature must correlate to exactly 1 record in the DBF, and their order must be identical. So the "Record Number" field is not for any purpose related to the DBF. My interpretation is that the "Record Number" field is required to count up from 1 to the number of shape features in the shape file. But this being completely redundant, I am unsure whether I missed something?

Some clarifications after reading your answers and comments:

  1. I am writing a reader/writer for shapefiles, so I need to parse them correctly as well as produce valid output.
  2. Shapefiles as well as DBF files have an "intrinsic" record number (let's call them A and B). The first shape / record after the header in the shapefile / DBF has A=1 / B=1, the next has A=2 / B=2, and so on. The shapefile specification clearly states that the shapes and records have a one-to-one relationship based on these numbers, so the attributes for shape A=1 are contained in record B=1, and so on. Neither A nor B is the "Record Number" field I am asking about.
  3. Each shape in the shapefile also has an (explicit) INT32 field in its shape header, which is called "Record Number" in the shapefile specification. This is where my confusion starts. Let's call this value C. The specification requires that this field starts at 1 (so for shape A=1, it must be C=1). But it doesn't give any other rules (such as "increment C by 1 for each shape"), nor does it give any semantic meaning to this field. So it seems to me that C is indeed meaningless. But if that is true, the shapefile is bloated by 4 unneeded bytes for each shape, which seems weird to me. So I want to be sure I am not missing anything...
  4. I have no idea where things like "FID, OID, OBJID, or OBJECTID" come from. I am not using any ESRI products, but glancing at http://support.esri.com/es/knowledgebase/techarticles/detail/37480 I conclude that those are properties / attributes some ESRI products use and store in the DBF file associated with the shapefile. If that is so, this has nothing to do with my question.
Improve this question
2
  • 1
    Check out support.esri.com/es/knowledgebase/techarticles/detail/37480. From that is this statement: In a shapefile, the 'FID' field contains the ObjectID, and the values start at zero
    – John
    Commented Mar 27, 2013 at 14:33
  • 1
    You don't indicate why the question is interesting to you, but if it's in a programming or reverse engineering context studying the Shapefile C library (Shapelib) is likely time well spent.
    – matt wilkie
    Commented Mar 27, 2013 at 16:11

3 Answers 3

Reset to default
3

It should be something like FID, OID, OBJID, or OBJECTID.

It is the unique identifier for that table which maps the geometry to the attributes.

Improve this answer
3

I believe that there is a relationship. From our (Safe Software's) Readers and Writers Manual:

An Esri shapefile consists of a main file, an index file, and a dBASE table. The main file is a direct access, variable-record-length file in which each record describes a shape with a list of its vertices. In the index file, each record contains the offset of the corresponding main file record from the beginning of the main file. The dBASE table contains feature attributes with one record per feature. The one-to-one relationship between geometry and attributes is based on record number. Attribute records in the dBASE file must be in the same order as records in the main file.

So, according to my info, there is a 1:1 relationship between Shape and DBF via the record number.

Improve this answer
2
  • This sentence is incorrect, "The one-to-one relationship between geometry and attributes is based on record number" The relationship cannot be based on record number because the .dbf has no record number. The relationship is purely by position. The first shp record, whether is has a record number of 0 or 1 is related to the first dbf record.
    – klewis
    Commented Mar 28, 2013 at 2:43
  • 1
    @klewis You might be a little too severe here. DBase files do have implicit record numbers by virtue of their fixed record length. A DBase file begins with a pre-header that includes information about total length of the (physical) file and a header from which the record length and structure can be read. This allows random access to the table records (as it was originally intended to do). The .shx file exploits this by associating these physical record numbers to each shape. (Going in the other direction would require a table of shape offsets, because shapes have variable lengths.)
    – whuber
    Commented Mar 28, 2013 at 3:43
3

There is a 1 to 1 correlation to the record in the .shp file and the .dbf. However, this is based on the record order in both the .shp and the .dbf. There is no connection based on any field/value stored in the .dbf. If you open the .dbf in something other than ArcGIS and perform a sort on any field and then save the .dbf file, you can mess up this referencing. The shape file will continue to work but the attributes may no longer be applied to the proper shape.

I found this out the hard way years ago when I was looking for a better way to manage the attribute data with out the overhead of ArcView 3.X

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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