Select to view content in your preferred language

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

430
6
Jump to solution
03-17-2025 09:09 AM
Labels (2)
BeckB
by
Occasional Contributor

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 B
APark A
NullPark B
Not in protected areaPark C
Not 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.

0 Kudos
1 Solution

Accepted Solutions
AustinAverill
Frequent Contributor

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! 

codeBlock.png

table.png

  

View solution in original post

0 Kudos
6 Replies
BeckB
by
Occasional Contributor

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! 

 

0 Kudos
AustinAverill
Frequent Contributor

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! 

codeBlock.png

table.png

  

0 Kudos
BeckB
by
Occasional Contributor

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

0 Kudos
AustinAverill
Frequent Contributor

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.

0 Kudos
DanPatterson
MVP Esteemed Contributor

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.


... sort of retired...
0 Kudos
AustinAverill
Frequent Contributor

This is a good point. Generally if I am doing a sort of one-off calculation, I will output to a new/empty field. Then after I can verify the ouput and data, I will calculate the field of interest to match the new/empty field that was populated initially. Otherwise I just use the new field in its place.

 

All depends on what how and why you are using it I guess.

0 Kudos