nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Get Count returning wrong specified selected feature class

GISIntern21

Hello! I am working on a Python project, and I am just about done with it, but I am struggling with formatting my Get Count function. I am writing a script to get the number of sales within a 1/2 mile of feedlots, but to finish it off, I need to return the number of feedlots that are within that half mile of the sales. So if a particular sale point has 1-3 feedlots within a half mile, I need to return that number, but right now, I am getting the number of sales instead (basically the opposite of what I need). I have tried swapping the feature classes in my function, but I only get '1' as a result. Is there a better way to write my code, or am I missing something?

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

Hayden Welch

If you want a really compact way to do this, you can build mappings between features really easily using SearchCursors and dictionary comprehensions:

from typing import TypeAlias
from arcpy import LinearUnitConversionFactor
from arcpy.da import SearchCursor

feedPoint_lyr = "feedPoint"
address_lyr = "address"
feature_units = 'Meters' # Replace with your feature units
_MILES = LinearUnitConversionFactor(feature_units, "Miles")
# Half Mile in in feature units
BUFFER = 0.5*_MILES

# Change this to the datatype of your PIN fields
PinType: TypeAlias = int
#PinType: TypeAlias = str

sale_to_lot: dict[PinType, list[PinType]] = {
    # Find all lots within `BUFFER` of each address
    pin: list(SearchCursor(feedPoint_lyr, ['PIN'], spatial_filter=point.buffer(BUFFER)))
    # Iterate all addresses
    for pin, point in SearchCursor(address_lyr, ['CountyPIN', 'SHAPE@'])
}

lot_to_sale: dict[PinType, list[PinType]] = {
    # Find all addresses within `BUFFER` of each feedlot
    pin: list(SearchCursor(address_lyr, ['CountyPIN'], spatial_filter=point.buffer(BUFFER)))
    # Iterate all feed lots
    for pin, point in SearchCursor(feedPoint_lyr, ['PIN', 'SHAPE@'])
}

This will give you two mappings, one mapping each feedlot to the addresses within 0.5 miles and one mapping addresses to lots within 0.5 miles.

You can then use these PIN mappings however you want without having to do a spatial query again.

This solution is more memory efficient, but spools up an ungodly amount of search cursors (len(address)+len(feedlots)). You can avoid this by loading the features into memory first:

from typing import TypeAlias
from arcpy import LinearUnitConversionFactor, PointGeometry
from arcpy.da import SearchCursor

feedPoint_lyr = "feedPoint"
address_lyr = "address"
feature_units = 'Meters' # Replace with your feature units
_MILES = LinearUnitConversionFactor(feature_units, "Miles")
# Half Mile in in feature units
BUFFER = 0.5*_MILES

# Change this to the datatype of your PIN fields
PinType: TypeAlias = int
#PinType: TypeAlias = str

# Load addresses
addresses: dict[PinType, PointGeometry] = {
    pin: shape
    for pin, shape in SearchCursor(address_lyr, ['CountyPIN', 'SHAPE@'])
}

# Load feedlots
feedlots: dict[PinType, PointGeometry] = {
    pin: shape
    for pin, shape in SearchCursor(feedPoint_lyr, ['PIN', 'SHAPE@'])
}


sale_to_lot: dict[PinType, list[PinType]] = {}
for address_pin, address_shape in addresses.items():
    sale_to_lot[address_pin] = [
        lot_pin
        for lot_pin, lot_shape in feedlots.items()
        # Skip lot if it is not within `BUFFER`
        if not lot_shape.disjoint(address_shape.buffer(BUFFER))
    ]

lot_to_sale: dict[PinType, list[PinType]] = {}
for lot_pin, lot_shape in feedlots.items():
    lot_to_sale[lot_pin] = [
        address_pin
        for address_pin, address_shape in addresses.items()
        # Skip address if it is not within `BUFFER`
        if not address_shape.disjoint(lot_shape.buffer(BUFFER))
    ]

MErikReedAugusta

Alfred's covered almost all of the basics you need here really well.

One thing I feel is important to explicitly point out where his code meaningfully differs from yours is that he has only one level of SearchCursor. This is very deliberate, and decidedly a best practice.

Nesting different SearchCursors or UpdateCursors can cause your code to be monumentally slower than you'd expect, because the inner cursor runs through its entire table/view once for every record in the outer cursor.

Simply put, consider the following:

with arcpy.da.SearchCursor(tbl_one, fieldList_one) as cursor1:
    for rowA in cursor1:
        with arcpy.da.SearchCursor(tbl_two, fieldList_two) as cursor2:
            for rowB in cursor2:
                #do stuff

If you have 100 records in tbl_one and 100 records in tbl_two, you'd end up in a loop of 10,000 iterations. This problem also grows exponentially, as you can probably see.

Even working with a smaller inner table like you were, this is often incredibly inefficient. There are very narrow cases where it might appear okay, at first glance. But I would argue that it's almost always a red flag that your underlying/theoretical procedure needs some revisiting.

The one exception typically cited is InsertCursor. Because of the way that one works, it's both fine and frequently standard practice to nest it inside either a SearchCursor or UpdateCursor.

abaldenweck@blm.gov_BLM_EGIS

No problem!

The way you have it set up isn't wrong.

Cursors are conventionally done the way I did it (peep the documentation for arcpy.da.SearchCursor, although the documentation for the older arcpy.SearchCursor doesn't do it) because it's supposed to be used as a context manager, meaning that it closes itself when it's done, removing any locks and freeing up resources. This sort of construction is great in case of errors; if you use it to open a file and then something breaks, it closes the file as part of the error reporting process.

That being said, it's been discovered that cursors don't actually behave like this, at least in file geodatabases, so you should still add in a del when you're done as a best practice (even though it's supposed to be doing it behind the scenes for you automatically when you use a with.

with arcpy.da.SearchCursor(lay, fields) as cursor:
    for row in cursor:
        #code
        pass
del cursor

GISIntern21

Alrighty! I'm still fairly new to Python, so I figured it was most likely an order of operations problem..
For formatting purposes, the code sample you shared, would that just substitute my 'for row in arcpy though the selections? My end goal is to create a csv output that has the sale and feedlot parcels, permits of the feedlots, etc, so I'm wanting to try and loop through all of my records I believe.

abaldenweck@blm.gov_BLM_EGIS

I think there's an order of operations problem here.

First thing: I don't think "select_feedlot" is necessary; you don't use it and also it's redundant for what you're doing anyway.

The way a cursor works is by going through each record in a table, one at a time. So, doing a select by attribute on the same table to get the exact same record is not a good use of time.

This is also the cause of the other, larger, problem, which is that all of your select by locations are plugging in the entire feedPoint_lyr, not just the current record you're trying to analyze for. I'm assuming that all of your sales are within 2640 feet of SOME feedlot, so if you plug in every feedlot, you're going to get every sale.

To get around this, use the SHAPE@ keyword (not sure if that's the right term for it) in your cursor's fields, and feed each record's geometry to SelectByLocation

with arcpy.da.SearchCursor(feedPoint_lyr, ['PIN', 'SHAPE@']) as cursor:
    for row in cursor:
        # Each row is returned as a tuple: (PIN, geometry)
        # feed it the second item in the tuple
        sales = arcpy.management.SelectLayerByLocation(
                            address_lyr, 'WITHIN_A_DISTANCE', 
                            row[1], '2640 FEET'
                            )

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.