[GRASS5] OOP and 3rd party libs

GRASS GIS GRASS GIS developer
1

Hi developers

I have been giving some thought recently to the question of third
party libraries in the GRASS environment, and how far we
might want to go in incorporating them into the main
distribution. To give a few of the matters arising:

1. Most large scale projects in the number-crunching zone,
whether they are free software, open source, public domain,
or whatever, incorporate some form of the BLAS/LAPACK libraries
for efficient linear algebra computations. Am I right in thinking
GRASS does not have this? Its presence would take a lot of
the burden away from developing separate routines in each module
and allow developers to concentrate on GIS specific code.

2. As an extension to the above there is the whole question of
linking to Fortran code. We already have some Fortran routines.
Do we have any Fortran developers? If I am right, this was
settled in the GRASS camp about 10 years ago - long before my time -
when it was decided as policy that future development would
concentrate on C and Fortran routines would be deprecated.
This is fine as far as it goed but I don't think we should
reject external Fortran routines if they do a specific job
more efficiently, and in any case will be maintained by others
who have skills more appropriate to the task, eg. mathematicians.
I am thinking of things where heavy repetitive number-crunching is
involved - co-ordiantes transformations, as in projection support,
possibly, finite element analysis, stats or (as above) linear algebra
routines.

3. Extending further, what about useful libs in other languages.
There is a lot of code in C++, and some in Ada95, that might be
useful. Again even if we are not using these languages ourselves
they are widely cross-platform and easy to link to C code. It is
much easier to find implementations of B-trees, RSTrees and the like
in C++ than in C, and they are often well-maintained.

4. Then - how much do we want ot rely on third party libraries?
They will generally be maintained by others, though they will
be GPL/BSD licensed, so we should be able to modify/improve them
as we see fit, and return the results to the broader community.

5. Finally, what about OOP. DO we want to start developing OOP
rouitnes within GRASS itself. I know some people regard OOP as
unnecessary, but others might feel the edge it gives development
to be indispensable. Others don't like C++. But there are
other options: Ada95 I have mentioned, and we have already
had numerous postings where people have praised Python as a
worhty development language for GRASS (with which I concur). There
is also Objective-C, which is more like a `natural' extension to
C itself, but is perhaps not so portable right now.

I would be interested to know if anyone else has had any
thoughts on these matters, and if so what they see as the
way forward.

Best wishes

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

My very shorts comments (not better than others)

David D Gray wrote:

Hi developers

I have been giving some thought recently to the question of third
party libraries in the GRASS environment, and how far we
might want to go in incorporating them into the main
distribution. To give a few of the matters arising:

1. Most large scale projects in the number-crunching zone,
whether they are free software, open source, public domain,
or whatever, incorporate some form of the BLAS/LAPACK libraries
for efficient linear algebra computations. Am I right in thinking
GRASS does not have this? Its presence would take a lot of
the burden away from developing separate routines in each module
and allow developers to concentrate on GIS specific code.

Only if they are part of the OS or GPL. Otherwise, it will be trouble
for large diffusion. Non OS or GPL, only for special projets not
part of main distribution.

2. As an extension to the above there is the whole question of
linking to Fortran code. We already have some Fortran routines.
Do we have any Fortran developers? If I am right, this was
settled in the GRASS camp about 10 years ago - long before my time -
when it was decided as policy that future development would
concentrate on C and Fortran routines would be deprecated.
This is fine as far as it goed but I don't think we should
reject external Fortran routines if they do a specific job
more efficiently, and in any case will be maintained by others
who have skills more appropriate to the task, eg. mathematicians.
I am thinking of things where heavy repetitive number-crunching is
involved - co-ordiantes transformations, as in projection support,
possibly, finite element analysis, stats or (as above) linear algebra
routines.

I know Fortran and any Fotran subroutine can be converted to C.
It depends on how many Fortran subroutine are present.

3. Extending further, what about useful libs in other languages.
There is a lot of code in C++, and some in Ada95, that might be
useful. Again even if we are not using these languages ourselves
they are widely cross-platform and easy to link to C code. It is
much easier to find implementations of B-trees, RSTrees and the like
in C++ than in C, and they are often well-maintained.

I like C++ and C++ isfar easier to teach to graduated students without
great computer expertise. It support OOP. One thing is to start
developping some high level C++ libraries which use the base C libraries.
Peoples can use the level they prefers (C or C++). I will not recommand
of developping C++ libraries independently of C libraries.

4. Then - how much do we want ot rely on third party libraries?
They will generally be maintained by others, though they will
be GPL/BSD licensed, so we should be able to modify/improve them
as we see fit, and return the results to the broader community.

If they are high quality, I agree. I do it often.

5. Finally, what about OOP. DO we want to start developing OOP
rouitnes within GRASS itself. I know some people regard OOP as
unnecessary, but others might feel the edge it gives development
to be indispensable. Others don't like C++. But there are
other options: Ada95 I have mentioned, and we have already
had numerous postings where people have praised Python as a
worhty development language for GRASS (with which I concur). There
is also Objective-C, which is more like a `natural' extension to
C itself, but is perhaps not so portable right now.

