Opened 10 years ago
Closed 10 years ago
#2539 closed defect (fixed)
v.in.ogr: error importing shapefiles: ValueError : too many values to unpack
| Reported by: | richardc | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | 7.0.0 |
| Component: | wxGUI | Version: | svn-releasebranch70 |
| Keywords: | wxgui vector import wizard | Cc: | |
| CPU: | x86-32 | Platform: | Linux |
Description
Probably related to https://trac.osgeo.org/grass/ticket/2537
I'm getting the following error on attempting to import a shape file, without success, with v.in.ogr.
Layer Manager > File > Import vector data > Common import formats [v.in.ogr] Browse to select file
From the command console:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-
packages/wx-2.8-gtk2-unicode/wx/lib/filebrowsebutton.py",
line 140, in OnChanged
self.changeCallback(evt)
File "/home/rcooper/grass70/grass-7.0.0svn/gui/wxpython/gu
i_core/gselect.py", line 1920, in OnUpdate
self._reloadLayers()
File "/home/rcooper/grass70/grass-7.0.0svn/gui/wxpython/gu
i_core/gselect.py", line 1945, in _reloadLayers
layerName, featureType, projection = map(lambda x:
x.strip(), line.split(','))
ValueError
:
too many values to unpack
{{{
And after clicking Import, I receive the following popup message:
No layers selected. Operation canceled
The above relates to 7.0.0svn:
{{{
System Info
GRASS version: 7.0.0svn
GRASS SVN Revision: 63929
Build Date: 2015-01-02
Build Platform: i686-pc-linux-gnu
GDAL/OGR: 1.11.1
PROJ.4: 4.9.0
GEOS: 3.4.2
SQLite: 3.7.9
Python: 2.7.3
wxPython: 2.8.12.1
Platform: Linux-3.2.0-31-generic-pae-i686-with-LinuxMint-13-maya
}}}
I've tried with a couple of shapefiles.
}}}
Change History (11)
follow-up: 2 comment:1 by , 10 years ago
| Component: | Vector → wxGUI |
|---|---|
| Keywords: | wxgui wizard added; v.in.ogr removed |
| Priority: | critical → blocker |
comment:2 by , 10 years ago
Replying to mlennert:
I can confirm this error on a freshly checkouted and compiled grass70release tree.
Bumping this up to blocker as this is fundamental functionality of the GUI.
tested and not confirmed by
System Info GRASS Version: 7.1.svn GRASS SVN Revision: 64069 Erstellungsdatum: 2015-01-12 Build Platform: i686-pc-mingw32 GDAL/OGR: 1.11.1 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
follow-up: 4 comment:3 by , 10 years ago
I cannot reproduce this bug. Please can you check it again with the fresh installation?
follow-ups: 5 6 9 comment:4 by , 10 years ago
Replying to martinl:
I cannot reproduce this bug. Please can you check it again with the fresh installation?
I have trouble finding a clear logic in all this as sometimes it seems to work and sometimes not. But I think I found a candidate of what might explain it 1, but only with gdal < 1.11 :
312 #if GDAL_VERSION_NUM >= 1110000
313 for (igeom = 0; igeom < OGR_FD_GetGeomFieldCount(Ogr_featuredefn); igeom++) {
314 Ogr_geomdefn = OGR_FD_GetGeomFieldDefn(Ogr_featuredefn, igeom);
315 if (!Ogr_geomdefn) {
316 G_warning(_("Invalid geometry column %d"), igeom);
317 continue;
318 }
319
320 Ogr_geom_type = OGR_GFld_GetType(Ogr_geomdefn);
321 fprintf(fd, "%s,%s,%d,%s\n", layer_name,
322 feature_type(OGRGeometryTypeToName(Ogr_geom_type)),
323 proj_same, OGR_GFld_GetNameRef(Ogr_geomdefn));
324 }
325 #else
326 fprintf(fd, "%s,%s,%d,\n", layer_name,
327 feature_type(OGRGeometryTypeToName(Ogr_geom_type)),
328 proj_same);
329 #endif
Line 326 reads:
fprintf(fd, "%s,%s,%d,\n"
should the last comma really be there ? Erasing it away seems to solve the problem for me.
However, this would not explain the problem for RichardC as he seems to be working with gdal 1.11...
Moritz
comment:5 by , 10 years ago
Replying to mlennert:
Replying to martinl:
I cannot reproduce this bug. Please can you check it again with the fresh installation?
I have trouble finding a clear logic in all this as sometimes it seems to work and sometimes not.
I updated v.external to report also geometry columns, see (1). The bug was related to PostgreSQL format for which v.external is not using GDAL library by default, but it's own implementation. Now it should be fixed.
(1) http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields
follow-up: 7 comment:6 by , 10 years ago
Replying to mlennert:
should the last comma really be there ? Erasing it away seems to solve the problem for me.
sorry, what kind of problems?
follow-up: 8 comment:7 by , 10 years ago
Replying to martinl:
Replying to mlennert:
should the last comma really be there ? Erasing it away seems to solve the problem for me.
sorry, what kind of problems?
The "ValueError: too many values to unpack" error when trying to use the vector import wizard to import a shapefile. This is a different bug (but probably of similar origin) than #2537.
comment:8 by , 10 years ago
Replying to mlennert:
The "ValueError: too many values to unpack" error when trying to use the vector import wizard to import a shapefile. This is a different bug (but probably of similar origin) than #2537.
As I already wrote, I cannot reproduce this bug. Are you sure that you have a fresh installation?
comment:9 by , 10 years ago
Replying to mlennert:
However, this would not explain the problem for RichardC as he seems to be working with gdal 1.11...
I have tested GRASS with GDAL 1.11, no problem.
follow-up: 11 comment:10 by , 10 years ago
I'm really losing the little that is left of my hair over this... ;-)
I did a completely fresh checkout of relbr70 this morning and could confirm the issue. Now I did the same and the issue seems to have gone away. IIUC, the issue was fixed with r64041, changing
layerName, featureType, projection = map(lambda x: x.strip(), line.split(','))
to
layerName, featureType, projection, geometryColumn = map(lambda x: x.strip(), line.split(','))
in gui/wxpython/gui_core/gselect.py, thus solving the issue of only three variables, but four values.
I don't understand why I still saw this error this morning, though.
I'll check out, recompile and test tomorrow on other machines running with gdal 1.10. I'll keep it open until then.
P.S. Could it be that certain gui files are not updated with 'make distclean; svn up; configure; make' ? I shouldn't have to do fresh checkouts everytime...
comment:11 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Replying to mlennert:
I'm really losing the little that is left of my hair over this... ;-)
I did a completely fresh checkout of relbr70 this morning and could confirm the issue. Now I did the same and the issue seems to have gone away. IIUC, the issue was fixed with r64041, changing
layerName, featureType, projection = map(lambda x: x.strip(), line.split(','))to
layerName, featureType, projection, geometryColumn = map(lambda x: x.strip(), line.split(','))in gui/wxpython/gui_core/gselect.py, thus solving the issue of only three variables, but four values.
I don't understand why I still saw this error this morning, though.
I'll check out, recompile and test tomorrow on other machines running with gdal 1.10. I'll keep it open until then.
Just did that with relbr7 and everything seems to work, now. Thanks for the fixes.
Closing the ticket.
Moritz
I can confirm this error on a freshly checkouted and compiled grass70release tree.
Bumping this up to blocker as this is fundamental functionality of the GUI.