[GRASS-dev] GRASS-TNG

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.

Thank you.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

Radek Bartoň ha scritto:

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.

Thank you.

- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF3FUL/NedwLUzIr4RAiVMAKCbydbOWFUYzAHYt1bolz9Y6aaKmQCfWYOy
tWKp7k8aOxDcktrBkeRkpnE=
=G4Hf
-----END PGP SIGNATURE-----

Hi,

I am not Radek's speaker;-) Just last time I spoke to him I got
another impression. GRASS has a long history it is great tool full of
interesting algorithms. I have talked to many people who looked at
GRASS code and they got a relativelly bad impression. Generally the
code (core libraries) is very "old", not object-oriented, sometimes
very hard to manage and especially to improve the functionality. It is
pity because GRASS needs more developers, more ideas, more power
users, maybe "the modern design". From my point of view it would be
great to start working (try to impress) on a new GRASS design, to
build on the GRASS history, etc. (the more people will be involved the
better result can be). I don't like idea making the "fork". Just to
think about the future of GRASS. Anyway I hope that Radek's project
will bring something reasonable to GRASS community. At least new ideas
about GRASS future (GRASS 8?).

Best regards, Martin

2007/2/21, Paolo Cavallini <cavallini@faunalia.it>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

Radek Bartoò ha scritto:
> 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.
>
> Thank you.
>

- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF3FUL/NedwLUzIr4RAiVMAKCbydbOWFUYzAHYt1bolz9Y6aaKmQCfWYOy
tWKp7k8aOxDcktrBkeRkpnE=
=G4Hf
-----END PGP SIGNATURE-----

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

If it is fork depends on what is definition of fork. Generally it should be
independent project which would provide modern programming framework for
analytical modules similar to that in current GRASS. So any user which is
used to work with GRASS command line would be familiar with new system but
inside it'will use completely new design oriented to OOP, extensibility,
parallelity and dynamic languages. Theoretically it should be compatible with
any GRASS's GUI developed over modules in the future.

IMHO a current state of core parts of GRASS is so unogranizes and oldstyled
that any progressive development is very difficult. That is why I think that
start from scratch and only take good ideas from GRASS is now the best
solution how to make a 21th century open-source GIS realizable.

For next one year I'll be working on making its design and prototype
implementation as my diploma work so even if this project wouldn't keep up it
would be at least a research of GIS domain. I have spoken with a few current
GRASS developers and they invite my ideas so I wish it won't happen.

Only support from comunity I miss for now are discussion of ideas and needs of
features but any kind of help or invention is welcomed.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

Hi,

I just forgot to stress the last raster/display library improvents
(Soeren, Glynn and others). Good work!

Martin

2007/2/21, Martin Landa <landa.martin@gmail.com>:

Hi,

I am not Radek's speaker;-) Just last time I spoke to him I got
another impression. GRASS has a long history it is great tool full of
interesting algorithms. I have talked to many people who looked at
GRASS code and they got a relativelly bad impression. Generally the
code (core libraries) is very "old", not object-oriented, sometimes
very hard to manage and especially to improve the functionality. It is
pity because GRASS needs more developers, more ideas, more power
users, maybe "the modern design". From my point of view it would be
great to start working (try to impress) on a new GRASS design, to
build on the GRASS history, etc. (the more people will be involved the
better result can be). I don't like idea making the "fork". Just to
think about the future of GRASS. Anyway I hope that Radek's project
will bring something reasonable to GRASS community. At least new ideas
about GRASS future (GRASS 8?).

Best regards, Martin

2007/2/21, Paolo Cavallini <cavallini@faunalia.it>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So I assume it is a fork, which is generally a Bad Thing.
> May I ask you why forking, and which development forces do you have to
> carry on what appears a daunting task?
> All the best.
> pc
>
> Radek Bartoò ha scritto:
> > 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.
> >
> > Thank you.
> >
>
> - --
> Paolo Cavallini
> email+jabber: cavallini@faunalia.it
> www.faunalia.it
> Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF3FUL/NedwLUzIr4RAiVMAKCbydbOWFUYzAHYt1bolz9Y6aaKmQCfWYOy
> tWKp7k8aOxDcktrBkeRkpnE=
> =G4Hf
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

