[GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc.

GRASS GIS GRASS GIS developer
1

dear allies,

i'm a relative newcomer to GRASS, so i appreciate your indulgence of any
mistakes i make. i've searched the web pretty extensively, and come to
the conclusion (though it's a bit opaque), based on documents dating
from between 2003 and 2005, that this is the status of importing DWG
data into GRASS:

1. v.in.dwg is the only module available

2. it can only be used by compiling from source

3. one has to use the old OpenDWG Toolkit, rather than the actively
maintained DWGDirect, either of which require becoming an associate
member of OpenDesign Alliance by faxing a contract (no $$)

4. the approach is to unarchive the Toolkit into a folder, and then to
run ./configure like so:

   ./configure \
   ... \
   --with-opendwg \
   --with-opendwg-includes=/home/usr1/opendwg27 \
   --with-opendwg-libs=/home/usr1/opendwg27

5. and then to compile GRASS from scratch

is this correct? will this process work with 6.2.2? is there any
movement on using DWGDirect, which is the only way to be compatible with
more recent versions of AutoCAD?

thanks so much!
.brush

2

brush wrote:

i'm a relative newcomer to GRASS, so i appreciate your indulgence of any
mistakes i make. i've searched the web pretty extensively, and come to
the conclusion (though it's a bit opaque), based on documents dating
from between 2003 and 2005, that this is the status of importing DWG
data into GRASS:

1. v.in.dwg is the only module available

Correct.

2. it can only be used by compiling from source

Correct.

The licences for GRASS and the OpenDWG library are incompatible, so
it's impossible to distribute a binary which satisfies both licences.

3. one has to use the old OpenDWG Toolkit, rather than the actively
maintained DWGDirect, either of which require becoming an associate
member of OpenDesign Alliance by faxing a contract (no $$)

AFAICT, yes.

4. the approach is to unarchive the Toolkit into a folder, and then to
run ./configure like so:

   ./configure \
   ... \
   --with-opendwg \
   --with-opendwg-includes=/home/usr1/opendwg27 \
   --with-opendwg-libs=/home/usr1/opendwg27

You need to build the OpenDWG library first.

5. and then to compile GRASS from scratch

If you already have a precompiled version of GRASS 6.3, you can
probably build just v.in.dwg with e.g.:

  make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs

6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so
you can't easily build individual modules outside of the source tree.

is this correct? will this process work with 6.2.2? is there any
movement on using DWGDirect, which is the only way to be compatible with
more recent versions of AutoCAD?

Someone who has the DWGDirect library will need to provide the code.

I'm not sure whether any of the active developers have either of the
DWG libraries (the original author of v.in.dwg, Radim Blazek, is no
longer an active developer).

The licensing conditions for the various DWG libraries (and the fact
that AutoDesk goes to significant lengths to inhibit compatibility)
tend to suppress interest.

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

3

thanks, glynn, for the quick response. some more comments and questions
inline:

On Sat, Sep 15, 2007 at 03:37:26AM +0100, Glynn Clements wrote:

> 1. v.in.dwg is the only module available

Correct.

> 2. it can only be used by compiling from source

Correct.

The licences for GRASS and the OpenDWG library are incompatible, so
it's impossible to distribute a binary which satisfies both licences.

understood. the ideal scenario in this situation, of course, would be
some kind of "one step" integrability in which, once a user has obtained
the library source from the opendesign alliance, v.in.dwg would be
compiled and integrated automatically with GRASS.

> 4. the approach is to unarchive the Toolkit into a folder, and then to
> run ./configure like so:
>
> ./configure \
> ... \
> --with-opendwg \
> --with-opendwg-includes=/home/usr1/opendwg27 \
> --with-opendwg-libs=/home/usr1/opendwg27

You need to build the OpenDWG library first.

really? both some (original?) versions of the v.in.dwg instructions,
and the opendwg toolkit manuals, seem to imply that the .h and .a
libraries (really just 4 files) are already built, and just need to be
linked into v.in.dwg's compilation. am i missing something?

> 5. and then to compile GRASS from scratch

If you already have a precompiled version of GRASS 6.3, you can
probably build just v.in.dwg with e.g.:

  make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs

6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so
you can't easily build individual modules outside of the source tree.

ok. i actually currently only have a precompiled version of 6.2.1. so
here's my questions:

how stable is 6.3? is it appropriate for enduser use?

the major installation hassle with GRASS seems to be getting all the
dependencies worked out. so if i install a precompiled 6.2.2 on (say)
xubuntu, and then recompile just GRASS with the new libraries, will that
avoid most of the hassles?

goodness, it would be nice to have a script to do this!

> is this correct? will this process work with 6.2.2? is there any
> movement on using DWGDirect, which is the only way to be compatible with
> more recent versions of AutoCAD?

Someone who has the DWGDirect library will need to provide the code.

I'm not sure whether any of the active developers have either of the
DWG libraries (the original author of v.in.dwg, Radim Blazek, is no
longer an active developer).

i'd be happy to provide the library code to developer(s) to update
v.in.dwg; it would be a collaborative partnership with our organization,
thus within the legal constraints of the license. if this is a real
possibility, whom would i contact?

The licensing conditions for the various DWG libraries (and the fact
that AutoDesk goes to significant lengths to inhibit compatibility)
tend to suppress interest.

i certainly understand that. at the same time, an enormous amount of
GIS-related information is stored in DWG files. are there other ways to
convert such information to more easily GRASS-readable data?

thanks,
.b

4

brush wrote:

thanks, glynn, for the quick response. some more comments and questions
inline:

On Sat, Sep 15, 2007 at 03:37:26AM +0100, Glynn Clements wrote:

> 1. v.in.dwg is the only module available

Correct.

> 2. it can only be used by compiling from source

Correct.

The licences for GRASS and the OpenDWG library are incompatible, so
it's impossible to distribute a binary which satisfies both licences.

understood. the ideal scenario in this situation, of course, would be
some kind of "one step" integrability in which, once a user has obtained
the library source from the opendesign alliance, v.in.dwg would be
compiled and integrated automatically with GRASS.

> 4. the approach is to unarchive the Toolkit into a folder, and then to
> run ./configure like so:
>
> ./configure \
> ... \
> --with-opendwg \
> --with-opendwg-includes=/home/usr1/opendwg27 \
> --with-opendwg-libs=/home/usr1/opendwg27

You need to build the OpenDWG library first.

really? both some (original?) versions of the v.in.dwg instructions,
and the opendwg toolkit manuals, seem to imply that the .h and .a
libraries (really just 4 files) are already built, and just need to be
linked into v.in.dwg's compilation. am i missing something?

Yes: these files you have to obtain from the OpenDesign Alliance.
AFAIK we could distribute binaries of v.in.dwg if there were dynamic
DWGDirect libraries available, but they aren't (at least not some months
ago). Since they only provide static libraries (.a instead of .so), they get
compiled into GRASS and hence fall under the "no distribution" restriction.

Maybe you can convince the OpenDesign Alliance to also make
dynamic libraries available?

Markus
--
View this message in context: http://www.nabble.com/v.in.dwg%3A-status-in-GRASS-6.2.2%2C-DWGdirect%2C-etc.-tf4446146.html#a12692350
Sent from the Grass - Dev mailing list archive at Nabble.com.

5

brush wrote:

> > 4. the approach is to unarchive the Toolkit into a folder, and then to
> > run ./configure like so:
> >
> > ./configure \
> > ... \
> > --with-opendwg \
> > --with-opendwg-includes=/home/usr1/opendwg27 \
> > --with-opendwg-libs=/home/usr1/opendwg27
>
> You need to build the OpenDWG library first.

really? both some (original?) versions of the v.in.dwg instructions,
and the opendwg toolkit manuals, seem to imply that the .h and .a
libraries (really just 4 files) are already built, and just need to be
linked into v.in.dwg's compilation. am i missing something?

Ah; my mistake. I had assumed that they were providing source.

> > 5. and then to compile GRASS from scratch
>
> If you already have a precompiled version of GRASS 6.3, you can
> probably build just v.in.dwg with e.g.:
>
> make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs
>
> 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so
> you can't easily build individual modules outside of the source tree.

ok. i actually currently only have a precompiled version of 6.2.1. so
here's my questions:

how stable is 6.3? is it appropriate for enduser use?

For a single user, 6.3 is probably preferable to 6.2. The occasional
user-visible change is probably outweighed by additional
functionality.

The main reason to stick with 6.2 is if you are investing significant
time and effort in creating scripts (or course material), where any
incompatible change would be a major inconvenience.

the major installation hassle with GRASS seems to be getting all the
dependencies worked out. so if i install a precompiled 6.2.2 on (say)
xubuntu, and then recompile just GRASS with the new libraries, will that
avoid most of the hassles?

When compiling from source, one thing to bear in mind is that you also
need the development packages (with the headers and .so symlinks) for
each dependency.

goodness, it would be nice to have a script to do this!

Installing dependencies is highly platform-specific. Once you have all
of the dependencies, "configure ; make ; make install" will often
suffice if you don't need some of the less common features.

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

6

Markus Neteler wrote:

Yes: these files you have to obtain from the OpenDesign Alliance.
AFAIK we could distribute binaries of v.in.dwg if there were dynamic
DWGDirect libraries available, but they aren't (at least not some months
ago). Since they only provide static libraries (.a instead of .so), they get
compiled into GRASS and hence fall under the "no distribution" restriction.

It doesn't make any difference whether the libraries are static or
dynamic.

Unless you can supply the OpenDWG/DWGDirect source code under a
GPL-compatible licence, you cannot distribute a binary which is linked
(statically or dynamically) against both the GRASS libraries and the
DWG libraries.

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

7

On Sat, Sep 15, 2007 at 09:20:29PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> Yes: these files you have to obtain from the OpenDesign Alliance.
> AFAIK we could distribute binaries of v.in.dwg if there were dynamic
> DWGDirect libraries available, but they aren't (at least not some months
> ago). Since they only provide static libraries (.a instead of .so), they get
> compiled into GRASS and hence fall under the "no distribution" restriction.

It doesn't make any difference whether the libraries are static or
dynamic.

Unless you can supply the OpenDWG/DWGDirect source code under a
GPL-compatible licence, you cannot distribute a binary which is linked
(statically or dynamically) against both the GRASS libraries and the
DWG libraries.

would it be possible to create a standalone binary that converts from
DWG into GRASS-internal data structures, which could be accessed if it
exists from inside GRASS? then this binary could have a licensing
structure separate from GPL.

this would make it a lot easier to separately maintain and compile that
code in a one-click fashion, reducing the barrier to use.

does this make sense?

.b

8

question at end...

On Sat, Sep 15, 2007 at 09:10:27PM +0100, Glynn Clements wrote:

> > If you already have a precompiled version of GRASS 6.3, you can
> > probably build just v.in.dwg with e.g.:
> >
> > make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs
> >
> > 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so
> > you can't easily build individual modules outside of the source tree.
>
> ok. i actually currently only have a precompiled version of 6.2.1. so
> here's my questions:
>
> how stable is 6.3? is it appropriate for enduser use?

For a single user, 6.3 is probably preferable to 6.2. The occasional
user-visible change is probably outweighed by additional
functionality.

The main reason to stick with 6.2 is if you are investing significant
time and effort in creating scripts (or course material), where any
incompatible change would be a major inconvenience.

> the major installation hassle with GRASS seems to be getting all the
> dependencies worked out. so if i install a precompiled 6.2.2 on (say)
> xubuntu, and then recompile just GRASS with the new libraries, will that
> avoid most of the hassles?

When compiling from source, one thing to bear in mind is that you also
need the development packages (with the headers and .so symlinks) for
each dependency.

> goodness, it would be nice to have a script to do this!

Installing dependencies is highly platform-specific. Once you have all
of the dependencies, "configure ; make ; make install" will often
suffice if you don't need some of the less common features.

ok: then it seems to me i should install a precompiled version of 6.3,
and then build v.in.dwg alone using the Makefile fragments. is that
correct? this will avoid having to have development pkgs for
dependencies...

if i get this working, i'll try and write up instructions; where could
they be posted?

thanks,
.b

9

Glynn Clements wrote:

It doesn't make any difference whether the libraries are static or
dynamic.

Unless you can supply the OpenDWG/DWGDirect source code under a
GPL-compatible licence, you cannot distribute a binary which is linked
(statically or dynamically) against both the GRASS libraries and the
DWG libraries.

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

Right.

Maybe it is worth to look at how gvSIG solves this
http://www.gvsig.gva.es/index.php?id=faq-preguntas-tec&K=1&L=2
?
Take out their lib/driver and use that also for us? Seems to be here
http://sourceforge.net/project/showfiles.php?group_id=151469

