[GRASS5] Re: v.out.e00

GRASS GIS GRASS GIS developer
1

Hi Gordon,

(I cc this to "grass5" to get the other informed)

On Fri, Dec 14, 2001 at 12:14:30PM -0700, gordon.haverland@gov.ab.ca wrote:

Hello Markus,
  Well, I've been working on v.out.e00 for about a week now, and I think I
need a day or so to think about things.

  Yes, there are some bugs in the existing code. In fact, I am pretty
sure that the code submitted never ran on any architecture (let alone this
Intel Linux machine). However, there is something else going on with the
code that I am having problems tracking down.

  In the code before the "calculation" of the Universe polygon, is a
branch of code which builds the doubly linked list which is searched to
build the polygon and also has: if( map.Link[i].left < 0 ) {
  map.Link[i].left = 1;
} else {
  map.Link[i].left += 1;
}
and similar for right. I've tried 4 or 5 variations on writing that chunk
of code dealing with the renumbering of map.Link[i].(right|left) now. If
I put fprintf(stderr,"...") statements before and after that code, I get
the similar result as if I have no fprintf()s there. That is, the if left
is less than 0, that left is multiplied by -1. Sometimes right gets set to
1 and sometimes it is left alone. However, if I put fprintf()s between
the right and left chunks of code, now it renumbers left and right
correctly. Which seems to me to be a compiler bug. However, it may be a
problem with the vector library, because almost every line read from a
grass vector file comes out with lines which consist of a single node
pointing to itself (N1 almost always equals N2).

It would be a LOT easier to follow what is going on, if I could do this
debugging inside emacs with gdb, instead of using a zillion fprintf
statements. Do you know how I can arrange to run GRASS binaries inside
GDB? Do I have to compile all of grass with
-ggdb?

Have a great weekend!
Gordon Haverland

Please have a look at
documents/debugging.txt
in the source code. It tells you how to debug with GDB. I assume that
you have been trying to debug
$GISBASE/bin/module
which is only a hard-link to front-end. The real binary which is
happily accepted by a debugger lives in
$GISBASE/etc/bin/cmd/module

Of course "-g" is required (and no "-s").

Hope this helps,
you fixes will be appreciated!

Markus

PS: Please be sure to work on the latest code in CVS (release branch).
It is also included in the CVS snapshot.

2

On Mon, 17 Dec 2001 10:29:00 +0100, Markus Neteler <neteler@itc.it> wrote:

Hi Gordon,

(I cc this to "grass5" to get the other informed)

On Fri, Dec 14, 2001 at 12:14:30PM -0700, gordon.haverland@gov.ab.ca wrote:
>
> Hello Markus,
> Well, I've been working on v.out.e00 for about a week now, and I think I
> need a day or so to think about things.
>
> Yes, there are some bugs in the existing code. In fact, I am pretty
> sure that the code submitted never ran on any architecture (let alone this
> Intel Linux machine). However, there is something else going on with the
> code that I am having problems tracking down.
>
> In the code before the "calculation" of the Universe polygon, is a
> branch of code which builds the doubly linked list which is searched to
> build the polygon and also has: if( map.Link[i].left < 0 ) {
> map.Link[i].left = 1;
> } else {
> map.Link[i].left += 1;
> }
> and similar for right. I've tried 4 or 5 variations on writing that chunk
> of code dealing with the renumbering of map.Link[i].(right|left) now. If
> I put fprintf(stderr,"...") statements before and after that code, I get
> the similar result as if I have no fprintf()s there. That is, the if left
> is less than 0, that left is multiplied by -1. Sometimes right gets set to
> 1 and sometimes it is left alone. However, if I put fprintf()s between
> the right and left chunks of code, now it renumbers left and right
> correctly. Which seems to me to be a compiler bug. However, it may be a
> problem with the vector library, because almost every line read from a
> grass vector file comes out with lines which consist of a single node
> pointing to itself (N1 almost always equals N2).

  I'm not sure how v.out.e00 is written, but if you're talking about negative
numbers for area edge lines, then it means the line should be traversed in
reverse order. I'm not sure what you mean about each line having a single
node. That might be the case if your reading areas via Vect_get_area_points(),
but that is probably not the correct way to construct an E00 file, since
edges will get duplicated.

> It would be a LOT easier to follow what is going on, if I could do this
> debugging inside emacs with gdb, instead of using a zillion fprintf
> statements. Do you know how I can arrange to run GRASS binaries inside
> GDB? Do I have to compile all of grass with
> -ggdb?
>
> Have a great weekend!
> Gordon Haverland

Please have a look at
documents/debugging.txt
in the source code. It tells you how to debug with GDB. I assume that
you have been trying to debug
$GISBASE/bin/module
which is only a hard-link to front-end. The real binary which is
happily accepted by a debugger lives in
$GISBASE/etc/bin/cmd/module