On 21/02/07 16:16, Radek Bartoň wrote:

On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

If it is fork depends on what is definition of fork. Generally it should be independent project which would provide modern programming framework for analytical modules similar to that in current GRASS. So any user which is used to work with GRASS command line would be familiar with new system but inside it'will use completely new design oriented to OOP, extensibility, parallelity and dynamic languages. Theoretically it should be compatible with any GRASS's GUI developed over modules in the future.

IMHO a current state of core parts of GRASS is so unogranizes and oldstyled that any progressive development is very difficult. That is why I think that start from scratch and only take good ideas from GRASS is now the best solution how to make a 21th century open-source GIS realizable.

For next one year I'll be working on making its design and prototype implementation as my diploma work so even if this project wouldn't keep up it would be at least a research of GIS domain. I have spoken with a few current GRASS developers and they invite my ideas so I wish it won't happen.

Only support from comunity I miss for now are discussion of ideas and needs of features but any kind of help or invention is welcomed.

You might want to look at Thierry's work on KerGIS (http://www.kergis.com/en/index.html) who decided not to work within the GRASS dev community with the current GRASS code for some of the same reasons you mention. However, he does not seem to be going the same direction you are in terms of language and programming choices.

Moritz

On 21/02/07 16:16, Radek Bartoň wrote:

On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

If it is fork depends on what is definition of fork. Generally it should be independent project which would provide modern programming framework for analytical modules similar to that in current GRASS. So any user which is used to work with GRASS command line would be familiar with new system but inside it'will use completely new design oriented to OOP, extensibility, parallelity and dynamic languages. Theoretically it should be compatible with any GRASS's GUI developed over modules in the future.

IMHO a current state of core parts of GRASS is so unogranizes and oldstyled that any progressive development is very difficult. That is why I think that start from scratch and only take good ideas from GRASS is now the best solution how to make a 21th century open-source GIS realizable.

For next one year I'll be working on making its design and prototype implementation as my diploma work so even if this project wouldn't keep up it would be at least a research of GIS domain. I have spoken with a few current GRASS developers and they invite my ideas so I wish it won't happen.

Only support from comunity I miss for now are discussion of ideas and needs of features but any kind of help or invention is welcomed.

Just another thought:

If you would like this to actually be a reflection on where GRASS might go in the future, why not do this within the GRASS community (for example on the GRASS wiki site) ? This might give the whole project more visibility and might help integrated ideas into GRASS.

Moritz

On Wednesday 21 of February 2007 16:39:32 Moritz Lennert wrote:

I chose Trac because of its features and extensibility that integrates all
tasks during software management and development. GRASS wiki is just wiki and
using mailing list as a main way of comunication is not clear enough for me.
Futhermore any comunication about GRASS-TNG in GRASS-dev mailing list may
babble there.

BTW: I have seen KerGIS already but I did't try that because I think that this
project is somewhere else.

Just another thought:

If you would like this to actually be a reflection on where GRASS might
go in the future, why not do this within the GRASS community (for
example on the GRASS wiki site) ? This might give the whole project more
visibility and might help integrated ideas into GRASS.

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

Hi,
i agree with radek.

The core design of grass is very old. And so the code basis.
Implementing basic features
like thread safety -> parallel processing, a raster library which support 2d and 3d raster maps with a sophisticated time series support
will result in rewriting the core of grass.

So i think it is a good approach to start from scratch using the 20 years of great experience with grass to create a successor. The software technics have radically changed in the last 20 years and so the hardware. And IMHO to profit from those changes, we need to start from scratch.

This also allows us to think about new great features, which are even not available in modern commercial GIS.

So lets collect new ideas at
http://grass-tng.no-ip.org.
This project will only work with the support of the grass community.
Take this as chance to discuss a new and better GIS core design.
All points of view are important, the views of the users which kind features they expect, the views of the developers which features are possible to implement and which not.

