search

DOI-USGS / gems-tools-arcmap

Tools for working with the GeMS geologic map database schema in ArcGIS
Creative Commons Zero v1.0 Universal
42 stars 21 forks source link

FGDC metadata, step 1 #67

Open williamjunkin opened 3 years ago

williamjunkin commented 3 years ago

I am getting an error using the FGDC metadata, step 1 tool and I am out of ideas. The error seems to have something to do with one of the entries in my datasources table. I have been researching solutions but I am a bit out of my league and not sure where to start. I have copied and pasted the error text and attempted to include a screenshot below. I appreciate any ideas.

Traceback (most recent call last): File "C:\Users\wjunkin\Desktop\ArcGIS_files\GeMS\gems-tools-arcmap-master\Scripts\GeMS_FGDC1_Arc10.py", line 189, in titleText = titleText + ' '+str(row[2]) UnicodeEncodeError: 'ascii' codec can't encode character u'\u2014' in position 102: ordinal not in range(128)

Failed to execute (Metadata-FGDC1).

image

ethoms-usgs commented 3 years ago

The problem character is an em-dash, which looks like it would be in your DAS5. If you don't care about changing that to a hyphen, that would be the short-term solution. But I will also edit a fix and update the tool.

williamjunkin commented 3 years ago

Thanks so much--that was the issue. I fixed it but unfortunately got another inscrutable (to me) error immediately.

image

I looked up Error 000229 and attempted to run the tool with background processing turned off, but I got the same error.

I really appreciate the help with this. I am required to turn in a gems-compliant product but I have no python experience and these error messages are a bit over my head.

ethoms-usgs commented 3 years ago

I have seen that error when the table is open in table view in ArcMap. If it does not work when you close the table -- even saving the mxd might not clear out the view lock -- close and re-open the mxd and try again.

williamjunkin commented 3 years ago

I tried closing the table view, saving, closing the mxd, reopening and running the tool--but same error message.

ethoms-usgs commented 3 years ago

Ok, try these steps.

williamjunkin commented 3 years ago

Ok! That seems to have worked for now. Thanks so much for the help

alwunder commented 2 years ago

To the original problem, I was having the exact same issue. The fix is a simple one. The str() command uses the default character encoding to encode the bytes passed to it. In this case, the unicode character for the em dash. If you look two lines above, the answer is there: force Python to encode the string as ASCII, and ignore the character if it's outside the ASCII range. The original code is posted, followed by the updated code:

Throws the encoding error: if row[2] <> None: titleText = titleText + ' ' + str(row[2])

No error: if row[2] <> None: titleText = titleText + ' ' + str(row[2].encode("ASCII",'ignore'))

If you have many unicode characters, you might consider revising your DataSources table, as this method simply skips over the offending characters which might not be acceptable. I have gone through my lists of sources and replaced the few em dashes with "--" and en dashes with a simple hyphen to avoid this problem.

Hope this helps explain the issue!

alwunder commented 2 years ago

To the original problem, I was having the exact same issue. The fix is a simple one. The str() command uses the default character encoding to encode the bytes passed to it. In this case, the unicode character for the em dash. If you look two lines above, the answer is there: force Python to encode the string as ASCII, and ignore the character if it's outside the ASCII range. The original code is posted, followed by the updated code:

Throws the encoding error: if row[2] <> None: titleText = titleText + ' ' + str(row[2])

No error: if row[2] <> None: titleText = titleText + ' ' + str(row[2].encode("ASCII",'ignore'))

If you have many unicode characters, you might consider revising your DataSources table, as this method simply skips over the offending characters which might not be acceptable. I have gone through my lists of sources and replaced the few em dashes with "--" and en dashes with a simple hyphen to avoid this problem.

Hope this helps explain the issue!

So, I just downloaded the most recent version dated August 24, and I see that Evan fixed the problem in two ways. First, he added the ".encode..." method to the offending str() command. Second, he changed the encoding from "ASCII" to "utf-8" which solves the problem of unicode characters entirely.

Thank you, Evan!

ethoms-usgs commented 2 years ago

Ah, good! I saw your earlier posts come across but I didn't have time to check in. Our encoding problems with the ArcMap toolset seem to resurrect themselves even after "fixes" so I hope this sticks!