Catch errors extracting names more selectively #171
Conversation
stevenday
force-pushed
the
issues/168-encoding-errors-during-import
branch
from
946bebf
to
1d6d01b
Compare
This changes the logic for extracting and decoding the name from a feature so that Exceptions are caught more selectively and the right errors are reported to the user. Previously, a UnicodeDecodeError could occur when the name field was read (because internally, the GDAL api uses force_text on the output) and the code would catch it but instead report that the name field didn't exist. This was confusing on files with encoding errors. Closes #168
stevenday
force-pushed
the
issues/168-encoding-errors-during-import
branch
from
1d6d01b
to
ee34937
Compare
|
Hmm, the test passes fine for me locally but fails on Travis. It's failing because it's not raising an error during the import at all when I'm trying to test the error message is the right one - I wonder if it's something about my versions? (Python 2.7.3, Django 1.7) |
|
I do get the same error locally, python 2.7.9, django 1.7.1. I think the difference will be in the version of GDAL (or underlying library) that is installed; it looks like my version is returning the string with the |
| "Could not find name using name field '%s' - should it be something else? " | ||
| "It will be one of these: %s. Specify which with --name_field" % (name_field, choices)) | ||
| try: | ||
| name = feat.get(name_field) |
There was a problem hiding this comment.
I think Feature's get() throws an OGRIndexError exception if name_field isn't present, unlike the normal pythonic get(), so the None check won't be reached.
|
So since my PR has it's own problems, and it's really a problem with the underlying GDAL library, I don't think this is much of an improvement, I'll retract! |
Closes #168