Talk:GRASS 6.3 Feature Plan: Difference between revisions
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++.