[GRASS-dev] GRASS-TNG

[Trevor Wiens]

On Wed, 21 Feb 2007 15:05:02 +0100
Radek Bartoň wrote:

> Hello everyone.
>  
> I just started working on project that should bring a new wind to open-source 
> GIS comunity. It's called GRASS-TNG as the next generation of GRASS GIS and 
> it should be compatible with  GRASS on users' level but inside it will be 
> completely new. For futher informantion and questions refer to its homepage 
> or my e-mail.
> 
> The homepage is: http://grass-tng.no-ip.org
> 
> So everybody is welcomed to join and participate on it's development. A few 
> people was preliminary noticed before and they was full of exitement how this 
> project would be evolving so let's get surprised.
> 

Radek,

Although right now I'm not actively developing GRASS, I would like to
comment on this.

Generally my impression of this concept is not positive. Over the years
I've seen ambitious projects come and go and GRASS, warts and all,
remains. Yes, the core architecture of GRASS is old and certain aspects
need rewriting to be sure, but is it practical and thus intelligent to
try to start from scratch?

For example, on your site, you suggest that C++ be used because it is
the standard for "modern" development. The reality is, if you want
speed and memory efficiency, well coded plain C wins every time. If you
want to do GUI development, then C or C++ is probably not necessary for
most tasks, so some Python based solution is more appropriate. For core
libraries plain C is likely the best choice. Choosing a tool because it
is "modern" rather than because it is the best tool for the job, is not
logical.

Although there are issues with the raster library, the one issue I
continually face is the cruftiness of vector library's memory
management. Before he left the project Radim Blazek left a todo list of
issues to be resolved in the vector library. If you are full of energy,
IMHO it would be much more helpful to all users to take on that list and
resolve the memory issues in the vector library, rather than diverting
energy in pie in the sky dreams of a new GRASS.

If you want to support parallel processing or time series it would be
more appropriate to work on the redesign of the raster library with
those features in mind rather than forking the already limited
development resources of the project. Similarly, examination of the
core vector library as to how it needs to be modified would be useful.

My primary issue with your approach is the likelihood of wasted effort
ending up in the trash can, as I fully expect from projects like KerGIS.

However, if you are independently wealthy and have a staff of
developers waiting to work on this full time over the next year or two,
then I would be supporting the initiative.

Although there are issues with GRASS, this kind of effort is best kept
within the GRASS community like Michael Barton's GUI development
efforts, which have yielded real results quickly that are of direct
benefit to GRASS users.

I'm sure you have your reasons and are not likely to listen to this
advice. However good your intentions may be, your likelihood of
success is low and it will probably waste a lot of people's time in the
process. Please reconsider what is really possible, not what is ideal.

All that said, good luck with your efforts. GRASS is in need of work
and dedicated developers who ( unlike me ) can find the
time to invest in what is a very usable product for the most part and
has great potential.

I would also like to second Michael's comments about naming. If this is
not part of the GRASS project, naming it GRASS is inappropriate.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)