I'm converting a raster to a vector with r.to.vect. The geometries are
converted successfully to vector shapes, but I noticed I was unable to work
further on the vectors' attribute table. When trying to add a field, I
received the following message:
Coor files of vector map <vector_map@test> is larger than it should be
(94546466 bytes excess)
I then tried to open up the attribute table and was told that the attribute
table <vector_map> could not be found. Interesting. A glance under the tab
"Manage Tables" showed no tables at all; I moved on to "Manage Layers" and
found only one layer, linked to my grass base and then
/Test/test/dbf/vector_map with the key cat. However, in my file manager I
don't see any such file, even when also viewing hidden files.
I tried connecting a new table with v.db.addtable, but got:
v.db.addtable map=vector_map@test table=test
Using user specified table name: test
ERROR: There is already a table linked to layer <1>
I've been able to duplicate this problem multiple times with the same
raster, but other vector maps I make from other rasters are created fine,
also with tables. Could the problem be connected to the high number of
features in the vector map? It's got almost a million. However, I've also
worked with vectors with more, which makes me doubt that hypothesis.
Alright, I've run the same test again with the same raster after having
deleted my mapset and importing it again into another location. I've read a
lot in the forums about coor files being too large and it seems that my
hypothesis of the vector being too large is completely invalid. Here some
additional info:
When I use v.build I get the same error:
Coor files of vector map <homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Nonetheless, v.build runs to the end.
Trying to add a column after running v.build gives me the same problem. I
get the following message:
Coor files of vector map <homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Coor files of vector map <homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Coor files of vector map <homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
DBMI-DBF driver error:
Table 'homogeneous_areas' doesn't exist.
Error in db_execute_immediate()
ERROR: Error while executing: 'ALTER TABLE homogeneous_areas ADD COLUMN area
double precision
'
ERROR: Cannot continue (problem adding column).
Still no further.
Running v.digit also doesn't help; I have the same problem. I also tried
exporting the vector as a shapefile and that didn't work either; GRASS
complained about not being able to access the level 2 topology data.
Any help would be appreciated, or at least a nudge in the right direction.
I've read a lot of stuff online but haven't found anything that helps me in
this situation yet and am confident that GRASS can do this... The coor file
is only 90 MiB large with a topo file of 231.8 MiB, therefore not huge
files. Of course, I wouldn't mind doing it with r.area, but my thread there
has also died off... People, I'm sorry if I'm asking stupid questions but at
least I'm trying!
Bad news for You - that vector file is corrupted. If You just imported
it - it failed to import correctly. If You run some other module - it
corrupted that file (and it's a bug). Also it lacks attribute table.
Also - when You ask for help, don't forget to include such details as
GRASS version, OS, LFS/64bit-ness and GRASS source (SVN or
distribution packages).
Alright, I've run the same test again with the same raster after having
deleted my mapset and importing it again into another location. I've read a
lot in the forums about coor files being too large and it seems that my
hypothesis of the vector being too large is completely invalid. Here some
additional info:
When I use v.build I get the same error:
Coor files of vector map<homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Nonetheless, v.build runs to the end.
Trying to add a column after running v.build gives me the same problem. I
get the following message:
Coor files of vector map<homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Coor files of vector map<homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
Coor files of vector map<homogeneous_areas@PERMANENT> is larger than it
should be (94546466 bytes excess)
DBMI-DBF driver error:
Hi Daniel:
I've lost the train of your specific problem, so this suggestion might be "off the wall" but you might try switching to an sqlite database rather than dbf files. Sqlite, I believe, handles large tables better, and it has a richer set of SQL compatible query options, etc.
That's done with the db.connect command
Table 'homogeneous_areas' doesn't exist.
Error in db_execute_immediate()
ERROR: Error while executing: 'ALTER TABLE homogeneous_areas ADD COLUMN area
double precision
'
ERROR: Cannot continue (problem adding column).
Still no further.
Running v.digit also doesn't help; I have the same problem. I also tried
exporting the vector as a shapefile and that didn't work either; GRASS
complained about not being able to access the level 2 topology data.
Any help would be appreciated, or at least a nudge in the right direction.
I've read a lot of stuff online but haven't found anything that helps me in
this situation yet and am confident that GRASS can do this... The coor file
is only 90 MiB large with a topo file of 231.8 MiB, therefore not huge
files. Of course, I wouldn't mind doing it with r.area, but my thread there
has also died off... People, I'm sorry if I'm asking stupid questions but at
least I'm trying!
I’m new to GRASS, but not GIS. I am trying to clarify several uses of bash scripting in GRASS.
I have GRASS installed at C:\Program Files\GRASS-64
Q1) In my first test script I ran, I noticed that I could run test.sh with “sh test.sh”
but this script ran when I put it in C:\Program Files\GRASS-64
and also ran if I instead put it in C:\Program Files\GRASS-64\bin
I’m wondering what is best practice of where to put your bash scripts and how to organize them?
Q2) I’m going to be looking into running bash scripts that loop the same operation on many different files. I am wondering to start experimenting with this, do I first need to import all the files I want to work with into a particular GRASS database? or can GRASS do this kind of operation regardless of what database it is running? I guess I can reword this question as what would be the best practice to bash scripting a loop that iterates through many files.
Q3) I’m also just learning bash scripting (for example I’m not yet sure how to run a .sh if it is in some other directory in bin without writing out the full path). On this note, I am wondering if there is a windows program that I can install where I can practice bash in the windows environment - without specifically running GRASS?
Thanks for the help. Also a good tip - for the record, the problem occured
consistently with GRASS 6.4, always in Linux systems (Ubuntu 10.4 64-bit and
OpenSUSE 11.3 32-bit). The vector map wasn't imported, but converted from a
raster map, also created with GRASS.
I think that using databases is generally a better idea. At the moment we're
in the process in my company of moving everything to databases anyway, so as
soon as a similar problem comes up again I'll try that. In the meantime I've
found a more elegant solution - using r.clump and porting the results on the
map with r.report to python, using that to make a reclass table, and
reclassifying the remaining raster cells according to the criteria I need.
It's basically a workaround because I never was able to get r.area running,
despite the fact that many list members offered great tips.
A couple of years ago I bough a used copy of "Learning the bash Shell"
(O'Reilly) [1]. It's a great book and can help you a lot with simple
and complex bash scripts.
As for automating grass operations, it depends on what sort of
processing you are doing. For instance, I do a lot of bash scripts to
import and process several maps in one pass. Something like this:
<pseudo-code here>
for map in map_list; do
r.in.gdal input=$map output=$map.imported
r.blablabla - process maps anyway you want
done
On Sat, Aug 21, 2010 at 3:45 PM, a. o. <ytrapaet@hotmail.com> wrote:
I'm new to GRASS, but not GIS. I am trying to clarify several uses of bash
scripting in GRASS.
I have GRASS installed at C:\Program Files\GRASS-64
Q1) In my first test script I ran, I noticed that I could run test.sh with
"sh test.sh"
but this script ran when I put it in C:\Program Files\GRASS-64
and also ran if I instead put it in C:\Program Files\GRASS-64\bin
I'm wondering what is best practice of where to put your bash scripts and
how to organize them?
Q2) I'm going to be looking into running bash scripts that loop the same
operation on many different files. I am wondering to start experimenting
with this, do I first need to import all the files I want to work with into
a particular GRASS database? or can GRASS do this kind of operation
regardless of what database it is running? I guess I can reword this
question as what would be the best practice to bash scripting a loop that
iterates through many files.
Q3) I'm also just learning bash scripting (for example I'm not yet sure how
to run a .sh if it is in some other directory in bin without writing out the
full path). On this note, I am wondering if there is a windows program that
I can install where I can practice bash in the windows environment - without
specifically running GRASS?
Thanks for you help!
ao
