[GRASS5] FIX: gdal/v.in.dgn support with grass 5.0.2

GRASS GRASS developer
,
1

[I have set some Bcc since the message might be of some interest to both
users, developers and packagers. Hope I don't make a mistake!]

Hello,

First sorry if the solution has already been given.

I wanted, in order to be more convincing about the adoption of GRASS, to
compile in the support for dgn (we use Microstation here).

This is the 5.0.2 release of GRASS. I have retrieved the 1.1.9 version of
gdal and I work on a FreeBSD 4.5 system, with user ports upgraded merely
to the 5.1 branch and adapted if necessary by hand.

Since the integration of the dgn library in gdal, the API has changed
and several things need to be adjusted for the module v.in.dgn (for
instance, DGNOpen now takes 2 arguments).

First, one need to use `--with-gdal=<PATH_TO_gdal-config>' as an
argument to `configure' and have gdal 1.1.9 compiled on the system with
the ogr support. If the `ogr' support has been compiled in, then the
DGN* functions are included in the gdal library. One doesn't need
something else. To verify the version of gdal (if installed):

gdal-config --version

To verify the presence of the DGN* functions one can use `nm' but a test
should be inserted in the configure script (I'm not an autoconf user, so
the patches are not given).

One problem with `gdal' is that the dgn* headers are not installed. I
have so added the relevant headers directly in v.in.dgn subdirectory,
but the "right" solution should be the installation of these by gdal.

The attached patches (named after the FreeBSD ports convention) are
sufficient to have v.in.dgn compiled successfully (it is not compiled by
default, you need to compile it with gmake5 and launch gmakelink5
afterwards ---BTW, how could one have it compiled by default if gdal
support is selected at configure time?).

Just a note : since `gdal-config --libs' mixes LDFLAGS (-L) and library
argument (-l), a dependency against GDAL_LIBS was puzzling gmake.

Thanks for the great work!
--
Thierry Laronde <tlaronde@polynum.org>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/

(attachments)

patch-src::src::mapdev::v.in.dgn::main.c (729 Bytes)
patch-src::src::mapdev::v.in.dgn::dgnlibp.h (5.76 KB)
patch-src::src::mapdev::v.in.dgn::dgnlib.h (27.5 KB)
patch-src::src::mapdev::v.in.dgn::cpl_conv.h (7.37 KB)
patch-src::src::mapdev::v.in.dgn::Gmakefile (635 Bytes)

2

Hello

On Sun, 20 Jul 2003, Thierry Laronde wrote:

...

Since the integration of the dgn library in gdal, the API has changed
and several things need to be adjusted for the module v.in.dgn (for
instance, DGNOpen now takes 2 arguments).

It looks like this is already fixed in the CVS v.in.dgn.

...

To verify the presence of the DGN* functions one can use `nm' but a test
should be inserted in the configure script (I'm not an autoconf user, so
the patches are not given).

I think if OGR support is in GDAL then it will be there. The GRASS 5.1 (to
be 5.7.x) configure script checks for `gdal-config --ogr-enabled`. Something
similar could be added to the 5.3.x configure and then the v.in.dgn module
compiled optionally.

One problem with `gdal' is that the dgn* headers are not installed. I
have so added the relevant headers directly in v.in.dgn subdirectory,
but the "right" solution should be the installation of these by gdal.

I think that is the main problem. Everything else seems fairly simple to
tidy up. It looks like you need to have a full GDAL source installation if
you want to compile this, or maybe the headers for the DGN functions could
be included in the installed GDAL headers instead of GDAL installing even
more header files. A temporary solution would be to include copies of the
dgnlib.h and dgnlibp.h with GRASS, depending on what other developers
think.

The Gmakefile should probably have a reference to $(GDAL_CFLAGS) in the
EXTRA_CFLAGS. Then cpl_conv.h wouldn't need to be copied over as that *is*
installed with GDAL.

...

afterwards ---BTW, how could one have it compiled by default if gdal
support is selected at configure time?).

You would use the src/CMD/lists/optional / optional.in and the
LOC_OPTIONAL macro in the configure.in file I suppose. Probably r.in.gdal
should eventually be done like this as well.

