Standardise KML to Layer row ID field name

08-16-2021 08:44 AM
Status: In Product Plan
Labels (1)
MVP Notable Contributor

In ArcPro 2.8 you can use the KML to Layer tool to convert a KMZ file to a Featureclass. Whilst the tool runs well it creates an unconventional field name of OID for the ObjectID field.

My idea is to simply standardise the output of this tool and ensure that the ObjectID field is called ObjectID. Most users (including myself) would be expecting to see this naming convention when output is created by a geoprocessing tool.

If you are developing model/scripting logic and suddenly a tool creates an unconventional name this can unhinge ones workflow. It's the same unnecessary irritation that I see sometimes with open source data formats when they decide to call the geometry field "geom"; when convention, certainly in the world of ESRI, it has always been called "Shape"...


@DuncanHornby I checked around each tool could name the ObjectId something different depending on the datasource it is writing to.  Consider using the following code if you need to know the Field Name.




Hi @JonathanNeal , As I wrote my idea I was aware of the approach you are suggesting arcpy.Describe(<data>).OIDFieldName and indeed I understand that would be best coding practise to always query the OID and geometry field name as they can be named something different. But that can add a level of complexity, albeit small, to any code and more importantly these tools are used in modelbuilder; it's just right royal pain in the a$$ to have to deal with! All this can vanish if ESRI tweak their tool to write out the ObjectID name as ObjectID for a geodatabase featureclass instead of OID. This would allow code/model development to flow more easily, be simpler and less likely to fail if everyone on the ESRI platform is working to the same standard/naming convention.


Is there a way to keep the symbology and fields from the KML in the shape file?

Status changed to: In Product Plan

The OID field naming for the output of KML To Layer has been addressed in ArcGIS Pro 3.2. The feature classes should always have an OID field named OBJECTID.