Validate gdb fails at step 3.9

[wgs-asteely]

Everything works great up to step 3.9, as below. I've run the tool successfully on several other gdbs. Not sure why this one is failing. One possibility is that the entries in MapUnit are kinda long...several are 8 characters, e.g. "Mv(gssc)". That's honestly the only thing I can see is different about this compared to other succesful runs.

Start Time: Friday, March 15, 2024 12:25:18 PM
This version of the tool is up to date: GeMS_ValidateDatabase.py, version of 11/28/2023

{omitted for clarity]

3.9 No unnecessary map units in DescriptionOfMapUnits
Traceback (most recent call last):
File "J:\geologic_mapping\methods_tools_instructions\GeMS\gems-tools-pro-2.12.9\Scripts\GeMS_ValidateDatabase.py", line 1716, in
dmu_path = db_dict["DescriptionOfMapUnits"]["catalogPath"]
File "J:\geologic_mapping\methods_tools_instructions\GeMS\gems-tools-pro-2.12.9\Scripts\GeMS_ValidateDatabase.py", line 1624, in main
for f in dmu_fields:
File "J:\geologic_mapping\methods_tools_instructions\GeMS\gems-tools-pro-2.12.9\Scripts\GeMS_ValidateDatabase.py", line 447, in check_map_units
# find all tables that have MapUnit-y field names
IndexError: list index out of range
Failed script Validate Database...
Failed to execute (ValidateDatabase).
Failed at Friday, March 15, 2024 12:25:58 PM (Elapsed Time: 40.23 seconds)

screenshot of DMU table attached

[ethoms-usgs]

Ok, I don't think it's the length. MapUnit is built by default in all tables with a length of 10 characters, and I don't think there is a reason it can't be modified to be longer. I also think parentheses should be ok, so I don't know off-hand what's triggering the error. Have you used those before?

[wgs-asteely]

I've used the tool on similar types of MapUnit names. These were just a bit longer than others we use so I thought that might be it. Though I also considered they were under the length limit...so I'm puzzled too... From: Evan Thoms ***@***.***> Sent: Monday, March 18, 2024 10:36 AM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Ok, I don't think it's the length. MapUnit is built by default in all tables with a length of 10 characters, and I don't think there is a reason it can't be modified to be longer. I also think parentheses should be ok, so I don't know off-hand what's triggering the error. Have you used those before? - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKMLAKBIVANGAP5CRMLYY4QYPAVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUGUZTSNJQGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ethoms-usgs]

Have you checked both fields for leading or trailing empty spaces?

[wgs-asteely]

Hey Evan, I've run the white space tool and done a ctrl-f on every MapUnit field in the gdb for a white space character. None. If it's not length, and not a white space, what does that leave us with? I assume that if it did find there was a DMU entry for which there was no associated MapUnit feature in any of the FCs, then it would just return that as something to look in to, not fail the script. Is that a good assumption, or is this failure telling me something about a mismatch between DMU map units and actual MapUnits? Thanks so much! Alexander N. Steely, PhD, LG (he/him) Assistant State Geologist Assistant Director of Geologic Hazards and Mapping Washington Geological Survey Cell: 360-999-0115 ***@***.******@***.***> From: Evan Thoms ***@***.***> Sent: Monday, March 18, 2024 1:43 PM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Have you checked both fields for leading or trailing empty spaces? - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKO3ZQAC4BHLWD35PETYY5GV5AVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUHE2TCMRVGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ethoms-usgs]

Sorry, Alex. I didn't look super closely at the error message at first, but the report suggests to me that Arc is running a cached version of the script and may not be the most recent. See in the error message how it says that the error is happening when it hits line 447? That line is a comment; it can't trigger an error. This can happen when the application does not know about a new version that should replace a cached version. Can you close everything down and then try again?

[wgs-asteely]

