[GRASS-dev] GRASS-TNG

[Radek Bartoň]

On Thursday 22 of February 2007 09:45:13 Markus Neteler wrote:
> Radek Bartoň wrote on 02/22/2007 01:04 AM:
> > On Thursday 22 of February 2007 00:19:14 tlaronde at polynum.com wrote:

> To me it sounds a bit like "name hijacking" which will generate
> confusion. OSGeo has
> developed branding rules, logo usage and so forth. I hope that we don't
> have to do
> the same here. It worked for the last 25 years that people, developing
> something new,
> also chose a new name (see KerGIS etc).
> Since you dislike the GRASS code, I don't see any reason why you should
> take its
> name and logo. I see a moral problem here.

OK. Since there is a problem I'll change a name. I can name it for instance 
GAL as an acronym for "GRASS Abstraction Layer". If it is stil too close to 
GRASS name G could be a acronym for GIS? But as I said, I don't want to be 
completely independent  from GRASS development. I'd like to provide another 
way how to implement new or reimplement existing modules to GRASS for those 
who don't want to deal with plain C. If this seems to you as a different 
project with no connection to GRASS, all right it can be developed 
separatelly but if you'll consider that my project could live within GRASS in 
future please let me know and we can cooperate.

> But I don't think that anyone is opposed to implementing new ideas.
> Personally,
> I believe much in code evolution rather that rewriting things from
> scratch. At
> least, my lifetime doesn't suffice to do the latter, replication years
> of scientific
> work which then gets coded into software. But you are probably younger
> than me :-)
> Maybe you underestimate the years of testing which have been done within
> the GRASS project. New developers are always welcome.
>
> Of course I am looking forward you new parallelized GIS with n-dimensional,
> topological vector engine and 4D support for all data types (also hybrid
> r/v would
> be fancy). No kidding, new code is pretty needed and the topological
> vector engine
> really needs optimization. In my personal work, I suffer from the lack of
> time series support (I worked around it with scripts). So, also that's hot.

Aim of my project is not to implement all these features, the aim is to 
provide environment to do that easily and think about that support from 
beginning. It is up to anyone who needs any of that features to implement it 
using this environment.

> Could you give me some more details why an object oriented approach
> is fancy (for us, for our applications)? AKAIK there is only Smallworld
> doing
> that, so there must be a reason why GIS industry didn't choose the concept.

Object orientation in code itself doesn't imply object orientation in data 
structures but can support them. Generally my project shouldn't be dependent 
on internal data structures. It should provide an abstraction layer. Reasons 
for object orientation on that kind of level within code is for an easy 
readability and power of expression.

> Concerning C++: The module causing most portability problems in GRASS
> is r.terraflow (the only C++ module). If you look at the DebianGIS list,
> the GDAL package there is pretty old due to C++ compatibility problems.
> AFAIK a major pain for DebianGIS users.
> As Frank stated (and I am sure that he knows his business), the C++ ABI
> is pretty fragile and causing tons of extra problems.

Yes. That will be problem to solve. Maybe it implies abandonment of GDAL 
within my project but this is last solution.

> BTW: You can use GRASS GPL commercially (make money by using it).

Why would I do that? :-)

-- 
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

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