FGDC metadata, step 1

[williamjunkin]

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).

[ethoms-usgs]

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]

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

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]

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]

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

[ethoms-usgs]

Ok, try these steps.

• In Windows Explorer, with all ESRI software closed, look for and delete any .LOCK files that might be hanging out in the gdb folder
• Try the tool from the standalone ArcCatalog app, not the floating ArcCatalog window in an ArcMap session.

[williamjunkin]

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

[alwunder]

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]

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]

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!