Of course "-g" is required (and no "-s").

If documents/debugging.txt doesn't help, let me know... The trick is to
compile the module without the "-s" flag and probably without any
optimizations as well. Then run the debugger from a terminal where a
GRASS session is running (to get the environment). Works fine...

--
Eric G. Miller <egm2@jps.net>

3

"Eric G. Miller" wrote:

On Mon, 17 Dec 2001 10:29:00 +0100, Markus Neteler <neteler@itc.it> wrote:

> Hi Gordon,
>
> (I cc this to "grass5" to get the other informed)
>
> On Fri, Dec 14, 2001 at 12:14:30PM -0700, gordon.haverland@gov.ab.ca wrote:
> >
> > Hello Markus,
> > Well, I've been working on v.out.e00 for about a week now, and I think I
> > need a day or so to think about things.
> >
> > Yes, there are some bugs in the existing code. In fact, I am pretty
> > sure that the code submitted never ran on any architecture (let alone this
> > Intel Linux machine). However, there is something else going on with the
> > code that I am having problems tracking down.
> >
> > In the code before the "calculation" of the Universe polygon, is a
> > branch of code which builds the doubly linked list which is searched to
> > build the polygon and also has: if( map.Link[i].left < 0 ) {
> > map.Link[i].left = 1;
> > } else {
> > map.Link[i].left += 1;
> > }
> > and similar for right. I've tried 4 or 5 variations on writing that chunk
> > of code dealing with the renumbering of map.Link[i].(right|left) now. If
> > I put fprintf(stderr,"...") statements before and after that code, I get
> > the similar result as if I have no fprintf()s there. That is, the if left
> > is less than 0, that left is multiplied by -1. Sometimes right gets set to
> > 1 and sometimes it is left alone. However, if I put fprintf()s between
> > the right and left chunks of code, now it renumbers left and right

Hmm... I looked (after a long time) at my code again, and found at last
one bug : this part of the code is only valid for an AREA line type.
So I just corrected v.out.e00.c in the CVS. One should also eliminate
lines of type DOT. It is not done in this quick development.

Arc/Info and Grass topology concepts are very close, but the implementations
are different. The "Universe" polygon is typical to Arc/info and has allways
(AFAIK) 1 for Ident. So I choose to add one to each area ident, thus leaving
free the first slot. The "outside" is numbered 0 in Arc/Info and has a
negative value in Grass.

> > correctly. Which seems to me to be a compiler bug. However, it may be a
> > problem with the vector library, because almost every line read from a
> > grass vector file comes out with lines which consist of a single node
> > pointing to itself (N1 almost always equals N2).

  I'm not sure how v.out.e00 is written, but if you're talking about negative
numbers for area edge lines, then it means the line should be traversed in
reverse order. I'm not sure what you mean about each line having a single
node. That might be the case if your reading areas via Vect_get_area_points(),
but that is probably not the correct way to construct an E00 file, since
edges will get duplicated.

Yes, polygon edge lines are traversed clockwise : the interior is on the
right, so any hole must be traversed counterclockwise. the edge number is
negative when you have to traverse the line in reverse order.

You have also to keep all nodes for building the E00 file, and have some
points inside each polygon for the attribute table.

Hope this will help you to undersand the code. My personnal feeling is that
reading an e00 file is probably easier than reading Shapefile or MIF/MID
files (no need to rebuild topology), but writing an e00 file is harder than
writing Shapefile or MIF/MID files because you have to build the Arc/Info
view of topology, instead of simply drawing closed polygons.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

4

Eric G. Miller wrote:

> Please have a look at
> documents/debugging.txt
> in the source code. It tells you how to debug with GDB. I assume that
> you have been trying to debug
> $GISBASE/bin/module
> which is only a hard-link to front-end. The real binary which is
> happily accepted by a debugger lives in
> $GISBASE/etc/bin/cmd/module
>
> Of course "-g" is required (and no "-s").

If documents/debugging.txt doesn't help, let me know... The trick is to
compile the module without the "-s" flag and probably without any
optimizations as well. Then run the debugger from a terminal where a
GRASS session is running (to get the environment). Works fine...

The "-s" switch should no longer be added to LDFLAGS automatically.
Anyone preparing binary distributions should probably run "strip" on
the resulting executables, or use "LDFLAGS=-s ./configure ...".

The "-g" switch will be added to COMPILE_FLAGS automatically if the
compiler is known to support it, unless CFLAGS was pre-defined by the
user.

Also, "-O2" will be added automatically for GCC, unless CFLAGS was
pre-defined by the user. This is undesirable for debugging, so I'd
recommend using "CFLAGS=-g ./configure ...".

--
Glynn Clements <glynn.clements@virgin.net>