0

I am doing an analysis that places a buffer around X property, then identifies all the parcels within that buffer to store in a database and perform analysis on later.

Currently, I have two separate databases. One for all the properties I run the buffer on, then a second which includes all of the parcels that are within the buffer. Each record in the second database has a reference field to the first so I know where they all belong. The issue is there is massive duplication of properties in the second database since many of the buffers would end up overlapping each other. In turn I'm adding the same parcels to the second database, they just reference different records to the first. I feel like this is hugely inefficient.

Is there a better way to do this? I thought I could just add a field to the Parcel data and use Calculate Field to just append any reference fields together. Is my "Better Way" suggested below the best way to do this, if so is there a reason why the modelBuilder does not properly select the parcels so I can then calculate the field?

enter image description here

enter image description here

  • Joining a table or selecting the records to perform some operation later would be very difficult with better way? and take a lot of time scripting; Space is cheap, time is expensive, only worry about space if your database has a hard limit (like personal geodatabase with a limit of 2 GiB).. file and enterprise databases maximum limit depends on the OID field type (usually LONG 2^64 = 9223372036854775808 rows, but OIDs are not recycled, deleted rows are never reused). – Michael Stimson Mar 4 at 5:51
  • OK speed is for sure my biggest concern. The ModelBuilder above is a simplified version of what I am doing, but generally speaking I am creating a custom buffer, clipping the parcel data based on the buffer then appending that data. It takes almost 60 seconds to do eeach iteration. It's brutal. I am just trying to find a way to do it faster. Also, your point about deleting rows is interested. So, you're saying it's pretty much pointless to ever delete records? That would save time with my script. – David Seroy Mar 4 at 6:04
  • Generate near table does this on a single layer. It stores enough info to summarize anything about parcels within a buffer. – FelixIP Mar 4 at 6:14
  • @FelixIP. Not super familiar with this. Can you elaborate a little? – David Seroy Mar 4 at 6:21
  • No, deleting records that are no longer required is a good idea followed by compressing/compacting the database, rows that no longer exist will not slow down selection but deleted rows that haven't been compressed (ignored, not gone) will slow down the database. However I would suggest checking a feature doesn't already exist in the come back later database before inserting the same feature yet again provided you don't need to keep a snapshot of the geometry and attributes at the time the original script was run. What manner of database are you using? – Michael Stimson Mar 4 at 6:32
0

This is how that tool works:

arcpy.GenerateNearTable_analysis(in_features="POLYGONS", near_features="POLYGONS", out_table="C:/SCRATCH/SCRATCH.gdb/nearTable", search_radius="100 Meters", location="NO_LOCATION", angle="NO_ANGLE", closest="ALL", closest_count="100", method="PLANAR")

Output has OIDs of parent polygon and neighbors within specified radius, e.g. polygon with FID=14, has 4 neighbours:

enter image description here

It is enough to join neighbors via NEAR_FID to find virtually any statistics for parent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.