[GRASSLIST:412] GRASS and CORBA

Greetings,

I'm not sure if this is the right place to ask such a question.
If it disturbs you, please forgive me.

I am trying to develop an application using Grass libraries
under CORBA standard. I got the following error when I compiled
my programs:

MapObject_i.o(.text+0x2d): In function
`MapObject_i::getOverLayers(InformationLayer::BaseMap const&)':
/home/xwu/arch_dev/information_layer/MapServer/MapObject_i.cc:25:
undefined reference to `G_gisinit(char*)'
collect2: ld returned 1 exit status
gmake: *** [MapServer] Error 1

I have added the path to libgis.a and gis.h into my Makefile.
I also tried to use gmake5. But gmake5 doesn't recognize
those classes used in the programs. And I copy a lot of
variables from make.rules generated by gmake5 to my Makefile.
But the error is still there. I have no idea how to fix
such a bug.

Any suggestion or comment? Thanks a lot.

Best wishes.

Xueming

Xueming Wu wrote:

I'm not sure if this is the right place to ask such a question.
If it disturbs you, please forgive me.

I am trying to develop an application using Grass libraries
under CORBA standard. I got the following error when I compiled
my programs:

MapObject_i.o(.text+0x2d): In function
`MapObject_i::getOverLayers(InformationLayer::BaseMap const&)':
/home/xwu/arch_dev/information_layer/MapServer/MapObject_i.cc:25:
undefined reference to `G_gisinit(char*)'
collect2: ld returned 1 exit status
gmake: *** [MapServer] Error 1

The GRASS header files aren't designed for use with C++, so you have
to use e.g.

  extern "C" {
  #include "gis.h"
  }

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

FLAG: Set the following flag?
    Link attributes by coverage-ID not by coverage-#?

Question: What exactly does this option mean?

Thanks,
Keith

Keith J. Forbes wrote:

FLAG: Set the following flag?
    Link attributes by coverage-ID not by coverage-#?

Question: What exactly does this option mean?

