Copy Parcel PINs to Building Footprint Tables en masse?

[JaredPilbeam1]

Hi,

I'm working with real estate data/parcels and building footprint feature classes. Each parcel has it's own PIN. The footprint layer is empty of attribute data. I want to be able to copy the PINs over to a building footprint layer without having to do one at a time.

There are a few other Fields that need populated and those I can copy easily enough a bunch at a time by selecting a large area in Editor (see image here). But the PINs cannot be copied this way because they are unique.

Is there a way to do this?

Thanks,

Jared

[JaredPilbeam1]

Brian,

Thanks a lot. I'm not the data owner (i.e. only a GIS Tech I), so that basically rules out my original method I guess. But, you're right. Christopher's method is what I'm looking for. Christopher Thomas​

Here’s what I did:

• Select any number of Ref_Building_Footprints and create a layer
• Select the corresponding Parcels and create a layer
• Generate Near Table using Footprints selection as input and Parcels selection as Near Features. If Footprint resides within that Parcel it will include the distance of 0.
• Join Near Table output to Ref_Building_Footprints using IN_FID (Footprints selection)
• Join Parcels to Ref_Building_Footprints using NEAR_FID (Parcels selection)
• In table, Calculate Ref_Building_Footprints PIN from Parcel PIN

This worked very well. So, thank you all!

-Jared

[GIS-Cambria]

Yet another way to skin the cat is using Attribute Assistant (AA). You can add a rule to spatially dip (intersecting feature) just about anything and pass attributes between features. Something to be careful of though; feature envelopes. For example, we tried a bulk PIN transfer between address points and parcel polygons using AA and found that address points outside of a large parcel were still picking up that PIN. My only suspicion is the AA method used an envelope to select the point/parcel match. We did the spatial join to fill in all the existing address point/PIN info and then use AA for the maintenance.

A spatial join will work more succinct in your case to get your foundation built, but then consider using AA for your ongoing maintenance. It's a fantastic tool!

[AdrianWelsh]

Steve, Attribute Assistant seems like a good idea. If Jared were to use this, which download package would you recommend? I see that there are quite a few different ones and there doesn't seem to be an obvious one for updating parcels and/or building footprints.

[GIS-Cambria]

Any of the downloads for Attribute Assistant (AA) would be useful. The trick is to create the correct rules in your DynamicValue table and, if using generate ID functions, also add the ID columns one would like to use into the GenerateID table. The combination of AA and the two tables mentioned can be modified to work within your own environment and doesn't require your data to be completely within the LGIM as the samples have. Below are a few quick examples of the rules for the DynamicValue table with the columns separated by |:

BuildingFootprint|PARCELID|INTERSECTING_FEATURE|TaxParcels|PARCELNUM|C|True

The |C| is a value to use centroids

BuildingFootprint|BLDGID|GENERATE_ID|BuildingID|6|BFID-[seq]

The |6| will pad the numeric generated ID to 6 characters from left. The GenerateID table is used to manage your numeric sequence. You would add a record to GenerateID with the field that your method will look for, in this example the attribute is |BuildingID|. The result would be BLDGID = BFID-000001 etc.

[RuthBowers]

If you have an advanced license, my personal favorite for this type of task is the Identity tool from the Analysis Tools. It is similar to spatial join. It saves you steps since the output already has the identified attributes attached to the features of the input feature class.

[ChristopherThomas]

Another approach that has the benefit of working with the existing feature classes without creating additional feature classes like spatial join: Use the Generate Near Table tool. This produces an output table with the feature IDs of both feature classes. If the building resides within that parcel it will include the distance of 0. In this case you are not interested in the distance but the IN_FID(building OID) and NEAR_FID(parcel OID). Next you can join the NearTable output to the building feature class using IN_FID then join the parcels to the buildings using NEAR_FID. Next calculate the building.PIN over from parcel.PIN through the joined tables. Keep in mind if the feature classes are large, you might want to add indexes to the fields involved in the join to do the calculation with better performance.

[RuthBowers]

I agree that you are making this more complicated than it needs to be.

Also, it is highly unlikely that you will be allowed to add a field to a table in a versioned database. So, you will need to do something that creates an additional output table, like Spatial Join.

I would change your workflow as follows:

• Select the buildings you have drawn so far.
• If your parcel feature class is very large, do a spatial selection on it based on the selected buildings.  It can take an extremely long time to do a spatial selection on a large dataset. Doing the selection on a selected set trims the time down significantly.
• Then run a Spatial Join with the point layer and the parcels (Spatial join operates on selections, so you don't need to make another layer).  For the Match Option, choose HAVE_THEIR_CENTER_IN so that you don't need to create centroids.
• Save that output in the same file geodatabase or a shapefile
• Join the Spatial Join output with the building footprints layer (I believe joining the OBJECTID).  If ObjectId is the only unique identifier you have, it will have to do. As long no records are added or subtracted between this step and the next, you are okay.  The reason not to use ObjectId as a unique identifier is because it is not a static number. If someone adds or removes a record, the numbers may change and your records won't match up any more. ArcGIS considers itself to be the owner of ObjectId, and the user has no control over the column.
• Calculate the PIN in the building footprints layer equal to the PIN from the Spatial Join output.

You might want to discuss adding a unique identifier column to the footprint feature class with your SDE DBA . It would be convenient to be able to build relationship classes that go both ways between the parcels and the buildings.  When you are finished with this task, if I understand you correctly, you'll be able to relate what parcel goes with a building, but not what building(s) go with a parcel.