OOP is interesting but needs some thinking and discussions. I used it
more and more. I plan to do it in extending some GRASS functions for
our needs. I thing GRASS has some potential and interest but it needs
to be shown before preceeding. Experiments are require.

I would be interested to know if anyone else has had any
thoughts on these matters, and if so what they see as the
way forward.

Best wishes

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi developers,

i do not feel qualified to answer those questions, but i want to tell my
opinion.

David D Gray wrote:

1. Most large scale projects in the number-crunching zone,
whether they are free software, open source, public domain,
or whatever, incorporate some form of the BLAS/LAPACK libraries
for efficient linear algebra computations. Am I right in thinking
GRASS does not have this? Its presence would take a lot of
the burden away from developing separate routines in each module
and allow developers to concentrate on GIS specific code.

There is some code named "eigen_tools" (G_tqli, G_tred2), but i do not
know anything about it. If there is need for such a library, no
objections.

2. As an extension to the above there is the whole question of
linking to Fortran code. We already have some Fortran routines.
Do we have any Fortran developers? If I am right, this was
settled in the GRASS camp about 10 years ago - long before my time -
when it was decided as policy that future development would
concentrate on C and Fortran routines would be deprecated.
This is fine as far as it goed but I don't think we should
reject external Fortran routines if they do a specific job
more efficiently, and in any case will be maintained by others
who have skills more appropriate to the task, eg. mathematicians.
I am thinking of things where heavy repetitive number-crunching is
involved - co-ordiantes transformations, as in projection support,
possibly, finite element analysis, stats or (as above) linear algebra
routines.

If some module/function/library is only available in Fortran and the
code can be compiled with g77, i have no objections to including Fortran
code. But maybe it would be simpler to convert the whole module with f2c
to avoid possible compiling problems.
But the coordinate transformation and the projection support in grass
(corcnv lib and proj lib) do not rely on any fortran code. I don't think
that there are really problems with speed or efficiency in those
libraries, proj e. g. is very well designed and proven.

3. Extending further, what about useful libs in other languages.
There is a lot of code in C++, and some in Ada95, that might be
useful. Again even if we are not using these languages ourselves
they are widely cross-platform and easy to link to C code. It is
much easier to find implementations of B-trees, RSTrees and the like
in C++ than in C, and they are often well-maintained.

I personally do not like C++ and do not plan to program in grass with
C++. The problem will be that the C++ code should not introduce any
portability/compiler problems. I think GRASS should be portable to many
Unix and Unix-like systems and should not rely only on GNU egcs/g++
compiler. But again, if some functionality is only available with C++
and someone is able to integrate and document this, no objections.

4. Then - how much do we want ot rely on third party libraries?
They will generally be maintained by others, though they will
be GPL/BSD licensed, so we should be able to modify/improve them
as we see fit, and return the results to the broader community.

If the library has real benefits for GRASS, is needed for a
module/function in GRASS, gives better maintainability and performance
and has a compatible License (GPL/LGPL/BSD/PD) we should include it.
But i think that this cannot be decided in general, we should discuss
this as needed.

