2

I am trying to automate a workflow which involves exporting multiple feature classes (within a geodatabase) to shapefile format.

My inclination has been to use the FeatureClassToFeatureClass_conversion() tool, which I’ve had success with for similar jobs in the past.

The problem is that all shapefiles outputted by FeatureClassToFeatureClass_conversion() are stripped of their OBJECTIDs. Once exported, these shapefiles must undergo a validation cycle that requires the OBJECTID be intact.

What I'm looking for is the arcpy equivalent of the export data feature in ArcMap, which does not delete the OBJECTID field (FID field is ok).

When I look through the documentation I keep getting directed back to the same FeatureClassToFeatureClass_conversion tool. I feel like there’s something major I am missing here, but I simply haven’t been able to find a solution in the docs or on the web.

Any suggestions?

  • 3
    It's a violation of best practice to use ArcGIS-assigned IDs for any purpose. You should always create your own unique feature identifier column. This frees you from the impact of reassignment when tables are reloaded. – Vince Feb 5 '16 at 17:27
  • 1
    I solved this issue by first Copying the OBJECTID field, then exporting my feature class to shapefile, and finaly re-ordering the exported attribute table. Keep in min that the order of fields needed to remain unchanged in my case. To re-order the table I used this – Jess Feb 9 '16 at 21:45
5

FeatureClassToFeatureClass_conversion is the equivalent tool for the ArcGIS desktop export data function. It almost never is a good idea to use ObjectId as a user reference. Why don't you generate a user id column which you know will be consistent through data exports?object Ids within a gdb are given in reference to other features in feature classes stored within the gdb. i.e the objectId of a feature might not always start with 1. Where as in shapefiles the 'FID' always starts with 0 and goes up to the number of features in the shapefile -1. So the numbering is independent.

OR If you are scripting, you can always copy the object ID field on the fly into another column just before exporting your features. That guarantees you that you have the copy of the object ID at the time you copied the data. However, the object id of the original dataset, might change if you migrate the features in your gdb/ or edit it. Which makes it a not-so-reliable reference.

  • Thanks yanes. I should mention that I am not necessarily in a position to alter the layer's attribute tables or to propose a restructuring of the validation process. Mainly, I am trying to make my job less time consuming by automating a tedious export routine. Since ArcMap's export data feature outputs with an OBJECTID, our validation process has evolved around this information, for better or worse. While I submit to not knowing the answer to this question, I find it hard to believe that removing the OBJECTID is the only way to export a shapefile. Wouldn't the export data tool remove it too? – Jess Feb 5 '16 at 17:24
  • 1
    Oh great idea, I never thought about copying the object ID field. However, if I copied the object ID, what would prevent the FeatureClassToFeatureClass tool from stripping that object ID too? if I converted the field-type to a string or int, then wouldn't it no longer be a true OBJECTID? – Jess Feb 5 '16 at 17:33
  • I don't understand what you mean by removing the 'object id'. [OID/object id] and [FID/ feature id] for feature classes and shapefiles respectively, are the fields that are used by ArcGIS to ensure the geometries belonging to each unique feature are stored together. Its sole purpose is ensuring geometric integrity of features. What I suggested is if you need the object Id as it appeared in the feature class to be transferred to your shapefiles, you just add a new column and copy the object id in that column [call it oid2- maybe] then copy the oid into oid2. – yanes Feb 5 '16 at 17:36
  • I don't think I understood for what purpose you are going to use the OID correctly. I understand that you probably do not have much freedom to change the structure of the dataset. But using OID for validation is really not recommended (especially if you are thinking of joining on them). ArcGIS will only use the auto generated OID/FID fields, therefore, it won't be using your OID2 field. Btw, ArcGIS did not remove the OID when you export the data, OID/FID fields are generated when a dataset is created, they are automatically created, therefore, it just generated a column fitting for the format – yanes Feb 5 '16 at 17:55
  • when I export to shapefile in ArcMap, the outputted shapefile contains both an FID and an OID, and I am simply trying to reproduce this output in python. Due to your answer, I just noticed that the OID field outputed from arcmap is of type Long. This is a suprise to me, as I had previously assumed that the OID within these outputted shapefiles was of the OBJECTID type. Your suggestion to copy the OID before exporting makes a little more sense now, although I was kind of hoping for a simpler solution. If copying the OID field works than I will mark this as solved. Thanks! – Jess Feb 5 '16 at 18:00
1

The major issue you are missing is that the ObjectID column is not intended to be used as an identifier column. It is not necessarily a static number. It is possible that the powers that be at your workplace know that and are keeping that in mind in their workflow. On the other hand, you might want to make sure they know that if anyone edits the data or copies a table to another table, the ObjectIDs may change.

ArcMap--which would include the FeatureClassToFeatureClass tool--considers the ObjectID column to be a "system" column, not one to be used by the user. ObjectID is read-only to the user, and only ArcMap can edit it.

What keeps a column that you create from being stripped is that it is considered a column belonging to the user. You added it, and you can edit or remove it--not ArcMap. ArcMap won't remove user columns unless it is the nature of the tool at hand to only include certain columns, or columns designated by the user.

Anyway, as others have suggested, you can fix your workflow by copying the ObjectID into a new user-owned column. You will want to make it a Long.

  • Thanks RHB. The problem is that it will need have the same column name (in the shapefile) and be in the same ordinal position in the shapefile as the current object_id would be. – Jess Feb 5 '16 at 19:25
  • You can shuffle the ordinal positions of the columns by creating a new shapefile, adding the columns in the order you want, then apending the rows, also in the order you want. – RHB Feb 8 '16 at 1:12
  • 1
    Another thing to understand is that a feature class or table only has one oid column, regardless of what its name is. If a tool "keeps" an oid column and it appears there is more than one, this is not actually the case. The "extras" have been turned into user columns. Arcgis doesn't maintain them as oids past that point. – RHB Feb 8 '16 at 1:18
  • Same thing goes for shape length fields. I found that out the hard way. – Nicholas Nov 22 '16 at 22:11
0

If you don't necessarily need the ObjectID to match but just need a reference back to the source ObjectID, do this:

Create a template file GDB feature class with an additional long integer field (i.e. SDE_OID) based on the original feature class.

Use Append and set the new SDE_OID field to be populated by the source Object ID field.

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.