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.
Solved! Go to Solution.
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!
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!
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!
I see! Would this also work if I had the output of the code feed into column B directly instead of into column C?
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.
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.
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.