Each feature in e00 file (and in Arc/Info) have an internal
identifier (name_of_layer-#) to link attributes and geometry.
It is however a bad practice to use this number as an external
link because the internal numbering may change if you do
some operation (cleaning after erasing some objects, etc.).
# is computed automaticaly and you cannot modify it.
There is another identifier (name_of-layer-ID) that is
entirely controled by the user, and can therefore be used
to link your coverage to an external database, etc...

In practice for m.in.e00 :
- the is one attribute entry per graphic object (line, area, point)
so you should use the normal behaviour of the program.
- in some case, you want to consider all objects having the
same ID as one object in Grass, or the # links are broken
(yes, sometimes you can get really bad datasets !), so you
may want to try the ID number.

Honestly, its also an historical feature : the first release
used (incorrectly) ID for the link...

--
Michel Wurtz - Auzeville-Tolosane

Could I ask for a bit more clarification on this matter? I
have had some difficulty with .e00 files and the associated
dig_cats/ files that are created.

When I have chosen the "-i" option of m.in.e00 and then
copied the resulting dig/, dig_att/, and dig_plus/ files to
correspond to the various dig_cats/ files, I have mismatches
between areas on the map and the associated dig_cats labels.
The problem does not occur when I omit the "-i" option of
m.in.e00. So my conclusion had been to omit the "-i"
option.

However, Michel's post suggests that "-i" is the appropriate
option because coverage-# can be shuffled by subsequent
processing while coverage-ID is fixed. I would be grateful
for clarification.

Best regards,

Michael

Keith J. Forbes wrote:
> FLAG: Set the following flag?
> Link attributes by coverage-ID not by coverage-#?
> Question: What exactly does this option mean?

Each feature in e00 file (and in Arc/Info) have an internal
identifier (name_of_layer-#) to link attributes and geometry.
It is however a bad practice to use this number as an external
link because the internal numbering may change if you do
some operation (cleaning after erasing some objects, etc.).
# is computed automaticaly and you cannot modify it.
There is another identifier (name_of-layer-ID) that is
entirely controled by the user, and can therefore be used
to link your coverage to an external database, etc...

In practice for m.in.e00 :
- the is one attribute entry per graphic object (line, area, point)
so you should use the normal behaviour of the program.
- in some case, you want to consider all objects having the
same ID as one object in Grass, or the # links are broken
(yes, sometimes you can get really bad datasets !), so you
may want to try the ID number.

Honestly, its also an historical feature : the first release
used (incorrectly) ID for the link...

I don't agree that the user-assigned coverage ID provides a better link than
the internal coverage number.

I've done some work with m.in.e00, both using it and coding for it. I recall
that when I imported a point coverage I had to use the -i option, but when I
imported a line coverage the -i option did not work correctly. My
recollection could be faulty.

More recently I modified m.in.e00 to correctly read polygon coverages (that
modification has not yet been merged back to CVS) and found that the e00
format does not use the coverage-ID in the polygon topology (PAL) table. I
couldn't find a way to use the coverage-ID to link the data; it appeared
necessary to use the coverage-#.

I thought that it might be best to remove the -i option entirely.

I can think of only one problem that might come up when indexing with
coverages numbers. You cannot import data from two different e00 files and
use the category numbers to compare objects between the two imported data
sets. There is no way to guarantee that the category number for an object
from one file will be the same category number for the same object from a
different file.

Roger Miller

On Thu, 19 Jun 2003 16:34:35 -0400 (EDT), Michael Ash wrote

Could I ask for a bit more clarification on this matter? I
have had some difficulty with .e00 files and the associated
dig_cats/ files that are created.

When I have chosen the "-i" option of m.in.e00 and then
copied the resulting dig/, dig_att/, and dig_plus/ files to
correspond to the various dig_cats/ files, I have mismatches
between areas on the map and the associated dig_cats labels.
The problem does not occur when I omit the "-i" option of
m.in.e00. So my conclusion had been to omit the "-i"
option.

However, Michel's post suggests that "-i" is the appropriate
option because coverage-# can be shuffled by subsequent
processing while coverage-ID is fixed. I would be grateful
for clarification.

Best regards,

Michael

> Keith J. Forbes wrote:
> > FLAG: Set the following flag?
> > Link attributes by coverage-ID not by coverage-#?
> > Question: What exactly does this option mean?
>
> Each feature in e00 file (and in Arc/Info) have an internal
> identifier (name_of_layer-#) to link attributes and geometry.
> It is however a bad practice to use this number as an external
> link because the internal numbering may change if you do
> some operation (cleaning after erasing some objects, etc.).
> # is computed automaticaly and you cannot modify it.
> There is another identifier (name_of-layer-ID) that is
> entirely controled by the user, and can therefore be used
> to link your coverage to an external database, etc...
>
> In practice for m.in.e00 :
> - the is one attribute entry per graphic object (line, area, point)
> so you should use the normal behaviour of the program.
> - in some case, you want to consider all objects having the
> same ID as one object in Grass, or the # links are broken
> (yes, sometimes you can get really bad datasets !), so you
> may want to try the ID number.
>
> Honestly, its also an historical feature : the first release
> used (incorrectly) ID for the link...

Michael Ash wrote:

However, Michel's post suggests that "-i" is the appropriate
option because coverage-# can be shuffled by subsequent
processing while coverage-ID is fixed. I would be grateful
for clarification.

I just wanted to say that if you have attributes in an *external*
database linked to the Arc/info Coverage, it probably uses the
coverage-ID as the link field, so it may be interesting to take
it for the aat number...

If you have only an e00 file, coverage-# is the choice.

--
Michel Wurtz - Auzeville-Tolosane

Roger Miller wrote:

More recently I modified m.in.e00 to correctly read polygon coverages (that
modification has not yet been merged back to CVS) and found that the e00
format does not use the coverage-ID in the polygon topology (PAL) table. I
couldn't find a way to use the coverage-ID to link the data; it appeared
necessary to use the coverage-#.

Yes, when a line has the same polygon on his left and right side, it must be
imported as a "line" in grass. If you don't do that, v.support is confused.
I have not finished that, but if you have it ready, merge it !

--
Michel Wurtz - Auzeville-Tolosane