5. Finally, what about OOP. DO we want to start developing OOP
rouitnes within GRASS itself. I know some people regard OOP as
unnecessary, but others might feel the edge it gives development
to be indispensable. Others don't like C++. But there are
other options: Ada95 I have mentioned, and we have already
had numerous postings where people have praised Python as a
worhty development language for GRASS (with which I concur). There
is also Objective-C, which is more like a `natural' extension to
C itself, but is perhaps not so portable right now.

I personally think that incorporating OOP into an existing system has no
big benefits. GRASS' libraries have been developed in pre-OOP times and
i fear that wrapping this up into a OOP system will be very difficult.
The database structure and function semantics in GRASS are not object
oriented, but task oriented. All the late-coming systems had the benefit
that they could implement a clean OOP system from the beginning.
I would like to program in a script language (i know tcl/tk and Perl,
but both are not suited for GIS tasks) instead of writing C-Programs. I
had a glance at Python and think it is worth learning.
But overall i think that much simpler enhancements (e. g. to the
xdriver) will give a bigger effect with much lower workload than
redesigning the library to OOP.

cu,

Andreas

--
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'

4

I largely agree with Andeas views.
Here a few additions:

On Thu, Jun 08, 2000 at 11:26:52PM +0200, Andreas Lange wrote:

David D Gray wrote:
> 1. Most large scale projects in the number-crunching zone,
> whether they are free software, open source, public domain,
> or whatever, incorporate some form of the BLAS/LAPACK libraries
> for efficient linear algebra computations. Am I right in thinking
> GRASS does not have this? Its presence would take a lot of
> the burden away from developing separate routines in each module
> and allow developers to concentrate on GIS specific code.

There is some code named "eigen_tools" (G_tqli, G_tred2), but i do not
know anything about it. If there is need for such a library, no
objections.

> 2. As an extension to the above there is the whole question of
> linking to Fortran code.

I do not see advantages in using Fortran code.
And I am not aware of functionality that would exclusivly available
with fortran code.

If we need mathematical functions, may http://sourceware.cygnus.com/gsl/
GSL -- The GNU Scientific Library is an option.

> 5. Finally, what about OOP. DO we want to start developing OOP
> rouitnes within GRASS itself.

Object orientated programming (OOP) is a way to think and design programs
It is no necessarily connected to the syntax in a language. If you want
you can happily program object orientated in C itself.

But I agree with:

I personally think that incorporating OOP into an existing system has no
big benefits.

   Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

5

Andreas, thanks for your comments

Andreas Lange wrote:

David D Gray wrote:

> 2. As an extension to the above there is the whole question of
> linking to Fortran code. We already have some Fortran routines.
> Do we have any Fortran developers? If I am right, this was
> settled in the GRASS camp about 10 years ago - long before my time -
> when it was decided as policy that future development would
> concentrate on C and Fortran routines would be deprecated.
> This is fine as far as it goed but I don't think we should
> reject external Fortran routines if they do a specific job
> more efficiently, and in any case will be maintained by others
> who have skills more appropriate to the task, eg. mathematicians.
> I am thinking of things where heavy repetitive number-crunching is
> involved - co-ordiantes transformations, as in projection support,
> possibly, finite element analysis, stats or (as above) linear algebra
> routines.

If some module/function/library is only available in Fortran and the
code can be compiled with g77, i have no objections to including Fortran
code. But maybe it would be simpler to convert the whole module with f2c
to avoid possible compiling problems.

Yes, I notice now looking that BLAS and LAPACK are available as C code.
CLAPACK has been converted with f2c, then altered to be more C-friendly.
If you are interested (or anyone else is interested) there is
information
about these and other high performance maths libraries on
http://www.netlib.org and its mirrors.

> 4. Then - how much do we want ot rely on third party libraries?
> They will generally be maintained by others, though they will
> be GPL/BSD licensed, so we should be able to modify/improve them
> as we see fit, and return the results to the broader community.

If the library has real benefits for GRASS, is needed for a
module/function in GRASS, gives better maintainability and performance
and has a compatible License (GPL/LGPL/BSD/PD) we should include it.
But i think that this cannot be decided in general, we should discuss
this as needed.

To come back to linear algebra:

There was recently a debate about GRASS and parallel computing
systems on this list. This and other considerations show that
there is an interest in deploying GRASS on high performance systems -
not just linux PC's (or other PC's . . .). The advantage with things
like BLAS and LAPACK is that they are standards and it should be
possible to slot in versions optimised for high grade systems and
special tasks in place of the portable, general-purpose ones that
can be freely distributed from netlib. Of course I am not really
experienced here and I'm only repeating what I've read. There's
no reason why free GPL'd code like the GNU Scientific Library (gsl)
should not contain such special implementations, but the legacy
code is well ahead here, and if needed I see no problem with using
it as long as the license is compatible.

[A general question - does it violate the GPL if someone links to
a non-free dynamic library on their own system, where the link replaces
a link to a free distributable implementation - but without the
need to distribute the special implementation? ]

> 5. Finally, what about OOP. DO we want to start developing OOP
> rouitnes within GRASS itself.
...

I would like to program in a script language (i know tcl/tk and Perl,
but both are not suited for GIS tasks) instead of writing C-Programs. I
had a glance at Python and think it is worth learning.

I seem to recall some months ago I read somewhere, maybe on this list,
that there is a movement to get python scripting in ArcView? A possible
development would be code libraries and core stuff in C and provide
python hooks for rapid deployment of _modules_. ie write the modules in
python, or whatever scripting language we use. This wouldn't need to be
done all at once. The code could be written at first on an experimental
basis and as the need arises.

Quite a few of the issues raised here do depend on resolving one
problem, that has also been discussed before, and that is
dynamic linking.

Best wishes

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi Bernhard

Bernhard Reiter wrote:

> > 1. Most large scale projects in the number-crunching zone,
> > whether they are free software, open source, public domain,
> > or whatever, incorporate some form of the BLAS/LAPACK libraries
> > for efficient linear algebra computations. Am I right in thinking
> > GRASS does not have this? Its presence would take a lot of
> > the burden away from developing separate routines in each module
> > and allow developers to concentrate on GIS specific code.
>
> There is some code named "eigen_tools" (G_tqli, G_tred2), but i do not
> know anything about it. If there is need for such a library, no
> objections.

>
> > 2. As an extension to the above there is the whole question of
> > linking to Fortran code.

I do not see advantages in using Fortran code.
And I am not aware of functionality that would exclusivly available
with fortran code.

True, but what I really meant was that we might have advanced, difficult
to recreate and maintain code, that just happens to be available and
maintained in fortran, such as the matrix and vector handling routines
that come with BLAS and LAPACK and their extensions. But - I have just
found that much of this is also available in C.

If we need mathematical functions, may http://sourceware.cygnus.com/gsl/
GSL -- The GNU Scientific Library is an option.

I have just looked at the most recent release of this, and it
certainly now has much advanced functionality. For example, native
C implementations of BLAS - ie not just a wrapper or f2c translation.

Best wishes

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

To libe or not to libe that is the question, whether tis nobler...

Really, the question is not whether to include or certain libraries
for our use; rather, how can we make GRASS extensible so that
it remains a viable alternative for GIS work.

Two examples of current systems that allow installation of modules
for extending the capability of the system are perl and cygwin.
Perl has a directory system that is checked before the addition
of any module. They have three primary files for configuration.
In analogy to grass, it would be something like this:

/usr/local/grass-5.0b/Math/gsl

and in that directory would be have gsl.a, extralibs.all, extralibs.ld,
gsl.dll ( or gsl.so for solaris and/or gsl.sl for hpux)

The Cygwin toolset used to be a monolithic install procedure. Good
control but difficult to change and hard to add modules (programs).
When they merged with Redhat, they changed the install procedure
so that a setup.exe program can install one (or all) program from
the web or from the local drive. It's much better way to allow users
to add programs to the system.

Given these two examples, given the fact that we want GRASS to
succeed, let's look down the road on how to make it so users can
download a module of their choosing (Python,gsl,Octave,etc.)
and incorporate those features into an application that serves
their needs. Grass will surely survive if we provide this capability.

John Huddleston

----- Original Message -----
From: David D Gray <ddgray@armadce.demon.co.uk>
To: Grass Developer List <grass5@geog.uni-hannover.de>
Sent: Tuesday, June 06, 2000 9:17 AM
Subject: [GRASS5] OOP and 3rd party libs

Hi developers

I have been giving some thought recently to the question of third
party libraries in the GRASS environment, and how far we
might want to go in incorporating them into the main
distribution. To give a few of the matters arising:

1. Most large scale projects in the number-crunching zone,
whether they are free software, open source, public domain,
or whatever, incorporate some form of the BLAS/LAPACK libraries
for efficient linear algebra computations. Am I right in thinking
GRASS does not have this? Its presence would take a lot of
the burden away from developing separate routines in each module
and allow developers to concentrate on GIS specific code.

2. As an extension to the above there is the whole question of
linking to Fortran code. We already have some Fortran routines.
Do we have any Fortran developers? If I am right, this was
settled in the GRASS camp about 10 years ago - long before my time -
when it was decided as policy that future development would
concentrate on C and Fortran routines would be deprecated.
This is fine as far as it goed but I don't think we should
reject external Fortran routines if they do a specific job
more efficiently, and in any case will be maintained by others
who have skills more appropriate to the task, eg. mathematicians.
I am thinking of things where heavy repetitive number-crunching is
involved - co-ordiantes transformations, as in projection support,
possibly, finite element analysis, stats or (as above) linear algebra
routines.

3. Extending further, what about useful libs in other languages.
There is a lot of code in C++, and some in Ada95, that might be
useful. Again even if we are not using these languages ourselves
they are widely cross-platform and easy to link to C code. It is
much easier to find implementations of B-trees, RSTrees and the like
in C++ than in C, and they are often well-maintained.

4. Then - how much do we want ot rely on third party libraries?
They will generally be maintained by others, though they will
be GPL/BSD licensed, so we should be able to modify/improve them
as we see fit, and return the results to the broader community.

5. Finally, what about OOP. DO we want to start developing OOP
rouitnes within GRASS itself. I know some people regard OOP as
unnecessary, but others might feel the edge it gives development
to be indispensable. Others don't like C++. But there are
other options: Ada95 I have mentioned, and we have already
had numerous postings where people have praised Python as a
worhty development language for GRASS (with which I concur). There
is also Objective-C, which is more like a `natural' extension to
C itself, but is perhaps not so portable right now.

