[GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask]

Thu Mar 15 10:03:18 EDT 2007

Hi,

Am Mittwoch, 14. März 2007 08:02 schrieb Hamish:
> Glynn Clements wrote:
> > Is there an expected timeline for 7.x?
>
> That is entirely up to the fine folks on this list; I would guess that
> when the time comes, we know & we do it. Maybe then is now? I would not
> object to it happening as soon as the SVN server is up and running. (no
> technical reason for that, just a nice time for it to happen)
>
> my wishes for the GRASS 7.0.0 release
> * native MS windows fully stable and equal
>   - worthy of a major point release, if simply for the PR value
> * wxPython fully implemented for all GUIs
>   - no or minimal Tcl, for a consistent user experience
>     keep Tcl as non-default, optional "oldgui" ??? (answer that later)
> * no more interactive d.*, xterm GUIs, etc
> * centralized $MAPSET/raster/$MAPNAME/element
> * more?
>   - would a new raster format mean a new major point? or ok as long
>     as lib fns were backwards compatible with the old format? too much
>     to ask to support both? or r.convert module, like G6's v.convert?
>
> the raster format changes could mean a time of dual branch development
> like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
> working on 5.0/5.4. Markus may have some stern words about that. ;)

If we plan to implement a new raster format we should consider to merge the 
raster and g3d library. 
AFAICT the g3d library can offer good raster support. 
The core library has to be extended to support more data type (for now only
float and double are supported) but the implemented tile algorithm is capable
to support row wise data storage (in this case the tile has the size of a row)
as well as any tile size data storage. Each tile will be compressed and
stored. It also provides a cached data access, to get single values. In this
case the tile which contains the value at position x, y, z is loaded into the
memory. The tile cache size limits the number of tiles which are kept in 
memory.

In non cached data access mode the tiles are accessed in a specific order
(eg.: for raster data in increasing row numbers).

IMHO for backward compatibility the "get/put row" functions 
can be easily emulated in creating 3d volume maps with only one depth and with 
a tiles size of one row.

But i would suggest to implement a new raster API to have access to raster 
tiles of different sizes. Maybe we can name those functions G2d_* ... and the
G_*_row stuff are wrappers around the new API? In this case we are able to
provide the functionality of the raster, row io and segment library with one 
API (G2d_*).
The raster maps will be stored as g3d maps with the g3d metadata management
($MAPSET/raster/$MAPNAME/element). Many redundant general and raster/raster3d
modules have to be merged.

If the metadata management of raster and raster3d data is merged, it will be 
easier to implement time series support for booth map types.

Just my two cent
Soeren

>
> > If so, does that signify a point at which fundamental changes to the
> > graphics architecture can commence?
>
> I guess we could restate the question as do we want/need a GRASS 6.4
> stable release, or should we continue in devel mode all the way to 7.0?
>
> (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a
> nice milestone once winGrass is usable. If no 6.4 is planned, then there
> is no need for a new SVN branch for 7.0 devel, we just continue with
> 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
> cull away)
>
> [*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
> we shouldn't abandon them. I guess they will be the day-to-day GUI
> during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
> ??
>
> The 6.x problem is not with fundamental changes to the underlying
> architecture, that is wide open during a development minor version, and
> AFAIAC go for it. The issue is changing the user interface to the
> extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
> longer works with "GRASS 6". So we are free to "get our ducks in a row"
> now, and we should do that, we just have to make an effort to minimize
> user pain as we go.
>
> When it is apparent that we have reached the point where the effort to
> maintain backwards compatibility is a big time+energy sink, we trigger
> the start of GRASS 7 development, without regret.
>
> > If not, i.e. if i.ortho.photo *has* to continue to work until such
> > time that someone sees fit to write an alternative (if that ever
> > happens), then the graphics architecture will forever be limited to a
> > Tek4105 emulation, and I may as well give up now.
>
> I think we can, today, clearly make a list of things that will not be in
> GRASS 7. Firstly a list of lib fn families, and secondly a list of
> modules. Presumably replacements GUIs for missing modules will come
> on-line in proportion to the demand for module's functionality.
>
> > IMHO, I don't think that we can wait forever for decent graphics. The
> > biggest danger is that the "you can't remove that because someone
> > still uses it" problem will end up solving itself when no-one actually
> > uses GRASS any more. I'd prefer people to set achievable goals than to
> > insist on having everything and ending up with nothing.
>
> We just have to call it GRASS 7. As that is just a number it is simple to
> change. No need to artificially slow down development to keep 6.x alive.
> e.g. People with need for GRASS 5.4 can still use that if they want,
> without loss of functionality, new devel switching to GRASS 6 hasn't
> changed that. And GRASS 7 devel won't hurt those who still want to use
> GRASS 6. So no worries.
>
>
>
> Hamish
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev