Talk:GRASS 6.3 Feature Plan: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
My idea is to tighten developers and they features with release schedule. There is no point to list feature which nobody will implement or will not implement till THIS release. This should be a '''PLAN''' and not a '''wish list'''. This should be for non-abstract stuff, but for tasks that ''can'' and ''should'' be done before target release. Users then could look at this page to see - whats coming next, which bugs would be fixed etc.
My idea is to tighten developers and they features with release schedule. There is no point to list feature which nobody will implement or will not implement till THIS release. This should be a '''PLAN''' and not a '''wish list'''. This should be for non-abstract stuff, but for tasks that ''can'' and ''should'' be done before target release. Users then could look at this page to see - whats coming next, which bugs would be fixed etc.
[[User:MarisN|MarisN]] 15:45, 4 August 2006 (CEST)
[[User:MarisN|MarisN]] 15:45, 4 August 2006 (CEST)
There are already export modules for the VTK dataformat in grass,
so there is no need to implement this is gdal/ogr.
* r.otu.vtk
* v.out.vtk
* r3.out.vtk
are doing the job very well.
And the output files of these modules are the standard input format for ParaView.
And to patch ParaView to read directly from grass database should be a wish
for grass7. Because you need to implement this functionality in VTK, which
is the base for ParaView. And you need to handle the grass lib functions
within C++.

Revision as of 18:43, 14 August 2006

My idea is to tighten developers and they features with release schedule. There is no point to list feature which nobody will implement or will not implement till THIS release. This should be a PLAN and not a wish list. This should be for non-abstract stuff, but for tasks that can and should be done before target release. Users then could look at this page to see - whats coming next, which bugs would be fixed etc. MarisN 15:45, 4 August 2006 (CEST)

There are already export modules for the VTK dataformat in grass, so there is no need to implement this is gdal/ogr.

  • r.otu.vtk
  • v.out.vtk
  • r3.out.vtk

are doing the job very well. And the output files of these modules are the standard input format for ParaView.

And to patch ParaView to read directly from grass database should be a wish for grass7. Because you need to implement this functionality in VTK, which is the base for ParaView. And you need to handle the grass lib functions within C++.