Hi all,
v.to.db is new module for loading data from vector to DB:
- insert rows for new categories
- update column(s) with label, count, length, area and point(site) x,y
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi all,
today I checked in two prototype Oracle 8.x modules from
Christian Saldarini <cristian@torno.como.polimi.it>:
src.garden/grass.oracle2/
d.ora.rast
d.ora.sites
Markus
Here Christian's original mail:
-----------------------------------
Date: Tue, 06 Jun 2000 12:33:48 +0200
From: Christian Saldarini <cristian@torno.como.polimi.it>
To: Markus Neteler <neteler@geog.uni-hannover.de>
Subject: Re: oracle-grass interface
Markus Neteler wrote:
To be shure: Did you upgrade the existing version in src.garden
or develop from scratch? Perhaps it makes sense to remove the current
old version from GRASS 5 and replace by yours. Maybe other programmers
can assist you.
Well I made it from ground zero, to take advantage of new geometrical
functions of Oracle's Spatial Cartridge;the problem is that it was just a
sample code to test oracle's performances, so it's not so complicated.
In my opinion it could be useful to show others how to merge oracle and grass
libraries (how to write oracle's malkefiles and call basic oracle's
function);in this case i have to add explanations in almost every line of
code.
The next thing to say is that preparing oracle tables with user data and
creating all indexes is not so easy. Not every kind of users can afford this
system both for economical and technical needings.
Did you try the PostgreSQL interface included in GRASS 5? Perhaps
yours and this from Alex Shevlakov can be merged to become a powerful
interface.
That's a good idea: the A.S. interface does other things (like
reclassification), so with a few work togheter we can merge our commands whit
his ones, without redundancy.
Beside that a new ODBC driver is there (db.* modules), I connected to
PostgreSQL as well (should work with Oracle, too). It is using
unixODBC.
universal, reliable, portable, but not so fast as a custom solution...I really
don't know what's the best way.
(As you can understand i'm a performance maniac!)
[...]
Bye
Christian Saldarini
cristian@torno.como.polimi.it
-------------------------------
Further details can be found in:
src.garden/grass.oracle2/README.txt
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Markus Neteler wrote:
Hi all,
today I checked in two prototype Oracle 8.x modules from
[...]
> Beside that a new ODBC driver is there (db.* modules), I connected to
> PostgreSQL as well (should work with Oracle, too). It is using
> unixODBC.universal, reliable, portable, but not so fast as a custom solution...I really
don't know what's the best way.
(As you can understand i'm a performance maniac!)
Note about DBMI (db.* modules): DBMI != ODBC
DBMI is GRASS library for writing RDBMS modules and drivers.
You can write your own driver for Oracle or Postgres
but share all db.* modules with users of other RDBMS.
(I know it is also bit slower) . I started to work on dbmi because I think
it is better solution than:
d.rast.pg d.what.r.pg g.column.pg g.table.pg v.in.arc.pg
d.site.pg d.what.s.pg g.select.pg pg.in.dbf v.in.shape.pg
d.vect.pg d.what.v.pg g.stats.pg v.reclass.pg
d.rast.inf d.what.r.inf g.column.inf g.table.inf r.rescale.inf
d.site.inf d.what.s.inf g.select.inf v.reclass.inf
d.vect.inf d.what.v.inf g.stats.inf r.reclass.inf
d.vect.ora d.what.v.ora g.stats.ora r.rescale.ora
d.rast.ora d.what.r.ora g.column.ora g.table.ora v.reclass.ora
d.site.ora d.what.s.ora g.select.ora r.reclass.ora
.......
and so on for each RDBMS.
But it's only my opinion.
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Dear developers,
currently Roger Bivand is improving his "R"-GRASS
interface. You can use R within GRASS, load a
R-GRASS library and bidirectional exchange data
between GRASS and R for analysis.
So far, so good, but he is facing following problem:
Roger wrote:
I think the compiled
interface is going to work, though I'm still worried about
G_fatal_error(), which kills R too. It would be nice to have a function to
turn it off when GRASS libraries are being linked into dynamically loaded
modules in other settings, or at least to stop it doing exit(). Maybe
there is one? (Not the handler, because that doesn't stop the exit().)
Do you have any ideas to help him?
Many thanks in advance
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Markus Neteler wrote:
Do you have any ideas to help him?
I propose to modify the library code of G_fatal_error() in order to
use an environment variable, saying $FATAL_EXIT to control the
call to exit()
Just my 2/100 Euro
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Dear Markus (and others),
After two long night, I finaly have something that mimics (as far
as I know) the e00 format. The boring thing was to create the
"universe" polygon beloved by Arc/Info.
I would be glad if some Arc/Info owner can test the output.
I something doesnt work, I will like to have an original e00
file of a simple drawing (2 polygons, on with a hole, and an
external isle) with straigth lines, so it's easy to import and
export and to compare both.
v.out.e00 use the Grass dig_att file for filling the attribute of
the coverage-ID, so if it is linked to an external database via the
attribute, you should get all of them in Arc/Info.
Here is the program, the Gmakefile and the manual page in html.
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97
v.out.e00.tgz (5.06 KB)
Michel,
Shoot this to Lisa here (Lisa_Zygo@baylor.edu). She's got
arcinfo on her desktop. I'm compiling th code now. We'll
try it out today.
Bruce
Michel Wurtz - ENGEES/CEREG wrote:
Dear Markus (and others),
After two long night, I finaly have something that mimics (as far
as I know) the e00 format. The boring thing was to create the
"universe" polygon beloved by Arc/Info.I would be glad if some Arc/Info owner can test the output.
I something doesnt work, I will like to have an original e00
file of a simple drawing (2 polygons, on with a hole, and an
external isle) with straigth lines, so it's easy to import and
export and to compare both.v.out.e00 use the Grass dig_att file for filling the attribute of
the coverage-ID, so if it is linked to an external database via the
attribute, you should get all of them in Arc/Info.Here is the program, the Gmakefile and the manual page in html.
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97------------------------------------------------------------------------
Name: v.out.e00.tgz
v.out.e00.tgz Type: WinZip File (application/x-compressed)
Encoding: base64
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Dear Michel!
On Fri, Jun 16, 2000 at 03:26:13PM +0200, Michel Wurtz - ENGEES/CEREG wrote:
Dear Markus (and others),
After two long night, I finaly have something that mimics (as far
as I know) the e00 format. The boring thing was to create the
"universe" polygon beloved by Arc/Info.
Hooray...!!
I have added it to CVS. The HTML page is moved to the ../../html/
section.
Another step to improve GRASS' acceptance!
Even without ARC* we can exchange data now and keep the topolgy.
Many thanks, Michel,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus, hi Roger,
the general problem is (as i understand), that the GRASS concept assumes
that every call to the gis libraries comes from a module, that should
exit() if something goes wrong. The clean way would be to have a
centralized error handling routine that sets a global error flag and
returns an error status. But that is nearly impossible to implement now.
I must admit that i do not know in which way the interfacing between R
and GRASS is done, so that i have no idea how to circumvent the
exit()-problem. Possible: spawning a sub-process from R, so that the
sub-process exits and returns an error. Or setting up an own exit
handler with atexit().
Please correct me if i am wrong in assuming that the problem are calls
to G_fatal_error() from inside the library. Perhaps you could give me an
example where to look at some code.
cu,
Andreas
Markus Neteler wrote:
Dear developers,
currently Roger Bivand is improving his "R"-GRASS
interface. You can use R within GRASS, load a
R-GRASS library and bidirectional exchange data
between GRASS and R for analysis.So far, so good, but he is facing following problem:
Roger wrote:
>I think the compiled
>interface is going to work, though I'm still worried about
>G_fatal_error(), which kills R too. It would be nice to have a function to
>turn it off when GRASS libraries are being linked into dynamically loaded
>modules in other settings, or at least to stop it doing exit(). Maybe
>there is one? (Not the handler, because that doesn't stop the exit().)Do you have any ideas to help him?
Many thanks in advance
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Dear developers,
from David's data (he posted this bug recently) I have
run some 20 tests on working with single and multiple
string attribute in sites lists. Single and multiple
doubles are read correctly.
There is a bug:
Several string attributes are not read correctly,
if *spaces* occur within the strings (even if
@"substringA substringB" is used).
It can be tested with s.info which says: "format mismatch".
The bug must be in: src/libes/gis/sites.c
Function: int G__site_get (internal)
Maybe around line 393.
Note: If you have multiple string attributes *without*
spaces, it works o.k.
Unfortunately my programming knowledge is sufficient
to fix the problem.
Looking forward for help
Markus
PS: I have fixed the d.siter Gmakefile, now d.siter
will be installed properly (a nice "d.sites" tool
based on tcl/tk).
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Sat, 17 Jun 2000, Andreas Lange wrote:
Hi Markus, hi Roger,
the general problem is (as i understand), that the GRASS concept assumes
that every call to the gis libraries comes from a module, that should
exit() if something goes wrong. The clean way would be to have a
centralized error handling routine that sets a global error flag and
returns an error status. But that is nearly impossible to implement now.
Yes, the essence of the problem is that the library (gis) assumes that
death is a safe solution, and does not consider situations where functions
may be called from "foreign" programs not needing to be killed without
mercy.
The G_set_error_routine() function does work when G_fatal_error and
G_warning are called properly, that is that they are used instead of just
saying exit. Most of what's needed seems to be in place, and having
checked *.[ch] in libes/gis, the critical weaknesses were in error.c,
env.c, and get_row.c, all of which hit exit without going through the
error handler pointed to by G_set_error_routine. Having sorted out that,
the next issue was why it still didn't work - G_gisinit hit a fatal error
with no LOCATION, called G_fatal_error, which called print_error, which
then called log_error (setting active to 1 to avoid recursion), which
couldn't fing GISBASE, calling G_fatal_error again, but not then checking
to see if there is an alternative error handler. I've put edited versions
of the files on:
ftp://reclus.nhh.no/pub/misc/libes.gis.tar.gz
(I don't know that they don't break anything else!!)
I must admit that i do not know in which way the interfacing between R
and GRASS is done, so that i have no idea how to circumvent the
exit()-problem. Possible: spawning a sub-process from R, so that the
sub-process exits and returns an error. Or setting up an own exit
handler with atexit().Please correct me if i am wrong in assuming that the problem are calls
to G_fatal_error() from inside the library. Perhaps you could give me an
example where to look at some code.
The original interface was based on running R in the GRASS environment,
then running GRASS modules as system("g.whatever") from the R prompt, and
collecting the results. There were side effects, overhead for ASCII
transfer and loss of precision. I'm now doing a compiled interface,
dynamically loading a small number of C functions linked against libgis.a
(so far, more libes later). Dynamically loading something that can kill R
- which keeps everything in memory, and saving a big memory image to disk
every time an interface function is called seems a bit unfortunate. That
means that all the GRASS functions I link against need checking to see
that they don't just exit, but use G_fatal_error or G_warning properly. As
far as I am concerned:
G_fatal_error("whatever");
exit(-1);
is OK, because the program will never reach the exit - there are plenty of
cases like this.
Is this vaguely clear? (I'm not too sure myself!) My handler (by the way)
is:
int R_handler(char *message, int fatal) {
if(fatal == 1) error(message);
else warning(message);
}
where error() and warning() are R error handling functions that do all of
the housekeeping to get back up the call stack out of the function in
error. As of this evening, it works after having changed the files
mentioned above.
I'd be grateful for any advice.
Best wishes,
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'