Just a note : since `gdal-config --libs' mixes LDFLAGS (-L) and library
argument (-l), a dependency against GDAL_LIBS was puzzling gmake.

The CVS version of the Gmakefile and main.c seem to be different from the
ones your patches are against so it doesn't make sense to comment on the
other things.

Paul Kelly

3

Hello,

Quoting Paul Kelly <paul-grass@stjohnspoint.co.uk>:

> Since the integration of the dgn library in gdal, the API has changed
> and several things need to be adjusted for the module v.in.dgn (for
> instance, DGNOpen now takes 2 arguments).

It looks like this is already fixed in the CVS v.in.dgn.

OK.

> One problem with `gdal' is that the dgn* headers are not installed. I
> have so added the relevant headers directly in v.in.dgn subdirectory,
> but the "right" solution should be the installation of these by gdal.

I think that is the main problem. Everything else seems fairly simple
to
tidy up. It looks like you need to have a full GDAL source installation
if
you want to compile this, or maybe the headers for the DGN functions
could
be included in the installed GDAL headers instead of GDAL installing
even
more header files. A temporary solution would be to include copies of
the
dgnlib.h and dgnlibp.h with GRASS, depending on what other developers
think.

The Gmakefile should probably have a reference to $(GDAL_CFLAGS) in the
EXTRA_CFLAGS. Then cpl_conv.h wouldn't need to be copied over as that
*is*
installed with GDAL.

I agree, the main problem is that, at least, we must verify that the library
we are just about to link against matches the API use by the code, i.e. that
the prototypes are correct but this can only be achieved if this the gdal
package which installs the headers needed (it should be so since gdal installs
also statically linked library which are typically used when compiling...).

...
> afterwards ---BTW, how could one have it compiled by default if gdal
> support is selected at configure time?).

You would use the src/CMD/lists/optional / optional.in and the
LOC_OPTIONAL macro in the configure.in file I suppose. Probably
r.in.gdal
should eventually be done like this as well.

Thanks for the tip!

Cheers,

4

On Mon, 21 Jul 2003 tlaronde@polynum.org wrote:

Hello,

Quoting Paul Kelly <paul-grass@stjohnspoint.co.uk>:

...