But important to know, we currently discuss the core design of GRASS-TNG, not the features of hundrets of grass modules. :slight_smile:

Best regards
Soeren

Radek Bartoň schrieb:

On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

If it is fork depends on what is definition of fork. Generally it should be independent project which would provide modern programming framework for analytical modules similar to that in current GRASS. So any user which is used to work with GRASS command line would be familiar with new system but inside it'will use completely new design oriented to OOP, extensibility, parallelity and dynamic languages. Theoretically it should be compatible with any GRASS's GUI developed over modules in the future.

IMHO a current state of core parts of GRASS is so unogranizes and oldstyled that any progressive development is very difficult. That is why I think that start from scratch and only take good ideas from GRASS is now the best solution how to make a 21th century open-source GIS realizable.

For next one year I'll be working on making its design and prototype implementation as my diploma work so even if this project wouldn't keep up it would be at least a research of GIS domain. I have spoken with a few current GRASS developers and they invite my ideas so I wish it won't happen.

Only support from comunity I miss for now are discussion of ideas and needs of features but any kind of help or invention is welcomed.

I'm all for improvements to the GRASS code and for adding new expertise to
the development team. I also think that new open source GIS (and other)
projects are a good thing. Ongoing evolution and diversity are hallmarks of
the open source community.

If there are to be major improvements or restructuring of the GRASS code, it
will benefit more people if it takes place within the (very loose) structure
of the GRASS community and existing code base. For example, Glynn Clements
has put in an enormous amount of work to modernize and update code recently.
He could really use some expert help with this.

If you are starting a completely new GIS project from scratch, this is
great. But giving it the name GRASS is misleading to potential users--even
more so if it has no relationship with the existing project except the name.

IMHO, I wish you would be willing to contribute your expertise to the
existing project, which can always use new developers. However, if you
prefer not to do this and would rather start a new project, I'd prefer that
you named it something other than GRASS to avoid confusion.

Michael

On 2/21/07 8:16 AM, "Radek Bartoò" <xbarto33@stud.fit.vutbr.cz> wrote:

On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:

So I assume it is a fork, which is generally a Bad Thing.
May I ask you why forking, and which development forces do you have to
carry on what appears a daunting task?
All the best.
pc

If it is fork depends on what is definition of fork. Generally it should be
independent project which would provide modern programming framework for
analytical modules similar to that in current GRASS. So any user which is
used to work with GRASS command line would be familiar with new system but
inside it'will use completely new design oriented to OOP, extensibility,
parallelity and dynamic languages. Theoretically it should be compatible with
any GRASS's GUI developed over modules in the future.

IMHO a current state of core parts of GRASS is so unogranizes and oldstyled
that any progressive development is very difficult. That is why I think that
start from scratch and only take good ideas from GRASS is now the best
solution how to make a 21th century open-source GIS realizable.

For next one year I'll be working on making its design and prototype
implementation as my diploma work so even if this project wouldn't keep up it
would be at least a research of GIS domain. I have spoken with a few current
GRASS developers and they invite my ideas so I wish it won't happen.

Only support from comunity I miss for now are discussion of ideas and needs of
features but any kind of help or invention is welcomed.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Wed, Feb 21, 2007 at 04:47:14PM +0100, Radek Barto? wrote:

BTW: I have seen KerGIS already but I did't try that because I think that this
project is somewhere else.

And where exactly do you think it is?

KerGIS is not aimed to be the "modern GIS", "millenium GIS" and so on.

KerGIS is not: GRASS is poor, and just throw away piece after piece.

KerGIS is: I love GRASS as a software alive, learning from its
strengths and correcting its weaknesses.

The Art of Computer Programming dates back early 1960. It's still a
reference.

Unix dates back 1970. It's more and more the reference.

UML on the other side is a contemporary subject of laughs (see acmqueue,
they have some great papers about "dead by UML fever").

If you want to improve GRASS, you must learn first what GRASS is and how
it was supposed to work as a whole when there was a core _developers_
team. Beauty is homogeneity. Distinct pieces that fit perfectly one with
each other in an unity.

