[GRASS-dev] Re: About the vector changes

Markus Neteler neteler at osgeo.org
Sat Aug 8 14:34:43 EDT 2009


On Sat, Aug 8, 2009 at 7:03 PM, Glynn Clements<glynn at gclements.plus.com> wrote:
>
> 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.

Patch attached.

Note that it now fails to compile here:

make[1]: Entering directory `/home/neteler/grass70/lib/rst/interp_float'
gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include  -g
-Wall -Werror-implicit-function-declaration -fno-common -mtune=nocona
-m64 -minline-all-stringops   -fPIC  -I/usr/local/include
-D_FILE_OFFSET_BITS=64 -DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/output2d.o -c output2d.c
output2d.c: In function ‘IL_output_2d’:
output2d.c:153: error: void value not ignored as it ought to be
output2d.c:174: error: void value not ignored as it ought to be
output2d.c:190: error: void value not ignored as it ought to be
output2d.c:206: error: void value not ignored as it ought to be
output2d.c:222: error: void value not ignored as it ought to be
output2d.c:238: error: void value not ignored as it ought to be
make[1]: *** [OBJ.x86_64-unknown-linux-gnu/output2d.o] Error 1

No clue how what could be wrong in the patch. Same problem in
raster/r.in.xyz

Feel free to recycle the patch.

Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: G_fseek_ftell.diff.gz
Type: application/x-gzip
Size: 6248 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20090808/8ede0ca0/G_fseek_ftell.diff.gz


More information about the grass-dev mailing list