[GRASS5] Applicant for developing

GRASS GRASS developer
1

Hello,

I work in a geographer office, I'm also a photogrammeter and a C
developer on Un*x systems (trying to ensure POSIX susv3 compatibility
when there is no good reason to deviate). When I begin a new coding work
I do work with Don Knuth's literate programming tools (namely the C
oriented version `cweb') ---just to say that if, someday, I contribute a
totally new piece of code this will be done that way; hope this is not a
problem...
And I'm French, just to say that I write this kind of english that only
non-english native speakers understand fluently :wink:

Since I have started a GIS work where I am, at the moment, hired, and
since I have tested some proprietary GIS software and GRASS, finding
GRASS alltogether better thought than some poor all Access(TM) based
proprietary solution (claiming OpenGIS conformity so I hope you don't
want to go that way, do you?), I'd like to help the GRASS project.

The questions are:

1) Since GRASS is engaged in some major changes (new vector format and
so on) where to find the more comprehensive explanations about the
changes planned;
2) Are there tips to discover the coding tree structure/style of the
actual GRASS;
3) Are there accessible repositories where to find some state of the art
descriptions of topology oriented algorithms.

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

2

Thierry Laronde said:

Hello,

The questions are:

1) Since GRASS is engaged in some major changes (new vector format and
so on) where to find the more comprehensive explanations about the
changes planned;

All available info on 5.1 should be indexed here:
http://grass.itc.it/grass51/index.html

For draft 5.1 programming manuals go here:
http://grass.itc.it/grass51/manuals/

2) Are there tips to discover the coding tree structure/style of the
actual GRASS;
3) Are there accessible repositories where to find some state of the art
descriptions of topology oriented algorithms.

You should look at the programmer's manual for 5.0:
http://grass.itc.it/grass5/progmangrass50.pdf

And for code access, there is the GRASS CVS repository:
http://grass.itc.it/grasscvs.html

Moritz

3

On Sat, Jul 26, 2003 at 11:02:15PM +0200, Moritz Lennert wrote:

All available info on 5.1 should be indexed here:
http://grass.itc.it/grass51/index.html

For draft 5.1 programming manuals go here:
http://grass.itc.it/grass51/manuals/

[..]
You should look at the programmer's manual for 5.0:
http://grass.itc.it/grass5/progmangrass50.pdf

And for code access, there is the GRASS CVS repository:
http://grass.itc.it/grasscvs.html

Thanks!

I will have some time in august, so I will hopefully being able to start
some work on small problems I encounter as a user while diving in the code.

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

4

Also, the mailing list archives are a very good place to search for
information, particularly discussions about future features and direction
of GRASS and many things are not documented anywhere else. Unfortunately,
it is more difficult to find things here than it used to be as
it is not archived on google any more, but you may search it on
http://grass.itc.it/searchgrass.html (when the server is not
overloaded...) More recent messages are also archived on gmane.org

For fixing small problems you find with GRASS it is worth considering
whether they should go into the 5.3.x series (which uses the 'grass' CVS
repository at http://freegis.org/cgi-bin/viewcvs.cgi/grass/ ) or the
5.7.x series (which uses the 'grass51' CVS repository at
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/ and has a different
directory structure and build system).

At the minute, the 5.7.x series is harder to work with and less polished
but it will probably benefit the GRASS user community most for the future
if you contribute to it.

Paul K

5

On Saturday 26 July 2003 21:30, Thierry Laronde wrote:

Since I have started a GIS work where I am, at the moment, hired, and
since I have tested some proprietary GIS software and GRASS, finding
GRASS alltogether better thought than some poor all Access(TM) based
proprietary solution (claiming OpenGIS conformity so I hope you don't
want to go that way, do you?),

Probably not, simply because I am too tired to start all the work from scratch,
but I see it as a quite big problem that GRASS doesn't conform to SFS (OpenGIS).
Not because SFS is better (and may be it is in some particular cases), but because
almost all the world is using (or will be using in near future) SFS.
Now we can still get some clean data, because many users were using topological
ArcInfo coverage. Coverage is not supported any more for editing by ESRI, AFAIK.
And that's the end of clean data, and more or less the end of the possibility to import
polygon data to GRASS without problems.
You are maybe the first newcomer who did not ask 'Is GRASS SFS compliant?'

These days, I am thinking about possibility to model overlapping polygons
in topological format, I think it is possible, but limited. I need
to make some tests and then I will write something about that.

BTW, anybody has any experience with ArcGIS >= 8.3 spatial integrity rules?
Does it work? Do people realy use that?

Radim

6

Hello,

On Mon, Jul 28, 2003 at 09:20:36AM +0200, Radim Blazek wrote:

On Saturday 26 July 2003 21:30, Thierry Laronde wrote:
> Since I have started a GIS work where I am, at the moment, hired, and
> since I have tested some proprietary GIS software and GRASS, finding
> GRASS alltogether better thought than some poor all Access(TM) based
> proprietary solution (claiming OpenGIS conformity so I hope you don't
> want to go that way, do you?),

Probably not, simply because I am too tired to start all the work from scratch,
but I see it as a quite big problem that GRASS doesn't conform to SFS (OpenGIS).

Please don't take anything as an "attack" ---since I know how poorly
rewarding the work for open source/free software might be, with people
always critizing.

These are just remarks from an user and also a developer.

Not because SFS is better (and may be it is in some particular cases), but because
almost all the world is using (or will be using in near future) SFS.

I don't know the details of the specifications but I have seen one
proprietary implementation. This software is handling _all_ its data
through a database access, with an intolerable overhead, a poor result
and this is in no way "open" since all one has access to is Large binary
objects unreadable.

If the aim is to allow GRASS to interface with others, why not? But if
this interface will spoil the internal representation of the data and
the efficiency of the access, I'm a priori more reluctant.

My point of view is probably limited, indeed perhaps narrow, but I
prefer a clean solution to a "popular" one. My definition of "open" is
also narrow: what must be open is the door to let me escape with my
data. If I have means to import a standard format and to export to a
standard format without loosing the added value I have worked on, for me
the software is correct (whether proprietary/open, free(gratis)/sold).
(if this were true, everybody will have to implement, on a standard
basis, one import module, and one export one. And that's all).

That's partly why I'm a bit surprised that the "open GIS" initiative
has not focused to a define a standard file format (based perhaps on STEP iso
10303).

But it is probably too soon for me to speak about this with the sole
experience of a not optimal Windows oriented application: I'm perhaps
afraid about a deviation of the specifications, and not the spirit of
it.

Regards.
--
Thierry Laronde <tlaronde@polynum.org>

7

On Monday 28 July 2003 19:38, Thierry Laronde wrote:

Please don't take anything as an "attack" ---since I know how poorly
rewarding the work for open source/free software might be, with people
always critizing.

Attacks are welcome. You must expect counter-attack, but what I see
below is not realy attack, you have to learn more about GRASS to find
our real weaknesses.

My point of view is probably limited, indeed perhaps narrow, but I
prefer a clean solution to a "popular" one.

Do you prefer clean solution as programmer only or also as user?
It is nice to have clean solution, but if you cannot work with
dirty data all others are producing? I don't want to make
GRASS "example reference GIS application following GIS theory of '80s",
(even if it probably looks like that), it should be also possible to
use it for real work.

My definition of "open" is
also narrow: what must be open is the door to let me escape with my
data. If I have means to import a standard format and to export to a
standard format without loosing the added value I have worked on, for me
the software is correct

Currently the standard de facto is shapefile (very similar to SFS)
and it is impossible for example, to import overlapping areas from
shapefile. Topological format is good only for areas in 2D,
once you have more dimensions (z, time) you are lost.
We have to prove to model overlapping areas in topological
format (at least for limited number of overlapping areas)
or to add a new type for polygon to GRASS format.

Radim

8

Hello,

On Tue, Jul 29, 2003 at 11:51:21AM +0200, Radim Blazek wrote:

Attacks are welcome. You must expect counter-attack, but what I see
below is not realy attack, you have to learn more about GRASS to find
our real weaknesses.

The first thing I have discovered, compare to the proprietary solution
are the strenghs of GRASS: access to source code, un*x inside, etc. that
is means to solve problems more automatically (by some programming) than
if I had had to do everything by hand. Combining small (well,
"specialized" --- and _not_ v.trim!!) program to have a path from
orignal_mess to mostly_organized.

> My point of view is probably limited, indeed perhaps narrow, but I
> prefer a clean solution to a "popular" one.

Do you prefer clean solution as programmer only or also as user?

Both, I don't know for others but here the problem was to take data
absolutely not created with GIS in mind and to obtain without remaking
everything a GIS and without some programming it was not possible to
make the work. So I think a GIS user must be, at least, a little a
programmer.

It is nice to have clean solution, but if you cannot work with
dirty data all others are producing?

That's what I make here, but indeed with easy data (I mean 2D at the
moment, but 3D is in the scope).

I don't want to make
GRASS "example reference GIS application following GIS theory of '80s",
(even if it probably looks like that), it should be also possible to
use it for real work.

> My definition of "open" is
> also narrow: what must be open is the door to let me escape with my
> data. If I have means to import a standard format and to export to a
> standard format without loosing the added value I have worked on, for me
> the software is correct

Currently the standard de facto is shapefile (very similar to SFS)
and it is impossible for example, to import overlapping areas from
shapefile. Topological format is good only for areas in 2D,
once you have more dimensions (z, time) you are lost.
We have to prove to model overlapping areas in topological
format (at least for limited number of overlapping areas)
or to add a new type for polygon to GRASS format.

As you have said I have almost all to discover, so the discussion will
be useless because I have not the necessary background.
But what I have noted, as a user, is that the proprietary solution I
have tested was "good" (I only mean easy to use for an average user) for
displaying and querying an already built GIS, but the problem was, at
least here and for me, to build it, and the means were poor. It has
appeared to me that it was indeed the main focus of such a program to
display several already built sources and this is also like that that
OpenGIS appears to me ---I may be wrong, I give my impression. But that
was definitively not adressing my needs.

Regards,
--
Thierry Laronde <tlaronde@polynum.org>