If you want to learn GRASS, you must go back to its core.

That's what KerGIS has done.

I already changed a lot of things. I already reverted some changes I
made because I found that I did not correctly understand how things
work. KerGIS will end being significantly different from GRASS from the
engineering point of view. And despite of that, it will still be GRASS
because it will be one step nearer GRASS' very nature. It will be an
evolution of GRASS.

ESRI presented its products as a 3 stages line, from cheap to expensive:

1) Visualizing and updating SIG informations;

2) Being able to produce maps;

3) Being able to analyze data.

GRASS/KerGIS is the more powerful, since it's naturally stage 3.
Improving tools for 1 and 2 can be done (these tools already exist even
if they are not sexy).

And more than once, people with all the bells and whistles of shiny commercial
GUI were unable to do the work while KerGIS/GRASS was able to do it.

I find it rather---say---disgusting to read that whenever people find
something not obvious with GRASS, they think this is GRASS fault. And
the last thread about throwing away v.digit is typical.

Despite what people may think, I'm less conceited than the majority of
the people I read here. I still think that CERL GRASS is a golden gift.
And when I found a mistake, I do not blame the developers, but I'm just
proud to have the chance to become one of them making KerGIS/GRASS
even better.

But I'm not born tired, that's probably why I do not feel comfortable
in the contemporary "europe". You are probably right then : since I do
not belong to this low epoq, I do not feel compelled to produce the
"software of the XXI century". I prefer to work on an eternal one...

Even if I'm the only one. People are not "impressed" by GRASS? But who
is impressed by them?
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

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@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)

On Wednesday 21 February 2007 08:44, Michael Barton wrote:

I'm all for improvements to the GRASS code and for adding new expertise to
the development team. I also think that new open source GIS (and other)
projects are a good thing. Ongoing evolution and diversity are hallmarks of
the open source community.

If there are to be major improvements or restructuring of the GRASS code,
it will benefit more people if it takes place within the (very loose)
structure of the GRASS community and existing code base. For example, Glynn
Clements has put in an enormous amount of work to modernize and update code
recently. He could really use some expert help with this.

If you are starting a completely new GIS project from scratch, this is
great. But giving it the name GRASS is misleading to potential users--even
more so if it has no relationship with the existing project except the
name.

IMHO, I wish you would be willing to contribute your expertise to the
existing project, which can always use new developers. However, if you
prefer not to do this and would rather start a new project, I'd prefer that
you named it something other than GRASS to avoid confusion.

Michael

On 2/21/07 8:16 AM, "Radek Bartoò" <xbarto33@stud.fit.vutbr.cz> wrote:
> On Wednesday 21 of February 2007 15:19:55 Paolo Cavallini wrote:
>> So I assume it is a fork, which is generally a Bad Thing.
>> May I ask you why forking, and which development forces do you have to
>> carry on what appears a daunting task?
>> All the best.
>> pc
>
> If it is fork depends on what is definition of fork. Generally it should
> be independent project which would provide modern programming framework
> for analytical modules similar to that in current GRASS. So any user
> which is used to work with GRASS command line would be familiar with new
> system but inside it'will use completely new design oriented to OOP,
> extensibility, parallelity and dynamic languages. Theoretically it should
> be compatible with any GRASS's GUI developed over modules in the future.
>
> IMHO a current state of core parts of GRASS is so unogranizes and
> oldstyled that any progressive development is very difficult. That is why
> I think that start from scratch and only take good ideas from GRASS is
> now the best solution how to make a 21th century open-source GIS
> realizable.
>
> For next one year I'll be working on making its design and prototype
> implementation as my diploma work so even if this project wouldn't keep
> up it would be at least a research of GIS domain. I have spoken with a
> few current GRASS developers and they invite my ideas so I wish it won't
> happen.
>
> Only support from comunity I miss for now are discussion of ideas and
> needs of features but any kind of help or invention is welcomed.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

I agree 100% with Michael's comments. Your support to the current project may
yield better results faster.

