Select to view content in your preferred language

FieldMap object's OutputField property doesn't honor field type mappings

549
2
02-12-2013 04:58 PM
DarrenSmith
Regular Contributor
Summary: The FieldMap object's OutputField property does not accept assignment to a Field object with a .type property set to u'Integer'. If this is attempted the resulting FieldMap.OutputField.Type property defaults instead to be u'SmallInteger'.

When using a FieldMappings object as input to the FeatureClassToFeatureClass (Conversion) tool in order to rename fields from a single input feature class (i.e. no field merging involved) I discovered that there seems to be a subtle bug in the way Field Type keywords are mapped. This issue was discovered in 9.3.1 SP2, however, its so subtle that I'd bet that it still hasn't been fixed in later versions.

When the FieldMap object's AddInputField method is used to add a feature class field containing (long) integers to a FieldMap object the resulting FieldMap.OutputField.Type type property is set to u'Integer'. The documented method to manipulate the properties of the OutputField part of the FieldMap object is to take a copy of the FieldMap.OutputField object, which is a Field object, change its properties accordingly (field.Name = "NewName"), and then assign this changed field object back to the FieldMap.OutputField (fieldMap.OutputField = field). However, during the reassignment step the OutputField.Type doesn't seem to accept u'Integer' as a valid Type value, which causes the OutputField.Type property to default instead to u'SmallInteger'.

Original Code (renames a single field from the input in the output FC):

gp = arcgisscripting.create(9.3) # create arcgis scripting object
gp.OverWriteOutput = True
gp.workspace = <path to local workspace>

fieldMappings = gp.CreateObject("FieldMappings")
fieldMap = gp.CreateObject("FieldMap")
fc = "inputFC"
outFC = "outputFC"
att = 'att1'

fieldMap.AddInputField(fc, att)
# copy field object, change name and reassign
field = fieldMap.OutputField
field.Name = field.Name + "_New"
fieldMap.OutputField = field
# add field map to field mappings
fieldMappings.AddFieldMap(fieldMap)
            
gp.FeatureClassToFeatureClass_conversion(fc, outWrkspc, outFC, "#", fieldMappings)



Code with workaround:

gp = arcgisscripting.create(9.3) # create arcgis scripting object
gp.OverWriteOutput = True
gp.workspace = <path to local workspace>
typeDict = {'String':"TEXT", 'Single':"FLOAT", 'Double':"DOUBLE", 'SmallInteger':"SHORT", 'OID':"LONG", 'Integer':"LONG", 'Date':"DATE", 'Geometry':"BLOB", 'BLOB':"BLOB"}

fieldMappings = gp.CreateObject("FieldMappings")
fieldMap = gp.CreateObject("FieldMap")
fc = "inputFC"
outFC = "outputFC"
att = 'att1'

fieldMap.AddInputField(fc, att)
# copy field object, change name and reassign
field = fieldMap.OutputField
field.Name = field.Name + "_New"
# workaround for ESRI bug
field.Type = typeDict[field.Type]
fieldMap.OutputField = field
# add field map to field mappings
fieldMappings.AddFieldMap(fieldMap)
            
gp.FeatureClassToFeatureClass_conversion(fc, outWrkspc, outFC, "#", fieldMappings)



Please comment as to whether this bug is still relevant to 10 & 10.1.

Regards,

Darren
Tags (2)
0 Kudos
2 Replies
MathewCoyle
Honored Contributor
I do not believe this issue exists in versions 10.0 and above. The only issue I've seen is when mapping large datasets if the optional parameters are not set a sample of the data will be taken to determine what they are, if the sample doesn't get to a large enough numeric value or a long enough string you could run into errors when defaults are assigned.
0 Kudos
ZebThomas
New Contributor
No the issue is still there in 10.0. I just noticed this exact same bug with reassigning type = Integer to SmallInteger in 10.0 SP 5.

It happens when I assign a field object as the outputField of a Fieldmap object:
fieldmap.outputField = field

If field.type = "Integer" when this assignment is made, fieldmap.outputField.type will be SmallInteger

As far as I can tell, your workaround is the best.

However, I also tested this in 10.1 SP1 and apparently the issue is fixed there. The reassignment doesn't happen anymore.

Thanks,
Zeb
0 Kudos