> > One problem with `gdal' is that the dgn* headers are not installed. I
> > have so added the relevant headers directly in v.in.dgn subdirectory,
> > but the "right" solution should be the installation of these by gdal.
>
> I think that is the main problem. Everything else seems fairly simple
> to
> tidy up. It looks like you need to have a full GDAL source installation
> if
> you want to compile this, or maybe the headers for the DGN functions
> could
> be included in the installed GDAL headers instead of GDAL installing
> even
> more header files. A temporary solution would be to include copies of
> the
> dgnlib.h and dgnlibp.h with GRASS, depending on what other developers
> think.
>

...

I agree, the main problem is that, at least, we must verify that the library
we are just about to link against matches the API use by the code, i.e. that
the prototypes are correct but this can only be achieved if this the gdal
package which installs the headers needed (it should be so since gdal installs
also statically linked library which are typically used when compiling...).

Well we can only ask the GDAL developers what the situation is or how it's
supposed to be done [message copied to that list]...

5

Paul Kelly wrote:

I agree, the main problem is that, at least, we must verify that the library
we are just about to link against matches the API use by the code, i.e. that
the prototypes are correct but this can only be achieved if this the gdal
package which installs the headers needed (it should be so since gdal installs
also statically linked library which are typically used when compiling...).

Well we can only ask the GDAL developers what the situation is or how it's
supposed to be done [message copied to that list]...

Paul, and others,

It isn't generally my intention that GDAL should by default install the
include files for component libraries like dgnlib when it is being installed.
I feel that as the number of drivers grows this will introduce alot of clutter.
Also, I don't necessarily guarantee that all the sublibrary entry points will
be exposed externally from the main gdal library on platforms like Windows
where this must be explictly done.

I would be willing to add a "devinstall" target in the gdal/ogr/ogrsf_frmts/dgn
directory that installs all the dgnlib specific include files if you wish,
and also make some effort to ensure that the dgnlib API is properly exported
from the GDAL library on windows. However, this would still mean that
users installing dgnlib would need to do an extra step for use by GRASS,
I would imagine this would be frequently forgotten leading to lots of
additional problems. Of course, those preparing distributions could
presumably deal with this.

A similar issue came up a while ago with shapelib, and I somewhat reluctantly
agreed to install the shapelib include files, and ensure that the entry
points are exported from GDAL DLLs. (I think I did anyways) However, I
am not keen on following that example for all sorts of other libraries.

My *suggestion* would be to make v.in.dgn optional, dependent on whether
the appropriate components are installed, and to try to deal with DGN
primariliy via the OGR link in the new GRASS.

Let me know if you want me to add the dgnlib devinstall target in time
for GDAL 1.2.0.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

6

Hello Frank

On Mon, 21 Jul 2003, Frank Warmerdam wrote:

My *suggestion* would be to make v.in.dgn optional, dependent on whether
the appropriate components are installed, and to try to deal with DGN
primariliy via the OGR link in the new GRASS.

Yes you are right; I see now that the most elegant way of accessing the
dgn format is through OGR and that external programs like GRASS should not
bother with the component libraries that are helpers to OGR.
Makes sense to me now, thank you for the insight.

We could just add --with-dgn and --with-dgn-includes as options to the
GRASS configure script then to help the people who want to use this older
module.

Paul

7

Hello,

On Mon, Jul 21, 2003 at 08:49:11PM +0100, Paul Kelly wrote:

Hello Frank

On Mon, 21 Jul 2003, Frank Warmerdam wrote:

> My *suggestion* would be to make v.in.dgn optional, dependent on whether
> the appropriate components are installed, and to try to deal with DGN
> primariliy via the OGR link in the new GRASS.

Yes you are right; I see now that the most elegant way of accessing the
dgn format is through OGR and that external programs like GRASS should not
bother with the component libraries that are helpers to OGR.
Makes sense to me now, thank you for the insight.

We could just add --with-dgn and --with-dgn-includes as options to the
GRASS configure script then to help the people who want to use this older
module.

Well, since what would require that indeed gdal is installed, I think
the solution both of you propose is the correct one : just tell people
that they can use ogr2ogr to transform a dgn file in a format "natively"
supported by GRASS.

BTW, and this is just a question, have GRASS/GDAL developers already
looked at ISO 10303 (i.e. STEP) for a central ASCII format ?

Cheers,
--
Thierry Laronde <tlaronde@polynum.org>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/

8

On Sunday 20 July 2003 01:49 pm, Thierry Laronde wrote:

[I have set some Bcc since the message might be of some interest to both
users, developers and packagers. Hope I don't make a mistake!]

Hello,

First sorry if the solution has already been given.

I wanted, in order to be more convincing about the adoption of GRASS, to
compile in the support for dgn (we use Microstation here).

This is the 5.0.2 release of GRASS. I have retrieved the 1.1.9 version of
gdal and I work on a FreeBSD 4.5 system, with user ports upgraded merely
to the 5.1 branch and adapted if necessary by hand.

Since the integration of the dgn library in gdal, the API has changed
and several things need to be adjusted for the module v.in.dgn (for
instance, DGNOpen now takes 2 arguments).

First, one need to use `--with-gdal=<PATH_TO_gdal-config>' as an
argument to `configure' and have gdal 1.1.9 compiled on the system with
the ogr support. If the `ogr' support has been compiled in, then the
DGN* functions are included in the gdal library. One doesn't need
something else. To verify the version of gdal (if installed):

gdal-config --version

To verify the presence of the DGN* functions one can use `nm' but a test
should be inserted in the configure script (I'm not an autoconf user, so
the patches are not given).

One problem with `gdal' is that the dgn* headers are not installed. I
have so added the relevant headers directly in v.in.dgn subdirectory,
but the "right" solution should be the installation of these by gdal.

The attached patches (named after the FreeBSD ports convention) are
sufficient to have v.in.dgn compiled successfully (it is not compiled by
default, you need to compile it with gmake5 and launch gmakelink5
afterwards ---BTW, how could one have it compiled by default if gdal
support is selected at configure time?).

