<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [OSGeo-Discuss] C++ library for "gridding"</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Yes.<BR>
<BR>
One of the things that excited me when I met with Prof. Chen was how many OSGeo (and close friends) they were working on there and how much work they were ready to submit back to the projects.<BR>
<BR>
--- Original Message ---<BR>
From: "Paul Ramsey" <pramsey@refractions.net><BR>
Sent: Thu 10/19/06 4:50 pm<BR>
To: "discuss@mail.osgeo.org" <discuss@mail.osgeo.org><BR>
Cc: "Chen Rongguo" <chenrg@lreis.ac.cn>, "song" <song7537338@163.com>, "xianfeng song" <song.osgeo@gmail.com><BR>
Subject: Re: [OSGeo-Discuss] C++ library for "gridding"<BR>
<BR>
That's great news! Is this work being done in the GRASS CVS? On a <BR>
branch?<BR>
<BR>
P<BR>
<BR>
On 19-Oct-06, at 4:28 PM, Venkatesh Raghavan wrote:<BR>
<BR>
> Hi All,<BR>
><BR>
> Our colleagues in China have informed that they are<BR>
> working on modifying GRASS commands for data<BR>
> processing and analysis to C-API functions.<BR>
><BR>
> Perhaps, Helana and others would work together<BR>
> or support Prof. Chen in speeding up development<BR>
> of the GRASS C-API.<BR>
><BR>
> Regards<BR>
><BR>
> Venka<BR>
><BR>
> Paul Ramsey wrote:<BR>
>> I'll admit to interest, but can't really help. I would like to <BR>
>> eventually add raster analytics to PostGIS, and hopefully do so <BR>
>> through library linking rather than actually implementing the <BR>
>> features in the core PostGIS code. It would be nice to have a <BR>
>> common library to work on this stuff in.<BR>
>> P<BR>
>> On 19-Oct-06, at 10:09 AM, Helena Mitasova wrote:<BR>
>>> If anybody is interested in developing general library for gridding<BR>
>>> that would include some of the standard methods and at the same time<BR>
>>> allow easy implementation of new functions, I will be happy to help.<BR>
>>> Our original intention with the RST modules in GRASS was to <BR>
>>> create such<BR>
>>> library(including 2D, 3D and 4D) but I had to move on to erosion <BR>
>>> modeling<BR>
>>> before it could be finished - so whatever we have done is now <BR>
>>> scattered in<BR>
>>> the GRASS modules.<BR>
>>><BR>
>>> Helena<BR>
>>><BR>
>>> Markus Neteler wrote:<BR>
>>>> Hi,<BR>
>>>><BR>
>>>> we are working on the SWIG interface to solve that to some<BR>
>>>> extend. A major rewrite is the alternative :-)<BR>
>>>><BR>
>>>> Markus<BR>
>>>><BR>
>>>> PS: See<BR>
>>>> <A HREF="http://grass.gdf-hannover.de/wiki/GRASS_and_Python">http://grass.gdf-hannover.de/wiki/GRASS_and_Python</A><BR>
>>>> <A HREF="http://grass.gdf-hannover.de/wiki/GRASS_and_PHP">http://grass.gdf-hannover.de/wiki/GRASS_and_PHP</A><BR>
>>>> <A HREF="http://grass.gdf-hannover.de/wiki/GRASS_and_Shell">http://grass.gdf-hannover.de/wiki/GRASS_and_Shell</A><BR>
>>>><BR>
>>>> On 10/18/06, Paul Ramsey <pramsey@refractions.net> wrote:<BR>
>>>>> Yes, unfortunately the algorithmic goodness of GRASS is scattered<BR>
>>>>> throughout the program executables rather than consolidated in a<BR>
>>>>> library.<BR>
>>>>><BR>
>>>>> On 18-Oct-06, at 2:37 AM, Rob Agar wrote:<BR>
>>>>><BR>
</FONT>
</P>
</BODY>
</HTML>