yields an error:
v.in.ascii input=C:\cygwin\home\andy\models_temp\Bloomday_Olive_11set10_Avg output=test_US_import fs=\t
Scanning input for column types...
Maximum input row length: 31
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: double
Importando punti ...
Populating table...
ERROR: Could not close attribute table. The DBMI driver did not accept all attributes
Trying same test with an old (May 29) WinGRASS-6.4.svn installed on the same machine (same command), everything seems ok:
v.in.ascii --overwrite input=C:\cygwin\home\andy\models_temp\Bloomday_Olive_11set10_Avg output=test_US_import fs=\t
Scanning input for column types...
Maximum input row length: 31
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: double
Importando punti ...
Populating table...
Building topology for vector map <test_US_import>...
Registering primitives...
10001157 primitives registered
1157 vertices registered
Building areas...
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
Number of nodes: 1154
Number of primitives: 1157
Number of points: 1157
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.in.ascii completo.
Ticket created.
Any ideas? A change introduced in 6.4.0-1 has rendered WinGRASS unusable to me -- or am I doing something wrong?
I am wondering if there is a way by which I can restore v.in.ascii functionality in 6.4.0 until a fix is found for the problem. I am probably asking an unsound question: is there a way to compile the code in the state it was before the issue arose? During the first half of this year, Windows installers based on 6.4.svn snapshots have run smoothly for critical job tasks, and I have started to rely on them.
I am wondering if there is a way by which I can restore v.in.ascii
functionality in 6.4.0 until a fix is found for the problem. I am
probably asking an unsound question: is there a way to compile the code
in the state it was before the issue arose?
You can prevent the error with:
--- vector/v.in.ascii/in.c~ 2010-09-04 16:31:59.000000000 +0100
+++ vector/v.in.ascii/in.c 2010-09-21 08:57:12.000000000 +0100
@@ -519,8 +519,7 @@
if (driver) {
G_message(_("Populating table..."));
db_commit_transaction(driver);
- if(db_close_database_shutdown_driver(driver) == DB_FAILED)
- G_fatal_error(_("Could not close attribute table. The DBMI driver did not accept all attributes"));
+ db_close_database_shutdown_driver(driver);
}
fclose(tmpascii);
}
db_close_database_shutdown_driver() is incorrectly reporting errors on
Windows. v.in.ascii is the only module which checks the return status,
so it's the only module which is affected.
Any ideas? A change introduced in 6.4.0-1 has rendered WinGRASS
unusable to me [...]
[...] is there a way to compile the code
in the state it was before the issue arose?
You can prevent the error with:
--- vector/v.in.ascii/in.c~ 2010-09-04 16:31:59.000000000 +0100
+++ vector/v.in.ascii/in.c 2010-09-21 08:57:12.000000000 +0100
@@ -519,8 +519,7 @@
if (driver) {
G_message(_("Populating table..."));
db_commit_transaction(driver);
- if(db_close_database_shutdown_driver(driver) == DB_FAILED)
- G_fatal_error(_("Could not close attribute table. The DBMI driver did not accept all attributes"));
+ db_close_database_shutdown_driver(driver);
}
fclose(tmpascii);
}
db_close_database_shutdown_driver() is incorrectly reporting errors on
Windows. v.in.ascii is the only module which checks the return status,
so it's the only module which is affected.
GRASS 6.4> echo “10|10|abcd” | v.in.ascii out=test
Scanning input for column types…
Maximum input row length: 11
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: string length: 4
Importando punti …
100%
Populating table…
Building topology for vector map …
Registering primitives…
1 primitives registered
1 vertices registered
Building areas…
100%
0 areas built
0 isles built
Attaching islands…
Attaching centroids…
100%
Number of nodes: 1
Number of primitives: 1
Number of points: 1
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.in.ascii completo.
GRASS 6.4> v.in.ascii --overwrite input=Bloomday_Olive_11set10_Avg output=test_US_import fs=tab
ATTENZIONE: Vector map <test_US_import> already exists and will be
overwritten
Scanning input for column types…
Maximum input row length: 31
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: double
Importando punti …
100%
Populating table…
Building topology for vector map <test_US_import>…
Registering primitives…
1157 primitives registered
1157 vertices registered
Building areas…
100%
0 areas built
0 isles built
Attaching islands…
Attaching centroids…
100%
Number of nodes: 1154
Number of primitives: 1157
Number of points: 1157
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.in.ascii completo.
We don't provide message catalogues for (any dialect of) English; we
just use the untranslated strings.
The "C" locale doesn't use translations, while en_US would perform
translations using an en or en_US catalogue (if one existed; if the
catalogue doesn't exist, the untranslated strings are output).
Ideally, you should use:
export LC_ALL=C
if you intend to post the output. This provides "unlocalised"
behaviour for all categories (no message catalogues, ASCII encodings,
case conversion rules, etc).
GRASS itself only uses the LC_MESSAGES and LC_CTYPE categories, and
forces LC_NUMERIC to "C" (so that floating-point values use a dot
rather than a comma as the decimal separator). LC_CTYPE determines the
encoding and case conversion rules. However, some libraries might use
other categories (in particular, Python sets LC_CTYPE from the
environment, which why we force it back to "C" in G_gisinit()).