I'm using grass-6.0.0 to create a vector version of some scanned
out-of-copyright maps. At one point, v.digit froze and after a while I
had to kill the process. Upon restarting, I can display my vector map
using d.vect but I get a warning "coor files of vector 'foo@PERMANENT'
is larger than it should be'. From reading around, this is to be
expected since v.digit writes out the length data on exit. The
recommend fix is to rerun v.digit to rewrite the file.
However, if I try to run v.digit I get the following error;
"ERROR: Cannot open old vector foo@PERMANENT on level 2"
I get the same error if I try to export the dataset using v.out.ogr.
Now, my vector dataset was created today in grass 6.0 so I don't imagine
it uses the old vector format. Certainly, "g.list type=vect" shows my
map and "g.list type=oldvect" doesn't.
Any idea how I can recover my data? I was only doing a small amount of
work today to test-drive grass6, but since v.digit crashed once it's
reasonable to assume I'll encounter this again when I do the map for
real.
Secondly does grass6 allow you to store the geometry of a vector map in
a postgis table? (I've been storing attributes on a pg table). I'd
feel a bit happier if my data was being updated with transactions to
avoid crash-lossage like this.
Thanks in advance for any help. Today is the first day I feel that I've
got into the "grass way" of thinking about things.
I'm using grass-6.0.0 to create a vector version of some scanned
out-of-copyright maps. At one point, v.digit froze and after a while I
had to kill the process. Upon restarting, I can display my vector map
using d.vect but I get a warning "coor files of vector 'foo@PERMANENT'
is larger than it should be'. From reading around, this is to be
expected since v.digit writes out the length data on exit.
It would be possible but probably too slow (I think) to rewrite the size always when a new line is written (hard disk head jumps?).
If anybody is interested, it is possible to try to add
The recommend fix is to rerun v.digit to rewrite the file.
However, if I try to run v.digit I get the following error;
"ERROR: Cannot open old vector foo@PERMANENT on level 2"
I get the same error if I try to export the dataset using v.out.ogr.
You have to run v.build, it is always necessay after crash.
Now, my vector dataset was created today in grass 6.0 so I don't imagine
it uses the old vector format. Certainly, "g.list type=vect" shows my
map and "g.list type=oldvect" doesn't.
Any idea how I can recover my data? I was only doing a small amount of
work today to test-drive grass6, but since v.digit crashed once it's
reasonable to assume I'll encounter this again when I do the map for
real.
Secondly does grass6 allow you to store the geometry of a vector map in
a postgis table? (I've been storing attributes on a pg table). I'd
feel a bit happier if my data was being updated with transactions to
avoid crash-lossage like this.
No.
Radim
Thanks in advance for any help. Today is the first day I feel that I've
got into the "grass way" of thinking about things.
> I'm using grass-6.0.0 to create a vector version of some scanned
> out-of-copyright maps. At one point, v.digit froze and after a
> while I had to kill the process. Upon restarting, I can display my
> vector map using d.vect but I get a warning "coor files of vector
> 'foo@PERMANENT' is larger than it should be'. From reading around,
> this is to be expected since v.digit writes out the length data on
> exit.
It would be possible but probably too slow (I think) to rewrite the
size always when a new line is written (hard disk head jumps?).
If anybody is interested, it is possible to try to add
> The recommend fix is to rerun v.digit to rewrite the file.
> However, if I try to run v.digit I get the following error;
> "ERROR: Cannot open old vector foo@PERMANENT on level 2"
> I get the same error if I try to export the dataset using v.out.ogr.
You have to run v.build, it is always necessay after crash.
I've noticed when you are digitizing with a background draw command
including the vector map you are digitizing[*], the terminal window
displays errors on redraw about the size being wrong by about 9(?) bytes
for every point digitized (to be expected I guess). After 600 or so
points & the error growing to ~ 5000 bytes, d.vect crashes. v.build &
restarting always fixed it, less the last DB entry added. This is
unadvised usage but it's always good to make things more robust.
* I was using 'd.vect display=attr' to double check point values.
I cant understand whats the meaning for the ellipsoid into the brackets. Like (international ellipsoid) near to rome40 Monte_Mario. I know that the rome40 ellipsoid is based on the international one, but i cant understand why have I to specify at this point that im going to use the rome40 ellipsoid, when after i'll have to specify the towgs84 parameter. why grass need this two different definitions? and... how grass built the rome40 ellipsoid from the international one?
That list is what you get when you list datums. rome40 is the datum and international is the ellipsoid. I don't understand datums enough to be able to explain it better than that. The information about the ellipsoid used for that datum is just printed there to make it easier for you to make a decision about which datum to use.
I cant understand whats the meaning for the ellipsoid into the brackets. Like (international ellipsoid) near to rome40 Monte_Mario. I know that the rome40 ellipsoid is based on the international one, but i cant understand why have I to specify at this point that im going to use the rome40 ellipsoid, when after i'll have to specify the towgs84 parameter. why grass need this two different definitions?
Datum transformation parameters (like towgs84) are specfic to a localised area and there is no one correct set for each datum. The way GRASS prompts you for datum and transformation parameters etc. is designed, hopefully, to force you to think about what you are doing and not just blindly accept the defaults!