Good luck.

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Martin Landa wrote:

I am not Radek's speaker;-) Just last time I spoke to him I got
another impression. GRASS has a long history it is great tool full of
interesting algorithms. I have talked to many people who looked at
GRASS code and they got a relativelly bad impression. Generally the
code (core libraries) is very "old", not object-oriented, sometimes
very hard to manage and especially to improve the functionality. It is
pity because GRASS needs more developers, more ideas, more power
users, maybe "the modern design".

So you're essentially talking about re-writing a complete GIS from
scratch? In which case, why use the "GRASS" name?

GRASS' value isn't in its libraries, but in its modules. Those modules
depend upon the existing (crummy) API provided by the libraries.

AFAICT, the only part of the GRASS code which would be of any use for
the "TNG" project would be the fundamental algorithms contained in the
modules.

--
Glynn Clements <glynn@gclements.plus.com>

Hi,

Yet Another GIS Soft. I don't thik, that we need Yet Another, as there
are lot's of existing and good project, that just lack manpower to
keep up with growing requirements for GIS software.

I don't want to sound like troll, thus will ask two simple questions:
How You plan to make Yours project to succeed (hiring developers, other way?)?
How Your product is going to differ from already existing projects ant
they goals?
There are lot of existing projects in different languages with different goals:
GRASS :wink:
QuantumGIS
SAGA
uDig
gvSIG
JUMP
+ different web based projects etc.

I suggest to take look at SAGA first - it's working, it's modular,
it's C++. Maybee would be better to improve already existing
programms?

And, yes, IMHO it's more easy to learn how to drop together some C
lines to get new GRASS module, than learn how to do same in C++ with
all GUI stuf. That's why I like GRASS - I can help GRASS development
eaven if I'm not a programmer/coder.

Just my (trolls) pieace of wood to keep flamme burning.
Maris.

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

On Wednesday 21 of February 2007 17:44:01 Michael Barton wrote:

If there are to be major improvements or restructuring of the GRASS code,
it will benefit more people if it takes place within the (very loose)
structure of the GRASS community and existing code base. For example, Glynn
Clements has put in an enormous amount of work to modernize and update code
recently. He could really use some expert help with this.

If you are starting a completely new GIS project from scratch, this is
great. But giving it the name GRASS is misleading to potential users--even
more so if it has no relationship with the existing project except the
name.

My intention is that GRASS-TNG would have more common with GRASS than just
name. For now it's only idea how to put core things together as flexible as
possible no matter what they will do. They can be then interally implemented
using current grass libraries or completely new way depending on how would it
be better. From external point of view it should provide very powerfull tool
to implement GRASS modules using their algorithms quickly and transparently
so that probability of programming errors would be less than i plain C (i. e.
a few lines of Python code can substitude a lot of C code lines) In any case
it should be result of vaste discussion between GRASS comuntity.

IMHO, I wish you would be willing to contribute your expertise to the
existing project, which can always use new developers. However, if you
prefer not to do this and would rather start a new project, I'd prefer that
you named it something other than GRASS to avoid confusion.

It shouldn't be a project in means of independent piece of software with own
support and team but more just case study how can be things organized. Even
if it'll end after a year or two with no useable implementation it can bring
some ideas and directions of how to involve current GRASS in the future.

--
Bc. Radek Bartoò

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

On Wednesday 21 of February 2007 19:03:22 Glynn Clements wrote:

So you're essentially talking about re-writing a complete GIS from
scratch? In which case, why use the "GRASS" name?

I mean and I don't. It's because of a way how I approach to my project's
design. I'm starting to think about an abstract GIS package for easy
development of modules (which can be used same way as GRASS's ones) and how
it should "ideally" look like. Then I/we'll be clarifying that idea to more
details so that certain shape of it will appear. When we'll be satisfied with
its shape then I would be the best time to proceed to some prototype
implementation to prove that concept could work. And then it'll be just up to
all developers current or new ones if some prototype part of implementation
will stay or if they'll be replaced with current GRASS code or completely new
and optimal one.

GRASS' value isn't in its libraries, but in its modules. Those modules
depend upon the existing (crummy) API provided by the libraries.

Yes, I completely agree with that. but tall tree can't have wormy roots.

AFAICT, the only part of the GRASS code which would be of any use for
the "TNG" project would be the fundamental algorithms contained in the
modules.

I agree again. I'm not afraid to take a C code of an module read it and
rewrite it in clearer way if I would have powerfull tools to do that.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

On Wednesday 21 of February 2007 19:42:32 you wrote:

Hi,

Yet Another GIS Soft. I don't thik, that we need Yet Another, as there
are lot's of existing and good project, that just lack manpower to
keep up with growing requirements for GIS software.

I don't want to sound like troll, thus will ask two simple questions:
How You plan to make Yours project to succeed (hiring developers, other
way?)? How Your product is going to differ from already existing projects
ant they goals?
There are lot of existing projects in different languages with different
goals: GRASS :wink:
QuantumGIS
SAGA
uDig
gvSIG
JUMP
+ different web based projects etc.

I think that I answered a lot of your questions in e-mails sent between your
and this reply. Here I only stress these things:

- GRASS-TNG aims are not to develop independent GIS software but define how
should GRASS look like inside to be more extensible and modern in development
and module way. If that look will occur compatible with current state of
things it can be completely assimilated.
- If I leave out time spent on inventing, describing and discussion ideas by
people from comunity it should be just one person work. This does not mean
that I want to do it only myself. Eveyone who share my ideas can join, but
anyway it'll be a diploma work so there should be some kind of entirety
within work I'll do.

I suggest to take look at SAGA first - it's working, it's modular,
it's C++. Maybee would be better to improve already existing
programms?

I've seen this project too. I really thought very long time if I shouldn't
join SAGA team but in the end I decided for GRASS because of three reasons:

- SAGA is mainly GUI oriented and GRASS don't or at least wasn't :slight_smile: I love a
way how can one use GRASS with command line. Of course they are some task
that coudn't be done without it (such as v.edit, v.pyedit).
- GRASS is well known, I mean it has wider comunity base and interest from
Linux distributions.
- I came across with GRASS first :-).

And, yes, IMHO it's more easy to learn how to drop together some C
lines to get new GRASS module, than learn how to do same in C++ with
all GUI stuf. That's why I like GRASS - I can help GRASS development
eaven if I'm not a programmer/coder.

Just my attitude: C is powerfull when you want to implement something
optimally but to realize abstract ideas quickly and clearily it's poor.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

On Wednesday 21 of February 2007 18:05:51 Trevor Wiens wrote:

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?

I answer by another question. It is possible to rewrite core parts without
affecting modules' code and without causing so much needs of refactoring and
bugs so that starting partially from scratch will not take so much time?

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.

Now I see that I perhaps shouldn't write that note that "C++ is standard" that
way. I was not ment as a argument against C but as a argument against Python
as main development language (even if I'd like to do everything in Python). I
decided for C++ for now because of that it provides balanced ratio between
relatively good perfomance and mainly certain level of abstraction and thus
fastest code aquisition. Secound reason was that certain people wanted that
core parts will be in C++. Whole project is about discussion so If you don't
agree just login to make rights to discussion forum and write up there your
suggestions.

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.

Sometimes a dream can turn to reality and sometimes they can't. For me even if
this project would end after year without any success it won't be a waste of
time. I just want to try to "make my dream become true" and it's up to
everyone if they consider that this project has a future and contribute to
it.

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.

I tried that way when I was exploring my possibilities of contribution. I
tried to look on NVIZ and implement colored vectors. After two day of hard
work I gave it up. Not because I lack of patience or determination. I just
consider that THIS is a waste of time.

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 would also like to second Michael's comments about naming. If this is
not part of the GRASS project, naming it GRASS is inappropriate.

I want to stay close to comunity as possible. If comunity consider that I'm
not close enough, I'll change a name of project, but without comunity I'll be
forced to change project's goal to make a real "fork" because without comunity
my project would be nothing.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz