[GRASS5] Re: GRASS and GDAL

[Markus Neteler]

Hi Frank, [cc to GRASS 5 developers list]
hi GRASS developers,

On Tue, Jul 04, 2000 at 12:18:31PM -0500, Frank Warmerdam wrote:
> Markus Neteler wrote:
> > > OpenEV is built with Python as the extension language.  I think it would be
> > > _relatively_ easy to make menus and so forth for OpenEV using python that
> > > would launch GRASS analysis progress in the background, but I haven't analysed
> > > that issue in detail.
> > This sounds very good as Python may be a good way to reach portability
> > between UNIX/Linux and Windows world. We still hope to get GRASS
> > running on all platforms. John Huddleston added numerous patches to
> > GRASS, now the analysis tools run on Windows/Cygnus, the XRRIVER
> > port is still in progress.
> 
> Markus,
> 
> Certainly Python should not be a barrier to portability, but using Cygwin it
> seems that the XDRIVER stuff would be your main portability problem. 
Yes, you are right. I hope that the XDRIVER port can be finalised
soon :-)

> > > OSSIM might also be a useful viewer.  It is much less far advanced at this
> > > time, but it doesn't currently have a dependency on OpenGL which is a plus
> > > for portability.
> >
> > Well, what about Imagelinks? Is it for shure that OSSIM will be kept
> > in open source in future? I do not want to spend my time for others
> > and finally get no access to the code later on. Maybe this is somewhat
> > pessimistic?!
> 
> The code is public now, and under GPL / LGPL so there isn't anything they
> could do to retract it.  Of course, I think there is a substantial risk that
> they will abandon work on OSSIM at some point, perhaps before it is at a very
> useful state.  Of course that risk exists with OpenEV as well. 
> 
> > > I am not sure why you want to incorporate LIMP.  It isn't maintained much
> > > now, and it is mainly useful as a high performance environment to implement
> > > filters, and other image processing operators in.
> > Well, I thought it would help to speed up zooming etc. within
> > a GIS when using large datasets. I do not know enough about LIMP.
> 
> It does handle this well, but if you are mainly concerned about display 
> speed for overviews of images there are other ways of achieving good
> performance.  Certainly this is a key aspect of OpenEV, and I have done
> substantial work on GDAL to support pyramiding to help accelerate OpenEV.
Yes, pyramiding could be a useful approach to speed up the raster
management. Maybe it can be included into the GRASS raster libes,
then we do not need the LIMP.

> > > So, in summary, in the short term, I would like to work with the GRASS
> > > community to make OpenEV a useful GRASS data viewer; while leaving execution
> > > of analysis programs to the commandline (as now).  If this effort is
> > > reasonably successful, then it would make sense to pursue a closer
> > > integration, where GRASS analysis programs can be launched from OpenEV.
> >
> > You are very welcome. It would be a good idea to put this on
> > a web page within GRASS server to get more people involved.
> 
> I will promote OpenEV on the GRASS web page, and mailing list if/when I
> get a GRASS link completed. 
Please let me know when finished, then we add a page here.


> > > There was an issue about the license.  I think the easiest way to avoid
> > > this issue is for me to extract the code from the last non-GPL release.
> > > Is that 4.3?
> >
> > Well, what is the problem with license? I think as GRASS is GPL'ed, you
> > may use it and integrate it into GDAL. Note: The 4.x stuff does not have
> > floating point support. So you should go and use the current CVS
> > version. The libraries are in src/libes/, the includes in src/include/
> 
> The problem is that GDAL is not GPL.  It is under a less restrictive MIT
> license.  In order to link in GPL code, I have to make all of GDAL GPLed. 
> However, since you point out that the 4.3 code is significantly behind the
> 5.0 code (re: floating point) I will work from the 5.0 code.  If possible 
> it would be nice to put the code I extract under LGPL, for which I would
> need the permission of the current copyright holder (you?  Baylor?).  If
> I can't do this, I will still provide the GRASS library as a separate
> package, but I won't be able to distribute it as an integrated part of GDAL.

Well, Baylor did not contribute to GRASS 5 source code since last summer. 
So the current developers are the copyright holders (at least I should
belong somehow to the copyright holders). Anyway, I think we could
discuss to release the GRASS libraries under LGPL. As we want to
modularize the code into packages, this should not be a technical
problem. 
So, GRASS developers: What's your opinion here? Any problems to put the 
GRASS libs under LGPL?
Then it should be compliant to GDAL and reduce barriers.

> > > Unfortunately, GRASS support isn't mandated by Atlantis Scientific, so I
> > > think I will have to go ``off the clock'' while I work on it.
> >
> > Mhhh - maybe we get them interested to support GRASS? Like
> > Imagelinks supports OSSIM?
> 
> Well, it was something to get them to agree to OpenSource OpenEV.  I can't
> see a credible way of convincing them that GRASS support is a worthwhile
> expenditure of their limited resources.  
O.k. If they support OpenEV and this could become a useful GUI for
GRASS once, we have the same result. Of course GRASS is open to
other GUI's as well - no restrictions.

(BTW: http://openev.sourceforge.net/)

> > I do not know details here, but maybe it can be unified again. Then
> > PROJ4 could be included like a plug-in into GRASS and updated easily.
> > As you are interested in datum transforms as well, the wheel should not
> > be re-invented.
> I don't think it is a big issue.  

Thanks for your comments,

best wishes

 Markus Neteler

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'