Ability to insert features specifying the ObjectID value

Idea created by mikedorais on Apr 27, 2015
    New
    Score-70
    There is currently no way to insert a feature into a feature class so that its ObjectID will have a specified value instead of an automatically assigned one.  Automatically generated such IDs is common in databases, but so is the ability to override that behavior. An example is this statement Microsoft Transact-SQL:

    SET IDENTITY_INSERT TableName ON

    Without this ability, inconvenience, extra work, and slower performance may result when there is some source of features from which some process or code produces its unique integer ID, that needs to be passed to some ESRI tool or API call that requires the ObjectID in the feature class to which features were inserted.


    Note that this idea only applies to inserting a new feature and I would expect that an exception would occur if the value being inserted is not unique in the table.  I would not expect to be able to update it once inserted.  
    At present we are most interested in the ability to programmatically insert to insert features into a geodatabase feature class using ArcObjects (ArcGIS Engine).  It would need to be incorporated into the pattern of using IFeature.Store() and for when feature buffers are used, IFeatureCursor.InsertFeature().   Others may be interested in supporting it in other ArcGIS SDKs. Python, and through geoprocessing tools, and the ArcMap and ArcCatalog GUI.
    I invite comments from others who may have other applications.
     
    There are many examples where that a direct relation between the Object IDs would be useful, but here is just one example:


    ---

    When you build a network dataset the only way to specify a specific network location with Network Analyst (and associated APIs), is to use the ObjectID of the associated feature in the feature class (SourceID, SourceOID, PosAlong, SideOfEdge).

    Original source of feature data that already has unique integer IDS => exported to =>
    Feature Class that will participate in a network dataset.

    A process that references the original source of feature data then produces some output that needs to be fed directly into a Network Analyst routing problem requiring precise routing from/to the network element.

    As long as the unique integer IDs in the original feature class cannot be guaranteed to match the Object IDs in the feature class in the network dataset:

     
    • The Integer ID must be included as an additional separate field in the feature class.
    • Then for a given process:      
      • Process = > Integer ID output => Lookup Integer ID to find its corresponding ObjectID => Then use Object ID in Network Analyst stop specification.
           

    Were the unique integer IDs in the original feature class able to be guaranteed to match the Object IDs in the feature class in the network dataset:
    • There would be no need for the Integer ID to be included as an additional separate field in the feature class.
    • The for a given process:      
      • Process = Integer ID output => Then use integer ID directly as Object ID in Network Analyst stop specification.
           

    FYI: In our case the process that produces the integer ID output is a given for which we cannot change at this time.  We must support a legacy address geocoder that produces an integer ID from our proprietary design SQL table that gets exported to the feature class used in the network dataset.  We need to be able to route to/from that specific edge.  We are writing the code that performs the export and have an opportunity to solve the problem in that code.  The lack of ability to know the ObjectID to specify (which would be resolved by this idea), as well as the inability to specify only SourceID, SourceOID and have PosAlong, SideOfEdge be calculated based on the point location’s relation to the corresponding feature, required us to write a Python GP tool published as a service that is called to prepare stops before submitting them to our published route solve service.  It works, but the performance does not meet the requirements that were being met by an older Map Objects and Net Engine solution we already had in place.
    ---