Skip to main content
  • EN

Hi - I'm reading in one Esri File Geodatabase using the ArcObjects Reader (not the open source API reader) and writing out another with a subset of the data in it. The Writer uses a 'Reader as a Resource' to control the schema dynamically and also uses an empty Geodatabase with the same schema as a template file, to ensure that featureclasses that are sent no features by FME still exist (but are empty) in the exported FGDB.

My problem is that I am getting a warning that I can't engineer out of the process:

WARN  |User field name 'OBJECTID' conflicts with value of feature type parameter 'Object ID Field' ('OBJECTID') for table/feature class 'd_y_n59'.  User field will be ignored

This appears for every featureclass I'm trying to write, so 105.

I know that the incoming data has the OBJECTID and I know that the FGDB needs to create it. On my dynamic writer the FeatureType sets the field and the alias to 'OBJECTID' by default. I'm pretty confident that the result is good, even with the warnings, but if possible I want to try to get rid of the warnings completely. I can achieve this if I change the FeatureType parameters to say 'ObjectID' instead and the OBJECTID does look like it still gets created in the target, presumably because of the schema control I have in place with a resource and template file, but I don't want to do this if I'm actually creating a separate hidden and non standard attribute/index somewhere.

Any ideas?

Thanks in advance FME'rs!

I should add, that I have already tried to expose and then remove the OBJECTID off the incoming features prior to writing the data, but this makes no impact on the warnings.

 

 

I would try setting the objectid as attribute to remove/delete in the writer feature type dynamic definition, maybe that would help...

 

 

I should add, that I have already tried to expose and then remove the OBJECTID off the incoming features prior to writing the data, but this makes no impact on the warnings.

 

 

I would try setting the objectid as attribute to remove/delete in the writer feature type dynamic definition, maybe that would help...

 

 

I would try setting the objectid as attribute to remove/delete in the writer feature type dynamic definition, maybe that would help...

 

 

@itay - Spot on, proof that if you stare at a problem for too long without a break you miss the blindingly obvious. I set the 'Attributes to remove' and no blue now! Thanks...

 

@itay - Spot on, proof that if you stare at a problem for too long without a break you miss the blindingly obvious. I set the 'Attributes to remove' and no blue now! Thanks...

 

No problem sometimes leaving it and getting back to it helps me

 

 

I would try setting the objectid as attribute to remove/delete in the writer feature type dynamic definition, maybe that would help...

 

 

Excellent, thanks for reminding me about that option that I should probably have another look at 🙂

Dave,

In addition to comments already received and FYI:

GDB FC writing creates certain fields AUTOMATICALLY when the following common Geodatabase feature classes are created:

Polygon feature classes (areas):

OBJECTID, SHAPE (which will be populated with "polygon"), SHAPE_Length (ie perimeter), SHAPE_Area

Point feature classes:

OBJECTID

SHAPE (which will be populated with "point")

Line feature classes

OBJECTID, SHAPE (which will be populated with "polyline"), SHAPE_Length

table feature classes

OBJECTID

...................

In other words, you can safely delete all these fields from your schema / incoming data / writer - as GDB FC writing creates them automatically anyway whether you want them or not.

For that reason, don't use OBJECTID for anything, create your own polygon id for example if you want to use it in a meaningful way eg a polygon_id linked to data in an external table. If a polygon is edited eg split in two, new OBJECTID's will be automatically created in GDB FC that will have no connection to the original OBJECTID

.......................

Hope this helps

Howard L'

Reply


Community Stats

30,126
Posts
114,374
Replies
37,765
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.