[GRASS-dev] Re: About the vector changes

Glynn Clements glynn at gclements.plus.com
Sat Aug 8 13:03:14 EDT 2009


Markus Metz wrote:

> >> Yes, if you want to work with vectors not in the current mapset using 
> >> grass7, you have to rebuild topology for all vectors in the 
> >> corresponding mapset first.
> >>     
> >
> > So it's intentional that GRASS7 is no longer compatible with previous
> > vector maps?
> 
> Yes, for two reasons. GRASS7 expects now a sidx file while GRASS6 
> doesn't, and the last GRASS version writing a sidx file (I think 
> GRASS57) wrote it differently to the new format. I have now changed the 
> format numbers and set forward/backward compatibility info. GRASS6 can 
> open GRASS7 vectors, but GRASS7 can't open GRASS6 or GRASS5 vectors, 
> rebuilding topology is required. IOW, I broke backwards compatibility 
> which is against GRASS development policy I guess.

Breaking backwards compatibility is allowed in 7.0. We'll probably be
breaking raster compatibility at some point (but in a far more
fundamental way; old rasters won't be recognised at all).

Something this fundamental should have been announced (maybe it was
and I missed it). Also, the error message is misleading.

> My argument is that 
> enabling backwards compatibility would be about the same effort like 
> rebuilding topology. I could write a module that converts any existing 
> sidx file to the new format or builds the spatial index from topo if no 
> sidx file is found, then writes a new sidx file in the new format. That 
> would avoid rebuilding the core topology and category index.

Maybe the sidx file should have been renamed?

> > That isn't necessarily a problem, but I must have missed the
> > announcement. 
> Was hidden here:
> http://lists.osgeo.org/pipermail/grass-dev/2009-July/045098.html

Right; I didn't get the significance of that at the time.

> > PERMANENT/vector/fields contains:
> >
> > 	-rw-r--r-- 1 root root  4117 May 25  2004 cidx
> > 	-rw-r--r-- 1 root root 27905 May 25  2004 coor
> > 	-rw-r--r-- 1 root root    55 May 25  2004 dbln
> > 	-rw-r--r-- 1 root root   278 May 25  2004 head
> > 	-rw-r--r-- 1 root root   186 May 25  2004 hist
> > 	-rw-r--r-- 1 root root 24538 May 25  2004 sidx
> 
> There is no sidx file for vectors in
> http://grass.osgeo.org/sampledata/spearfish_grass60data-0.3.tar.gz

IOW: sidx was removed in 6.0 (existing sidx files were silently
ignored), then an entirely different sidx file was added recently, and
the code is confused by the existence of a 5.7 sidx file, right?

A different name might have been a better choice. Although the 5.7
datasets are old, they worked until a couple of weeks ago, so people
may still be using them.

Error messages about LFS could cause people to waste effort rebuilding
GRASS to no effect (we've seen something similar with people being
misdirected by the "helpful" information added to the "incompatible
library version" errors).

> Ah, ok, you use the grass57 dataset. I have now changed the version 
> number and compatibility info, you should now get reasonable 
> warnings/errors with the spearfish57 dataset.

Okay, I'll check it.

> > Also, this needs to be checked for anything which uses VECT_CFLAGS,
> > which isn't limited to v.* modules (a few g.* and r.* modules use
> > vector functions).
> 
> I fixed r.drain, v.in.dxf, v.vol.rst. AFAICT all other g.*, r.* and v.* 
> modules are ok. Please let me know if I missed something.

I don't know which modules need fixing and which don't. I was just
pointing out that e.g. g.{copy,remove,rename,list} use the vector
libraries (but don't use VECT_CFLAGS; is that a bug?), r.to.vect,
d.vect, etc use the libraries and VECT_CFLAGS, so it isn't just v.*
modules which need to be checked. It might just be v.* modules which
need to be fixed; I don't know.

> I got carried away (replacing all fseek/ftell occurrences I could find 
> with G_fseek/G_ftell, adjusting off_t as you showed above) and also made 
> r3.in|out.v5d LFS-safe, but did not submit. Should I?

Yes; ideally, we should use G_{fseek,ftell} everywhere. Ultimately, it
would be better to enable -D_FILE_OFFSET_BITS=64 globally (to ensure
that there aren't any cases where a FILE* is obtained via fopen64()
then passed to code which can't handle it), which means making
everything LFS-aware.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list