Fwd from Ivan, I wonder how G_scan_easting() and G_scan_northing() fit into
this problem? (for 1.2345e6 not 123:45:54.321E; 31E needs to be considered
East)
--Hamish
Note: forwarded message attached.
____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Hi,
2007/11/25, Hamish <hamish_nospam@yahoo.com>:
Fwd from Ivan, I wonder how G_scan_easting() and G_scan_northing() fit into
I do not fully understand this notation
this problem? (for 1.2345e6 not 123:45:54.321E; 31E needs to be considered
East)
anyway
$ cat pok.txt
123:45:54.321E|80N
1.2376508917e2|80N
$ v.in.ascii in=pok.txt out=pok
$ v.out.ascii pok
123.76508917|80|1
123.76508917|80|2
works for me...
Martin
--Hamish
Note: forwarded message attached.
____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ---------- Messaggio inoltrato ----------
From: Ivan Shmakov <ivan@theory.asu.ru>
To: Hamish <hamish_nospam@yahoo.com>
Date: Sun, 25 Nov 2007 15:36:50 +0600
Subject: Re: [GRASS-user] scientific notation
[...]>> Can GRASS actualy deal with number written with scientific notation ?
>> Is there a specific way to deal with these numbers ?> v.in.ascii coulumn scanning code seems to overlook that case.
[...]
Since my message has apparently not reached grass-dev, and since
you're interested in this problem, I'm forwarding it to you.
The problem seems to me somewhat trivial to solve.---------- Messaggio inoltrato ----------
From: Ivan Shmakov <ivan@theory.asu.ru>
To: Martin Landa <landa.martin@gmail.com>
Date: Sat, 24 Nov 2007 22:35:48 +0600
Subject: Re: scientific notation
>>>>> Martin Landa <landa.martin@gmail.com> writes:[...]
>> I would like to import points data in GRASS (with v.in.ascii). My
>> data includes number written with the scientific notation (for
>> example 1.2e+23). During the import, I am defining them as double.
>> Unfortunately, it doesn't work...>> I get the following message :
>> " ERROR: Column 9 defined as double has string values ">> Can GRASS actualy deal with number written with scientific notation ?
>> Is there a specific way to deal with these numbers ?> no, it seems, v.in.ascii doesn't support it...
It seems that it's the is_double () function which behaves in a
wrong way:$ nl -ba grass-6.3.cvs_src_snapshot_2007_11_03/vector/v.in.ascii/points.c
...
30 /* Determine if the string is double, e.g. 123.456, +123.456, -123.456
31 * return 1 if double, 0 otherwise */
32 static int is_double(char *str)
33 {
34 int i = -1, ndots = 0;
35
36 while (str[++i] != '\0') {
37 if (i == 0 && (str[i] == '+' || str[i] == '-'))
38 continue;
39
40 if (str[i] == '.') {
41 if (ndots > 0)
42 return 0; /* > 1 dot */
43
44 ndots++;
45 continue;
46 }
47
48 if (!isdigit(str[i]))
49 return 0;
50 }
51
52 return 1;
53 }
...
$IIUC, the number is to be converted from its string
representation by atof () later. Since, I assume, atof ()
supports e-notation, there's no necessity in such a strict check
like is_double () currently performs. Therefore, I suggest
is_double () to be reimplemented on top of strtod () instead,
e. g.:static int
is_double (char *s)
{
char *tail;if (strtod (s, &tail),
tail == s || *tail != '\0') {
/* doesn't look like a number,
or has extra characters after what looks to be a number */
return 0;
}return 1;
}BTW, is_int () could be rewritten as well.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
re. yesterday's v.in.ascii changes, rev 1.51
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.ascii/in.c
"Changes since 1.50: +465 -425 lines
Run indent
Message standardization"
Please do not mix code changes with indent changes!
It makes it very hard to review the code changes.
SUBMITTING rule 15:
Existing code should not be re-indented except in extreme cases, as this
will make "diff" comparisons with older versions impossible. If indent is
needed, do not check in any changes other than the indentation in the same
commit! Do add the indent switches and any indent warning messages to the
CVS log. Any change or fix mixed in with an indent is very hard to track
making it hard for others to follow the change or fix any new bugs.
and changing the v.in.ascii columns= option to use
G_define_standard_option(G_OPT_COLUMNS) is not very safe as the standard option
is really meant for a different column= task. If in future someone changed the
parser.c definition for the intended task, v.in.ascii's option could change in
an undesirable way.
note that by doing that you have changed the name of the option in an
incompatible way-
v.in.ascii was:
columns_opt->key = "columns";
while parser.c sets it to
case G_OPT_COLUMNS:
Opt->key = "column";
Anyone who scripted "columns=" will now get an error.
(regardless of above, perhaps it would be a good idea to change G_OPT_COLUMNS
to key->"columns" in parser.c? the change would be backwards compatible as the
options work on minimum letter match)
thanks,
Hamish
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
Hamish,
2007/11/26, Hamish <hamish_nospam@yahoo.com>:
re. yesterday's v.in.ascii changes, rev 1.51
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.in.ascii/in.c"Changes since 1.50: +465 -425 lines
Run indent
Message standardization"Please do not mix code changes with indent changes!
It makes it very hard to review the code changes.SUBMITTING rule 15:
Existing code should not be re-indented except in extreme cases, as this
will make "diff" comparisons with older versions impossible. If indent is
needed, do not check in any changes other than the indentation in the same
commit! Do add the indent switches and any indent warning messages to the
CVS log. Any change or fix mixed in with an indent is very hard to track
making it hard for others to follow the change or fix any new bugs.
well, sorry.
and changing the v.in.ascii columns= option to use
G_define_standard_option(G_OPT_COLUMNS) is not very safe as the standard option
is really meant for a different column= task. If in future someone changed the
parser.c definition for the intended task, v.in.ascii's option could change in
an undesirable way.note that by doing that you have changed the name of the option in an
incompatible way-
v.in.ascii was:
columns_opt->key = "columns";while parser.c sets it to
case G_OPT_COLUMNS:
Opt->key = "column";Anyone who scripted "columns=" will now get an error.
(regardless of above, perhaps it would be a good idea to change G_OPT_COLUMNS
to key->"columns" in parser.c? the change would be backwards compatible as the
options work on minimum letter match)
already done
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gis/parser.c.diff?r1=1.133&r2=1.134
Martin
thanks,
Hamish____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hamish
> Please do not mix code changes with indent changes!
> It makes it very hard to review the code changes.
Martin wrote:
Hamish,
..
well, sorry.
just a friendly reminder to everyone 
Hamish
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs