On Mon, Sep 12, 2011 at 8:24 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
Try r48225.
Now a different one:
line 267, in main
? ? y, z = yz.split(' ')
ValueError: too many values to unpack
I've improved m.proj as much as I can.
Thanks for your efforts!
Still...
v.out.gps -t input=railroads output=trail.gpx
Traceback (most recent call last):
File "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/m.proj",
line 288, in <module>
main()
File "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/m.proj",
line 267, in main
x, y = xy.split('\t')
ValueError: need more than 1 value to unpack
I don't know this script, but this error means that the string xy has more than 2 items that are separated by a tab (or by a space in the earlier post).
xy = "item_a item_b item_c"
x,y = xy.split(" ")
will produce this error. There are several ways to fix it.
1) change xy so that it is only containing 2 items
2) change the parsing of xy to: x,y = xy.split(" ")[0:2]
(this gets the first 2 items and ignores the rest
3) put the statement inside an error trap like try/except
Michael
The main problem is that, when cs2cs is run with the -E flag, it
appears to copy the input semi-verbatim, meaning that the output
format varies according to the input format. This makes it impossible
to reliably parse the output from cs2cs.
I believe that cs2cs should get the equivalent to the -g flag in GRASS which
makes the output truely machine-readable.
Perhaps we concentrate on more important issues than v.out.gps and
let it rest for now. Thanks, Glynn, I am sure that m.proj is way better now.
> line 267, in main
> x, y = xy.split('\t')
> ValueError: need more than 1 value to unpack
I don't know this script, but this error means that the string xy
has more than 2 items that are separated by a tab (or by a space in
the earlier post).
Wrong. In that case, the error would be "too many values to unpack".
In this case, the error is that there are too few values: splitting
the string results in a single value (i.e. there are *zero* tabs),
when two values are expected.
I can't actually reproduce this error.
The problems which I had with cs2cs were related to the case where the
-E flag was used (when copy_input is True). In that situation, cs2cs
copies some prefix of the input to the beginning of the output,
complete with whatever whitespace it contained, and also copied some
portion of the input to the end of the output, again with whitespace
intact.
This means that the two fields we're actually interested in are
bracketed by arbitrary text containing (apparently) arbitrary
whitespace, which makes identifying those fields impossible.
You're right of course. Somehow I read the ValueError wrong. A dyslexic or senior moment I suppose.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
On Sep 13, 2011, at 3:16 AM, Glynn Clements wrote:
Michael Barton wrote:
line 267, in main
x, y = xy.split('\t')
ValueError: need more than 1 value to unpack
I don't know this script, but this error means that the string xy
has more than 2 items that are separated by a tab (or by a space in
the earlier post).
Wrong. In that case, the error would be "too many values to unpack".
In this case, the error is that there are too few values: splitting
the string results in a single value (i.e. there are *zero* tabs),
when two values are expected.
I can't actually reproduce this error.
The problems which I had with cs2cs were related to the case where the
-E flag was used (when copy_input is True). In that situation, cs2cs
copies some prefix of the input to the beginning of the output,
complete with whatever whitespace it contained, and also copied some
portion of the input to the end of the output, again with whitespace
intact.
This means that the two fields we're actually interested in are
bracketed by arbitrary text containing (apparently) arbitrary
whitespace, which makes identifying those fields impossible.
Warning: Macro "GS_NEAR_EQUAL" depends on an unknown identifier
"GS_BETWEEN". Macro "GS_NEAR_EQUAL" will not be output
Warning: Macro "GS_NEAR_EQUAL" depends on an unknown identifier
"GS_BETWEEN". Macro "GS_NEAR_EQUAL" will not be output
Status: Writing to ogsf.py.
Status: Wrapping complete.
A few more other warnings also appear - no idea if that matters.
Warning: Macro "GS_NEAR_EQUAL" depends on an unknown identifier
"GS_BETWEEN". Macro "GS_NEAR_EQUAL" will not be output
Warning: Macro "GS_NEAR_EQUAL" depends on an unknown identifier
"GS_BETWEEN". Macro "GS_NEAR_EQUAL" will not be output
If any C code used GS_NEAR_EQUAL, you'd get an "undefined symbol"
error for GS_BETWEEN, but the compiler won't care about errors in
macros which are never used.
However, ctypes translates macros to Python functions, so it has to
parse the macro body.