Hey Evan, Fascinating. So I have restarted my machine a bunch of times during this. And I just downloaded and used the 12.13 version instead of 12.9 that I had been. No change. Still errors out at the same place with the same error. So I deleted the default gdb and default toolbox. And changed locations for all the gems tools. Still same error. Very puzzling... From: Evan Thoms ***@***.***> Sent: Monday, March 18, 2024 6:13 PM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Sorry, Alex. I didn't look super closely at the error message at first, but the report suggests to me that Arc is running a cached version of the script and may not be the most recent. See in the error message how it says that the error is happening when it hits line 447? That line is a comment; it can't trigger an error. This can happen when the application does not know about a new version that should replace a cached version. Can you close everything down and then try again? - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKK25LVD7JCY35OB573YY6GLLAVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBVGU2TCOBUGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ethoms-usgs]

Ok. Thanks for trying that. Can you send me the gdb?

[wgs-asteely]

Sure. Thanks so much for taking a look! I'm attaching here...
KittitasEastKittitas_geologicmap_14MAR2024.gdb.zip

[ethoms-usgs]

Odd, I just ran the tool on it and there were no code errors. When you downloaded the new toolbox, did you completely replace the older folder? Also, try downloading to a new empty folder in a different location and try it from there.

[wgs-asteely]

Hey Evan, So strange. We'll I'm glad it is error free, but I do need to convince my computer it is too. I have replaced the older tool folder. Renamed the gdb. Started from a blank map project. Disconnected from our vpn and stored everything locally. Deleted again everything in my default Arc locations (I think). And still the same issue. Aside from a fresh ArcPro install I'm not sure what else to do. You said that this can happen when Arc is looking to a cached version of the GeMS_validate script...do you know where that might live? Thanks, Alex From: Evan Thoms ***@***.***> Sent: Tuesday, March 19, 2024 2:33 PM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Odd, I just ran the tool on it and there were no code errors. When you downloaded the new toolbox, did you completely replace the older folder? Also, try downloading to a new empty folder in a different location and try it from there. - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKME724AGHXEXO646OLYZCVKLAVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBYGE3TENRQHA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wynaut]

I am also not able to replicate the error... Interestingly, I'm not even able to trigger rule 3.9 on purpose on this one -- nonsense units added to the DMU get totally skipped over! It's also not flagging the null values in DescriptionSourceID (Ql, hy).

I thought it might have something to do with having 'geologicmap' in the gdb name (since that's also the feature dataset's name), or with Windows' path length limit. But no...

[ethoms-usgs]

Should have looked at ESRI earlier:

https://community.esri.com/t5/arcgis-pro-questions/scripting-tool-does-not-return-line-error/td-p/1262701

Alex, what version of Pro are you on? They say this bug has been addressed in 3.2

[ethoms-usgs]

@wynaut, uh oh, really? I get validation errors when I add an unused unit and it catches null values in _ID

[wgs-asteely]

Hmm. Very strange. We're all on 2.9 still and there is no real plan to get to 3.x anytime soon. So...there is an error, but it's just not at the location it says it is? As people in that Esri thread said...that's not very helpful :-/ From: Evan Thoms ***@***.***> Sent: Wednesday, March 20, 2024 2:17 PM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Should have looked at ESRI earlier: https://community.esri.com/t5/arcgis-pro-questions/scripting-tool-does-not-return-line-error/td-p/1262701 Alex, what version of Pro are you on? They say this bug has been addressed in 3.2 - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKK5LP5HJ3SYLELCPDLYZH4FPAVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGY2TINRYGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wgs-asteely]

Evan, I double checked that I can run the script just fine on other gdbs. So, at least to my computer, there is something different and problematic about the KittitasEastKittitas gdb. From: Evan Thoms ***@***.***> Sent: Wednesday, March 20, 2024 2:17 PM To: DOI-USGS/gems-tools-pro ***@***.***> Cc: Steely, Alex (DNR) ***@***.***>; Author ***@***.***> Subject: Re: [DOI-USGS/gems-tools-pro] Validate gdb fails at step 3.9 (Issue #101) External Email Should have looked at ESRI earlier: https://community.esri.com/t5/arcgis-pro-questions/scripting-tool-does-not-return-line-error/td-p/1262701 Alex, what version of Pro are you on? They say this bug has been addressed in 3.2 - Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BHACYKK5LP5HJ3SYLELCPDLYZH4FPAVCNFSM6AAAAABEYR63E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGY2TINRYGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>