Okay, so I took some time and went through this whole script, and I think your first problem is that your code is unnecessarily convoluted. It's not that it's bad, per se, but that it's not doing you any favors troubleshooting and identifying the code. There are also some logical analysis concerns, here. So I'm going to go down the rabbit hole and try to address all of it that I caught.
This is going to be long, so I'm also going to color code the headings (and possibly break the post in two, if I hit forum limits). I'll also put a letter tag for the color, in case you or anyone else is color-blind:
- [G] Green Headings mean you really should do this, but technically it'll probably work if you don't. I'll give my justifications why I think the change is worth it, though.
- [R] Red Headings mean you need to do this. Either it's a syntax error or a serious logical error, or maybe it's just a massively bad practice that goes beyond "should".
- [P] Purple Headings are sidenotes. They might not require any action, but they're generally assumptions or thoughts I had while parsing through; if any are wrong, it might actually be a red flag.
Also, I'm going to refer to variable names in bolded blue, since these boards lack a good inline code option for things that don't warrant a full block.
1a. [G] Variable Names (especially your input variables)
Single-letter variable names like the (s, t, u, r) in your function definition really aren't the time saver many coders think they are. Trust me when I tell you, the 1–2 seconds longer it takes you to type out sales_listing instead of s is irrelevant against the mental load it's going to take you to troubleshoot and especially the mental load it's going to take others to troubleshoot. And too often forgotten: "Others" also includes yourself, but months in the future, when someone asks you to run this code again and it breaks, or you need to modify something to alter the calculation you're running. Be nice to future you; write longer variable names, and do at least some rudimentary documentation as you go. "Schedule time for machine maintenance, or your machine will schedule it for you," as the saying goes.
1b. [P] Try out an IDE other than IDLE
This is 99% a personal preference thing, so you do you. I personally use PyCharm and quite like it, but everyone's different. Two benefits relevant to addressing this script in particular, though: Auto-completion will help those longer variable names like sales_listing from 1a take the same amount of time to type as s. Now you get all the benefits of longer names, without any of the downsides. Also, most other IDEs will do things like highlight unused variables. You might've missed this entirely, but parcel_sites and spatial_ref don't actually do anything, other than get created & forgotten in Lines 9 & 11. They're not realistically hurting anything, but the extra clutter is going to make it harder to troubleshoot problems in your code. The same is true of select_feedlot in Line 34, though that might be another error we'll get to.
2. [G/R] Source Parcel Data & Overwrites
(Possibly harmless; possibly catastrophic—depending on source data)
First note: The way you're writing these means that PINs present in the Tax Parcel polygons will overwrite any matching PINs in the Address Points. If your source data is anything like our municipality's, the locations of the Address Points and the locations of the centroids of the Parcels (as represented by SHAPE@X & SHAPE@Y in Line 17) likely don't match. And if the parcels are big enough or close enough to that half-mile line, you could end up with lots of false positives and/or false negatives, depending on which point is more "correct".
If you can be sure that all PINs in one data set exist in the other dataset, then I'd just import one, and ignore the other. If there are unique PINs in either, then you'll need to decide which one wins, and make sure that one is second. But know that's going to increase the error bars in your resulting analysis.
Also, if you can use a single dataset, then Lines 21–27 become irrelevant, saving you and your computer some work!
2b. [P] dict.iteritems() vs dict.items()
In Line 25, you call iteritems(), but that method was removed for Python 3. If you're in ArcGIS Pro, you need to be writing in Python 3, even if your code is running outside Pro. If you're in ArcGIS Desktop, then there might be bigger concerns elsewhere, but for now this will presume you're working in Pro/Python 3. If you can't go down to one dataset (per #2), then you want lot_site.items().
For more information of the difference, there's a pretty good explanation in the Stack Exchange question here.
2c. [G] Unpacking & repacking lists/tuples
v = (x, y)
# These two lines do the same thing, but notice one is MUCH clearer. Why
# unpack & repack? The only difference is tuple vs. list. You could just
# save your original as a list, or cast it with list(v), instead. Much easier
# to debug later.
feed_point = [v[0],v[1]]
feed_point = v
3. [R] SelectLayerByLocation against selected parcel or parcel coordinates?
In Line 34, you do a SelectLayerByAttribute to get just the parcel you're looking at in this iteration of the loop. Then, you feed in the geometry token from the loop into SLBL. The parcel SLBA doesn't do anything.
Worse, this is the outer Cursor of your nested cursors, and it doesn't appear necessary at all. Lines 13–27 create a Feature Class that you then iterate through in Line 33, but you could just as easily have been iterating through a dictionary in far fewer lines:
lot_site = {}
with arcpy.da.SearchCursor(address_points, ['CountyPIN', 'SHAPE@']) as cur1:
for pin, geo in cur1:
lot_site[pin] = geo
with arcpy.da.SearchCursor(tax_parcels, ['PIN', 'SHAPE@']) as cur1:
for pin, geo in cur1:
lot_site[pin] = geo
for pin, geo in lot_site.items():
saleAddresses = arcpy.management.SelectLayerByLocation(address_lyr,
'WITHIN_A_DISTANCE',
geo,
'2640 FEET')
# do other stuff
As stated above in #2, you might not even need Lines 2–4 of the code above!
4. [G] Inner Cursor vs Definition Query
The other reason you have nested cursors is because you only want to pull the PINs that are in your Sales Listing. There's a nonzero chance this could be done by applying a definition query to the PIN data source(s) you're reading in. Examples are beyond the scope of this already-mammoth post, because they depend on how you're feeding the source PIN data in. But it's yet another case of "If you need to nest cursors, take a second look at your basic structural assumptions."
5. [R] Variable names again, but way more of a mess.
It took me absurdly long to parse through Lines 41–47. Partly, that was because of the nested cursors, and partly that was because of all the tuple slicing going on. Instead of calling sale[0] every time, just save it to a variable. In my test case where I was scribbling notes, I called it innerPIN, but I still maintain that the nested cursors aren't necessary here. You might also be able to combine some of those lines, depending on the structure of the data it's reading from the Sales & Feedlot listings:
adj, netsale, ratio = s.get(innerPIN)
6. [R] I think you missed a step...
Lastly, the most critical problem appears to be in Lines 38–48. As pointed out by Alfred: In Line 39, you set y=1. Every PIN; every time. Then, you pass that 1 over to count, which you save in your output dictionary. Every time.
No matter what the rest of this script does, you're always going to get a count of 1, because you manually passed that in. But I suspect you missed it because of the complications elsewhere, which is why I wrote out all that stuff above. At a loose glance, you appear to be missing a step, but to be sure, I would need to see an example output dictionary of what you expect to get back. You can put dummy PINs and such in, if you're worried about confidentiality concerns. Instead of the usual string of numbers and dashes most municipalities use, just use "dummy-PIN-1" and "dummy-PIN-2" in your example.
------------------------------
M Reed
"The pessimist may be right oftener than the optimist, but the optimist has more fun, and neither can stop the march of events anyhow." — Lazarus Long, in Time Enough for Love, by Robert A. Heinlein