I would be interested to know if anyone else has had any
thoughts on these matters, and if so what they see as the
way forward.

Best wishes

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write

to:

minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

ahoy all,
  just a quick question.. more a curiosity... im starting to do some
development work with GRASS, prob XDRIVER stuff, and i was just
wondering if there is talk of or anything started with a java
implementation of GRASS. it would take care alot of the problems that i
have seen discussed on this list in more short time here.. loadable
modules (just java classes), makes alot of the driver stuff
disappear... of course, java3d isnt really avaialable everywhere the
java vm is.. anyway, just wondering... thanks in advance, wayne

9

"wayne c deprince jr." wrote:

ahoy all,
  just a quick question.. more a curiosity... im starting to do some
development work with GRASS, prob XDRIVER stuff, and i was just
wondering if there is talk of or anything started with a java
implementation of GRASS. it would take care alot of the problems that i
have seen discussed on this list in more short time here.. loadable
modules (just java classes), makes alot of the driver stuff
disappear... of course, java3d isnt really avaialable everywhere the
java vm is.. anyway, just wondering... thanks in advance, wayne

Java enthousiast is going down. I will not invest in Java except
for WEB. I considered Java a few years ago and decided not because
of the large development requirement. I will go for C++ before
cosidering Java as many are doing presently.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Hi Wayne,

