-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Converting a GeoJSON that has a list-of-strings for a property fails with AttributeError: 'str' object has no attribute 'items'
#125
Comments
Thanks for raising the issue! Clear description. I'll have a look how to support this enhancement |
Thanks, @mattijn -- much appreciated! Note that things like bounding boxes also currently fail:
|
Thanks, @mattijn -- I've confirmed it works on our system internally too. Thank you so much for helping us with this, as a non-profit, these types of packages make all the difference in the work we're able to do. :-) |
Great! I'm glad its useful for you and others! |
We've been playing with this topojson library for automating topojson conversion from our geojsons (which we need to do to get our maps to work in Looker), and wanted to first say thanks for creating such a useful library!
Background of issue
One of our GeoJSON fields is a list of strings, e.g.:
This is valid, and has the nice benefit that tools like QGIS provide an editor around these lists like so:
Issue in topojson library
When running the topojson library on one of these files, an exception is generated:
Looking at the
_resolve_objects
function in hashmap.py, it has this chunk of code:The last branch of the if/else here that checks if the instance is of type
list
callsself._resolve_objects
with each item from the list, which in the case of a string-set for properties, means the individual string values are being passed into_resolve_objects()
. This then fails becausek, v in dictionary.items()
attempts to call items() on the string value as though it were a dict.Proposed Solution
I'm not sure what the expected behavior of
_resolve_objects
should be here to be more fully compliant with the GeoJSON spec. Having debugged this and traced down the source of the issue, I wanted to open the issue and provide the details of what we learned. For now, we're stepping around this issue by converting the list-of-strings to a basic comma-delimited string.The text was updated successfully, but these errors were encountered: