today I "played" a bit with DXF contour files (3D DXF).
It seems that we have a slightly confusing number of
DXF import modules...
But first: I have added DXF layer output to v.in.dxf. It
should be a flag, but the write routines are spreaded all over the source
code. So far the module now prints the layers after import, for example:
had some problems with configure script which could
not correctly define PCINCPATH and PQLIBPATH
variables:
----from config.log
configure:6827: checking whether to use PostgreSQL
configure:6847: checking for location of PostgreSQL
includes
configure:6873: checking for libpq-fe.h
configure:6881: gcc -E /usr/local/pgsql/include
conftest.c >/dev/null 2>conftest.out
----
now that would give error unless I put
-I/usr/local/pgsql/include and
-L/usr/local/pgsql/lib into configure script variables
on line 6836
later, the linux-686-specific head file requires the
same -I and -L handwork added prefixes to allow
compilation of old postgres modules
----------------
I use sources from the cvs snapshot of Nov 9
----------------
there's also a small error in
src.garden/gr*/g.colum*/infxColumn.c:
Hi
I can run other db.* modules with odbc-postgresql
driver, except for
db.tables that gets "dbmi: Protocol error" message and
terminates.
unlike other db.* modules, f.e. db.columns, which also
call macro
DB_RECV_RETURN_CODE and it returns DB_OK to them,
db_list_tables
calls the following macro chain (line 14,
c_list_tabs.c):
DB_START_PROCEDURE_CALL(DB_PROC_LIST_TABLES);
that either should return error or pass through; so it
does the second,
but later the call to db__recv_int would invoke
db_protocol_error().
As far as I traced the calls from grass to rpc libs,
those were:
But first: I have added DXF layer output to v.in.dxf.
[snip]
I think that's useful.
I think that's a great addition, Markus.
[snip]
Maybe it would make sense to merge v.in.dxf and v.in.dxf3d with
an optional flag for the Z value. And what about v.cadlabel...?
Comments and volunteers would be welcome.
I think combining the v.in.dxf* files is a good idea. v.cadlabel
performs a pretty unique function. I don't have a use for it and
wouldn't expend any effort supporting it. v.import and v.export have
DXF functions and I think those should probably be removed. The reason
is that the DXF format is important and difficult to support. It needs
to be supported through a specialized set of programs. Supporting DXF
import and export through additional generic tools like v.import and
v.export seems to me like an unnecessary added work load.
We had a thread about DXF imports last spring. Unless things have
changed in more recent rewrites there are several problems with the
existing import routines. There are several object types that they
don't import; in particular, they don't import text or splines. They
don't import text on arcs either, but maybe that's too much to expect.
There are probably other data types that aren't imported.
I've written my own import routines for DXF->grass ascii vector and DXF
text->paint labels, but I doubt that my routines are sufficient for the
future needs of GRASS.
There is at least one third-party import/export library released under
the GPL. The one I know if is DIME, which is a C++ class library. I'm
not very comfortable programming in C++. Also, I don't have much time
to spare right now and we will probably be into next year before I do.
Just the same, when time is available I will be willing to help.
> But first: I have added DXF layer output to v.in.dxf.
[snip]
> I think that's useful.
I think that's a great addition, Markus.
[snip]
> Maybe it would make sense to merge v.in.dxf and v.in.dxf3d with
> an optional flag for the Z value. And what about v.cadlabel...?
>
> Comments and volunteers would be welcome.
I think combining the v.in.dxf* files is a good idea. v.cadlabel
performs a pretty unique function. I don't have a use for it and
wouldn't expend any effort supporting it. v.import and v.export have
DXF functions and I think those should probably be removed. The reason
is that the DXF format is important and difficult to support. It needs
to be supported through a specialized set of programs. Supporting DXF
import and export through additional generic tools like v.import and
v.export seems to me like an unnecessary added work load.
We had a thread about DXF imports last spring. Unless things have
changed in more recent rewrites there are several problems with the
existing import routines. There are several object types that they
don't import; in particular, they don't import text or splines.
I am not sure whether this would be of any help, it depends on how
splines are defined in DXF, but there are spline functions for curves
used in few GRASS modules, e.g. v.to.sites (to generate additional points
on a curve if the given points are too far apart) and SG3d (and probably
nviz)
to define the fly path, so to write support for import of splines may be
simplified by
using these functions, they work pretty well.
They
don't import text on arcs either, but maybe that's too much to expect.
There are probably other data types that aren't imported.
I've written my own import routines for DXF->grass ascii vector and DXF
text->paint labels, but I doubt that my routines are sufficient for the
future needs of GRASS.
There is at least one third-party import/export library released under
the GPL. The one I know if is DIME, which is a C++ class library. I'm
not very comfortable programming in C++. Also, I don't have much time
to spare right now and we will probably be into next year before I do.
Just the same, when time is available I will be willing to help.
On Sun 11. November 2001 14:33, sixote alin wrote:
Hi
I can run other db.* modules with odbc-postgresql
driver, except for
db.tables that gets "dbmi: Protocol error" message and
terminates.
unlike other db.* modules, f.e. db.columns, which also
call macro
DB_RECV_RETURN_CODE and it returns DB_OK to them,
db_list_tables
calls the following macro chain (line 14,
c_list_tabs.c):
DB_START_PROCEDURE_CALL(DB_PROC_LIST_TABLES);
that either should return error or pass through; so it
does the second,
but later the call to db__recv_int would invoke
db_protocol_error().
As far as I traced the calls from grass to rpc libs,
those were:
Above is described communication between module and driver, and I don't
expect problems there. I think that driver function db_driver_list_tables()
in src/libes/dbmi/drivers/odbc/listtab.c fails for some reason, and driver
returns something else than expected integer. But all calls to ODBC
are checked for returned values, so I don't know where the problem is.
Used sources from CVS Nov.9, Linux RH 7.1/postgresql
-7.1.3
--alex
db.tables works here on RH7.1/postgres-7.0.3/postgresql-odbc-7.0.3
and RH7.1/mysql-3.23.36/MyODBC-2.50.39