[GRASS-dev] GRASS-TNG

Sören Gebbert soerengebbert at gmx.de
Wed Feb 21 13:59:56 EST 2007


Hi,

Trevor Wiens schrieb:
> 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?

Yes. But this does not mean grass has a bad design or is not good. Not 
at all! GRASS is a great peace of software. It was a absolutely 
fanstastic decision to make it available to the masses as open source. 
The concept (cli interace, modules, scriptable + grafical frontend ) is 
still  progressive.
Starting from scratch means to use the enormus knowledge manifested in 
the code of grass to create a new hopefully much better GIS core.

IMHO the design of grass back in the 80s was very progressive.
And all developers who worked/work on grass have my greatest respect.

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

I disagree. Because C is a subset of C++
you are able to combine object orientated approaches with speed.
Many fast libraries and applications are written in C++. And they chosed 
C++ not because its a modern language, they chosed C++ because it was 
the best choice for the project. And this includes not only GUI projects 
like:
* FLTK, wxWidgets or Qt
It includes also libraries and programms which need to run as fast possible:
* most game graphic engines: eg. ogre!
* visualization libraries: VTK, Open Inventor, OpenSceneGraph ...
* gdal, ogr, proj.4
...

And in my humble opinion: an object orientated approach is the best
choice for a GIS. Because every point on earth has the same property:
Coordiantes in space and time and all kind of attribute data. Those 
points can be represented as raster or voxel cells, vector point, lines 
... and so on. And with an objectoriented approach based on this 
principle you can create a very sophisticated GIS core.

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

Time series support is not only done by rewriting the raster library.
You need also to rewrite the whole file and metadata handling of grass 
to enable sophisticated time series for raster, raster3d and vector 
data. Becsaue all available data types should be supported.

> 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

Just my two cents
Soeren




More information about the grass-dev mailing list