Their CVS:
http://gdbms-plugins.cvs.sourceforge.net/gdbms-plugins/gdbms%20drivers/src/main/java/com/hardcode/gdbms/driver/dwg/
but the real code seems to be elsewhere.

Markus
--
View this message in context: http://www.nabble.com/v.in.dwg%3A-status-in-GRASS-6.2.2%2C-DWGdirect%2C-etc.-tf4446146.html#a12693948
Sent from the Grass - Dev mailing list archive at Nabble.com.

10

brush:

> > 2. it can only be used by compiling from source

Glynn:

> Correct.
>
> The licences for GRASS and the OpenDWG library are incompatible, so
> it's impossible to distribute a binary which satisfies both licences.

understood. the ideal scenario in this situation, of course, would be
some kind of "one step" integrability in which, once a user has obtained
the library source from the opendesign alliance, v.in.dwg would be
compiled and integrated automatically with GRASS.

This is a job for the GRASS Extensions Manager (GEM), see gem/README in
the GRASS 6.2.2 or 6.3 source code, and one of the reasons it was written.

Note that some developers may not be terribly interested in devoting
their own volunteer development time into coding a "tivo" solution that
makes it easy to sidestep the spirit of the GPL. The more that happens,
the less chance of a true "Open" DWG library ever gets written for
OGR/GDAL. This is not anti-user elitism, it is supporting long term user
interests over short term band-aids.

i'd be happy to provide the library code to developer(s) to update
v.in.dwg; it would be a collaborative partnership with our organization,
thus within the legal constraints of the license. if this is a real
possibility, whom would i contact?

Contact this mailing list (grass-dev). Patches can go into the GRASS patch
tracker, and are most welcome. It helps if you can convince a member of
the development team to become interested in it. (presumably someone with
a need for it)
Patch tracker:
  http://wald.intevation.org/tracker/?group_id=21

Glynn:

> The licensing conditions for the various DWG libraries (and the fact
> that AutoDesk goes to significant lengths to inhibit compatibility)
> tend to suppress interest.

brush:

i certainly understand that. at the same time, an enormous amount of
GIS-related information is stored in DWG files. are there other ways to
convert such information to more easily GRASS-readable data?

v.in.dxf seems to work pretty well for DXF, if you can save it in that
format. I don't know how it deals with the latest versions of DXF, but
have heard no complaints.

brush:

if i get this working, i'll try and write up instructions; where could
they be posted?

On the wiki site:
  http://grass.gdf-hannover.de/wiki/Main_Page

good luck,
Hamish

11

brush wrote:

> > Yes: these files you have to obtain from the OpenDesign Alliance.
> > AFAIK we could distribute binaries of v.in.dwg if there were dynamic
> > DWGDirect libraries available, but they aren't (at least not some months
> > ago). Since they only provide static libraries (.a instead of .so), they get
> > compiled into GRASS and hence fall under the "no distribution" restriction.
>
> It doesn't make any difference whether the libraries are static or
> dynamic.
>
> Unless you can supply the OpenDWG/DWGDirect source code under a
> GPL-compatible licence, you cannot distribute a binary which is linked
> (statically or dynamically) against both the GRASS libraries and the
> DWG libraries.

would it be possible to create a standalone binary that converts from
DWG into GRASS-internal data structures,

Not without re-writing a large portion of the vector library yourself.
And re-writing it if the GRASS vector format ever changes.

which could be accessed if it
exists from inside GRASS? then this binary could have a licensing
structure separate from GPL.

this would make it a lot easier to separately maintain and compile that
code in a one-click fashion, reducing the barrier to use.

A simpler solution would be to write something which converts DWG to a
published format, preferably one which GDAL/OGR can import.

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

12

brush wrote:

> When compiling from source, one thing to bear in mind is that you also
> need the development packages (with the headers and .so symlinks) for
> each dependency.
>
> > goodness, it would be nice to have a script to do this!
>
> Installing dependencies is highly platform-specific. Once you have all
> of the dependencies, "configure ; make ; make install" will often
> suffice if you don't need some of the less common features.

ok: then it seems to me i should install a precompiled version of 6.3,
and then build v.in.dwg alone using the Makefile fragments. is that
correct? this will avoid having to have development pkgs for
dependencies...

You may still need development packages for some of the dependencies;
PROJ and GDAL/OGR are the most likely candidates.

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