Just a note : since `gdal-config --libs' mixes LDFLAGS (-L) and library
argument (-l), a dependency against GDAL_LIBS was puzzling gmake.

Thanks for the great work!
--
Thierry Laronde <tlaronde@polynum.org>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/

Hi Thierry.

I saw this on grasslist and have been having problems with r.in.gdal and Frank
W. suggested recompiling with gdal.

I recompiled as follows:

./configure --with-postgres-includes=/usr/local/pgsql/include/
--with-gdal=/usr/local/share/gdal --with-postgres-libs=/usr/local/pgsql/lib

but now think I specified gdal location incorrectly

I have gdal-config in /usr/local/bin/.

should i use

--with-gdal=/usr/local/bin/gdal-config or
--with-gdal=/usr/local/bin

Thanks.

--
k|J|f

9

Hello Keith

On Mon, 8 Sep 2003, Keith J. Forbes wrote:

I recompiled as follows:

./configure --with-postgres-includes=/usr/local/pgsql/include/
--with-gdal=/usr/local/share/gdal --with-postgres-libs=/usr/local/pgsql/lib

but now think I specified gdal location incorrectly

I have gdal-config in /usr/local/bin/.

should i use

--with-gdal=/usr/local/bin/gdal-config or
--with-gdal=/usr/local/bin

It should be the first one. And if /usr/local/bin is in your path you
won't even need that, just '--with-gdal' should suffice. Just now I have
commited to CVS a change to make the './configure --help' output clearer
with regard to the --with-gdal option.

Please let us know how you get on

Paul

10

On Monday 08 September 2003 04:37 pm, Paul Kelly wrote:

Hello Keith

On Mon, 8 Sep 2003, Keith J. Forbes wrote:
> I recompiled as follows:
>
> ./configure --with-postgres-includes=/usr/local/pgsql/include/
> --with-gdal=/usr/local/share/gdal
> --with-postgres-libs=/usr/local/pgsql/lib
>
> but now think I specified gdal location incorrectly
>
> I have gdal-config in /usr/local/bin/.
>
> should i use
>
> --with-gdal=/usr/local/bin/gdal-config or
> --with-gdal=/usr/local/bin

It should be the first one. And if /usr/local/bin is in your path you
won't even need that, just '--with-gdal' should suffice. Just now I have
commited to CVS a change to make the './configure --help' output clearer
with regard to the --with-gdal option.

Please let us know how you get on

Paul

Paul: Thanks for the response. Tried what you suggested
(--with-gdal=/usr/local/bin/gdal-config)

and

--snip
checking if we should build directly against GDAL... yes
no
checking whether to use TIFF... yes

---snip

any idea if it will build directly against GDAL (since it said yes, and then
no???!!!!)

Thanks,
Keith

--
k|J|f

11

On Monday 08 September 2003 04:46 pm, Keith J. Forbes wrote:

On Monday 08 September 2003 04:37 pm, Paul Kelly wrote:
> Hello Keith
>
> On Mon, 8 Sep 2003, Keith J. Forbes wrote:
> > I recompiled as follows:
> >
> > ./configure --with-postgres-includes=/usr/local/pgsql/include/
> > --with-gdal=/usr/local/share/gdal
> > --with-postgres-libs=/usr/local/pgsql/lib
> >
> > but now think I specified gdal location incorrectly
> >
> > I have gdal-config in /usr/local/bin/.
> >
> > should i use
> >
> > --with-gdal=/usr/local/bin/gdal-config or
> > --with-gdal=/usr/local/bin
>
> It should be the first one. And if /usr/local/bin is in your path you
> won't even need that, just '--with-gdal' should suffice. Just now I have
> commited to CVS a change to make the './configure --help' output clearer
> with regard to the --with-gdal option.
>
> Please let us know how you get on
>
> Paul

Paul: Thanks for the response. Tried what you suggested
(--with-gdal=/usr/local/bin/gdal-config)

and

--snip
checking if we should build directly against GDAL... yes
no
checking whether to use TIFF... yes

---snip

any idea if it will build directly against GDAL (since it said yes, and
then no???!!!!)

Thanks,
Keith

Hi again. Did a "make clean" and then tried --with-gdal

and

---snip---

checking if we should build directly against GDAL... yes
checking for gdal-config... /usr/local/bin/gdal-config

---snip---

seems to have worked! Thanks.

--
k|J|f

12

On Mon, 8 Sep 2003, Keith J. Forbes wrote:

Paul: Thanks for the response. Tried what you suggested
(--with-gdal=/usr/local/bin/gdal-config)

and

--snip
checking if we should build directly against GDAL... yes
no
checking whether to use TIFF... yes

---snip

any idea if it will build directly against GDAL (since it said yes, and then
no???!!!!)

Looks like you found a long-standing bug in the configure script (only
happens when you specify the full path to gdal-config). It said yes to
that and then checked again to see if you had done just --with-gdal, and
the answer to that was no! I have fixed it in CVS so the second check is
conditional on the first one failing. The bug was harmless though.

Paul