here an interesting forward concerning GRASS and JAVA:

----------------------------------

From jpreston@uwimona.edu.jm Thu Apr 6 16:48:05 2000

Return-Path: <jpreston@uwimona.edu.jm>
To: Markus Neteler <neteler@geog.uni-hannover.de>
Subject: RE: Foundation of German GRASS User Group / 15.April 2000 - Hannover
Date: Thu, 6 Apr 2000 09:52:19 -0000

Thanks. On another matter I sent this posting to the list but I haven't seen
it circulated so I'll just tell you now.

I would like to get some feedback on a project that we are working on at my
Institute. We have a java servlet front end to GRASS 4.3 and a RDBMS (Solid
2.3) which allows us the
provide a simple application oriented interface to the geographic
information system.

The url is http://196.3.4.220:8000/jdb/icens.sivs?class=gis

the username is "guest" and password "icens".

Our university network is currently being restructured from routers to
switches so until they get it right the speed might be slow between 10:00 am
and 5:00pm est. Any other time the speed should be acceptable.

Do you know of other servlet interface project for GRASS or other groups
working on something similar?

Any feedback (including the bad ones...) will be welcome.

John Preston
International Centre for Environmental and Nuclear Sciences
University of the West Indies
Mona, Kingston 7, JAMAICA
jpreston@uwimona.edu.jm

