I'm working in ArcGIS Pro 3.1 using Field Calculator. I have a table where I want to transfer specific values of one column into another. Column B is a list of full, tidy names of parks. Column A is a similar, less-tidy list, but it does note some locations where the data collector specifically wrote that they were not in a protected area (rather than the protected area being missing and something to follow up on). Thus, I want to be able to fill column B with column A's value only if column A= "Not in protected area" and column B is empty, like in row 4 of the below table. Column AColumn BAPark ANullPark BNot in protected areaPark CNot in protected areaNull Here is the code I have so far in Calculate Field for Column B. (in expression line) COLUMN_B = reclass(!COLUMN_B!) (in code block) def reclass(COLUMN_B): if (COLUMN_B == None) and (COLUMN_A == "Not in Protected Area"): return "Not in Protected Area" else: return COLUMN_B Strangely, this code makes column A entirely equal to column B rather than calculating column B. Why is this code editing column A? How do I make it only bring my desired values of column A into column B? Any advice would be greatly appreciated.

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; } } }

Field calculator filling one field based on a specific value of another

BeckB

I'm working in ArcGIS Pro 3.1 using Field Calculator. I have a table where I want to transfer specific values of one column into another. Column B is a list of full, tidy names of parks. Column A is a similar, less-tidy list, but it does note some locations where the data collector specifically wrote that they were not in a protected area (rather than the protected area being missing and something to follow up on). Thus, I want to be able to fill column B with column A's value only if column A= "Not in protected area" and column B is empty, like in row 4 of the below table.

Column A	Column B
A	Park A
Null	Park B
Not in protected area	Park C
Not in protected area	Null

Here is the code I have so far in Calculate Field for Column B.

(in expression line) COLUMN_B = reclass(!COLUMN_B!)

(in code block)
def reclass(COLUMN_B):
    if (COLUMN_B == None) and (COLUMN_A == "Not in Protected Area"):
        return "Not in Protected Area"
    else:
        return COLUMN_B

Strangely, this code makes column A entirely equal to column B rather than calculating column B. Why is this code editing column A? How do I make it only bring my desired values of column A into column B? Any advice would be greatly appreciated.

Encontre mais publicações marcadas com

Analysis

Geodatabase

Accepted answers

AustinAverill

Using a function in the code block is definitely not over thinking this, you just has a couple pieces off!

Primarily, you weren't passing "column_a" into the function. So it could not read it. I recreated your data and am attaching some pictures of the field calculator and a calculated column so you can see the small change that would have got it to go!

All comments

BeckB

Update: I was completely overthinking this by pulling def into it. I got my desired result by putting this into the expression line of Calculate Field for Column Band ignoring the code block:

'Not in Protected Area' if !COLUMN_B!== None and !COLUMN_A!== 'Not in Protected Area' else !COLUMN_B!

AustinAverill

Using a function in the code block is definitely not over thinking this, you just has a couple pieces off!

BeckB

I see! Would this also work if I had the output of the code feed into column B directly instead of into column C?

AustinAverill

Absolutely,

I just put it out to C in my example so the original values weren't altered so it was easier to see how the logic in the defined function was applied.

DanPatterson

Yes. Perhaps. No

as a general rule when it comes to potentially altering data

As a suggestion, It is generally a good idea to do calculations into a new field... verify that things are fine... then if so, delete any unneeded fields.

Some people rely on the "undo" button to avoid the extra deletion step, but cases arise when an undo fails or doesn't go as planned.

Occasionally "shortcuts", ... aren't

But experiment when you have time and the thing you are doing isn't important.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

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