I found a use for the transfer attributes tool this week that I will end up using regularly and it made me think about the tool’s purpose and why we might want to avoid using it as much as possible.
I think there are many potential uses for batch geospatial processing methods that transfer attributes. For example, I might have climate polygon layer with the polygons broken up by a risk index. I then want to transfer the index number from the climate layer to all of the utility poles in a state. I’ve found a few different geoprocessing methods to do this including an iterating python script I created that I might need permission to share in a public forum.
The transfer attributes tool, however, works on a one-to-one feature attribute transfer. If your database is designed using good database management principles, the most that would ever transfer between two features in a situation like this is a primary key. This could still come in handy. The ability to directly copy a primary key to a new feature without data entry error can be very useful.
However, we should use caution if the transfer attributes tool is being used to copy over many fields that are not part of a primary key. That’s a duplication of data that calls into question the database design or possibly the programming design.
Some questions to ask include:
- If there are points and polygons or polygons and lines both representing the same feature, are both features even necessary?
- If a subset of features is being created is there any way to make that a query instead?
- If the features are in two separate servers, for example survey property data in one server and tax lot data on another server due to to splits in government responsibility, is there any way to connect that information to avoid duplication?
Once data is duplicated, even if the initial split was created through a sound method such as feature attribute transfer, the likelihood of one of those sources having changes that don’t get updated in the other feature goes up. This introduces costly errors. The cost might be the paycheck for 15 minutes of confusion and updates or it could be substantial sums of money. Are you willing to take that gamble?
We need to think carefully about why we are using certain tools and what that means about the the structure of our system. The transfer attributes tool is one of those that has the potential to allow non-ideal data management practices flourish, and as GIS saavy individuals we want to stop and think about if using this tool is hiding cracks in your data architecture.
GIS is a system not a tool; use the tool it contains wisely.
If you’d like to learn more about the transfer attributes tool, check out ESRI’s website HERE.
Have a great week! I hope this gives you some good food for thought on the tools you are using!
Best,
Michelle
Michelle Toner 