P.S. The site is currently in beta so if some (or all of the) commands seem
broken, forgive me!!.
-------------------------------------------------

Another approach is already in
src.garden/grass.java/

related to this pages:
http://www.vtt.co.jp/staff/sorokin/jni/

Best wishes

Markus

On Mon, Jun 12, 2000 at 09:44:49AM +0200, wayne c deprince jr. wrote:

ahoy all,
  just a quick question.. more a curiosity... im starting to do some
development work with GRASS, prob XDRIVER stuff, and i was just
wondering if there is talk of or anything started with a java
implementation of GRASS. it would take care alot of the problems that i
have seen discussed on this list in more short time here.. loadable
modules (just java classes), makes alot of the driver stuff
disappear... of course, java3d isnt really avaialable everywhere the
java vm is.. anyway, just wondering... thanks in advance, wayne

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

markus neteler,
  thank you very much for the info. it was a curiosity since im kind of
a java "geek" :slight_smile: im actually working with cesare furlanello at itc.it
on the stereo vision in grass, etc. so ill prob be bothering you more
in the next 1.5-2 months.. if i am a bother please let me know..
thanks again, wayne

Markus Neteler wrote:

Hi Wayne,

here an interesting forward concerning GRASS and JAVA:

----------------------------------
>From jpreston@uwimona.edu.jm Thu Apr 6 16:48:05 2000
Return-Path: <jpreston@uwimona.edu.jm>
To: Markus Neteler <neteler@geog.uni-hannover.de>
Subject: RE: Foundation of German GRASS User Group / 15.April 2000 - Hannover
Date: Thu, 6 Apr 2000 09:52:19 -0000

Thanks. On another matter I sent this posting to the list but I haven't seen
it circulated so I'll just tell you now.

I would like to get some feedback on a project that we are working on at my
Institute. We have a java servlet front end to GRASS 4.3 and a RDBMS (Solid
2.3) which allows us the
provide a simple application oriented interface to the geographic
information system.

The url is http://196.3.4.220:8000/jdb/icens.sivs?class=gis

the username is "guest" and password "icens".

Our university network is currently being restructured from routers to
switches so until they get it right the speed might be slow between 10:00 am
and 5:00pm est. Any other time the speed should be acceptable.

Do you know of other servlet interface project for GRASS or other groups
working on something similar?

Any feedback (including the bad ones...) will be welcome.

John Preston
International Centre for Environmental and Nuclear Sciences
University of the West Indies
Mona, Kingston 7, JAMAICA
jpreston@uwimona.edu.jm

P.S. The site is currently in beta so if some (or all of the) commands seem
broken, forgive me!!.
-------------------------------------------------

Another approach is already in
src.garden/grass.java/

related to this pages:
http://www.vtt.co.jp/staff/sorokin/jni/

Best wishes

Markus

On Mon, Jun 12, 2000 at 09:44:49AM +0200, wayne c deprince jr. wrote:
> ahoy all,
> just a quick question.. more a curiosity... im starting to do some
> development work with GRASS, prob XDRIVER stuff, and i was just
> wondering if there is talk of or anything started with a java
> implementation of GRASS. it would take care alot of the problems that i
> have seen discussed on this list in more short time here.. loadable
> modules (just java classes), makes alot of the driver stuff
> disappear... of course, java3d isnt really avaialable everywhere the
> java vm is.. anyway, just wondering... thanks in advance, wayne

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Hi Wayne,

On Tue, Jun 13, 2000 at 08:13:58AM +0200, wayne c deprince jr. wrote:

markus neteler,
  thank you very much for the info. it was a curiosity since im kind of
a java "geek" :slight_smile: im actually working with cesare furlanello at itc.it
on the stereo vision in grass, etc. so ill prob be bothering you more
in the next 1.5-2 months.. if i am a bother please let me know..

You are very welcome! I still try to get this "raw" stereo vision software
for you from my Indian colleague, I will meet him in August. Maybe
too late for you...

It would be pretty cool to have such a stereo aerial software module
in GRASS.

Best wishes to Cesare
and enjoy your time at Trento

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'