[GRASS5] grass5.1 directories proposal

[Andreas Lange]

Hi Markus,

i think that there are two different things mixed together with the
approach you propose:
- categorizing the modules by functionality/model integration/data type
- source directory structure.

The source directory structure should not be too important and should
confine to the usual standards.

But i feel that we need to categorize the modules by:
- functionality
- model integration (core, closely coupled model, loosely coupled
model/simulation, external model)
- data they operate on (input)
- data they generate (output)

This would faciliate the use of automatic interface generators (in
conjunction with the xml-description) to generate a GUI and to simplyfy
the user interface. 

I can imagine a setup for import/export as follows:

A file-browser that shows the GRASS database, locations, mapsets and the
home dir of the user
Right-mouse click activates a menue that shows the functions to operate
on the selected data/file, e. g. :
raster in mapset:
- display
- analyse
- interpolate
- resample
- project to...
- export/convert
(every function would require a sort of automatic log-in to the GRASS
location/mapset before executing the function/opening the window) 

tiff file in home directory:
- import to new location (from world file)
- import to existing location
etc. etc. 

With a setup similar to this the import/export could be made much
simpler without rewriting every module and/or writing a monolithic
"exchange" program. Every programmer could concentrate on the file
format he knows best.

I belive that not the number of modules is important, but the way they
are integrated within GRASS. If we develop a more flexible (and
user-configurable) way of adding modules to the GUI (tcltkgrass etc.),
we can even increase the number of modules without confusing the user.
E. g. we could change tcltkgrass so that the user can modify the menues
himself and provide different pre-defined menue configurations (imagery
work, database link, raster-only, vector-only, raster-and-vector etc.). 
 

Some additional thoughts on the directory proposal:

Markus Neteler wrote:
..
>             /formats
>                 /dlg    : library to manage DLG files
>                 /sdts   : library to manage SDTS files (was: src.contrib/..)
>                 /sgirgb : library to manage SGIs RGB-format (was: libimage)

here one level would be ok, e.g. /lib/dlg, /lib/sdts etc.

..
>             /plugins      (keeps external libs)
>                 /bwidget : tcl/tk extra library
>                 /gdal    : GDAL raster lib
>                 /gdbm    : database support for GRASS (or Berkeley DB)
>                 /libgrassio: GRASS import/export lib from Frank Warmerdam
>                 /proj    : PROJ 4.x library from Frank Warmerdam et al.
>                 /shapelib: SHAPE support lib from Frank Warmerdam

external libs could be provided in external location (/usr/local/lib
etc) if they are unchanged. 

..
> 
>         /exchange    (import/export modules)
>             /misc
>                 /m.e00
>             /raster
>                 /r.arc  (contains r.in.arc/r.out.arc)
>                 /r.ascii
>                 /r.tif
>                 ...
>             /scripts    (move import/export scripts here from global scripts)
>             /sites
>                 /s.ascii
>             /vector
>                 /v.ascii
>                 /v.shape
>                 ...
> 

I vote against a new import-export directory. 
Why not keep the modules in the original raster/vector/sites directory
and flag the functionality (import/export) by another system
(xml-description, textfile somewhere ...)

..
> 
> #now topic-oriented packages follow:
> 
> # vis-package:
>     /visualization
>         /nviz
>         /sg3d
>         /xganim

/viz is shorter IMHO, or is there a copyright?

> 
> 
> #hydro-dem-erosion-package:
>     /hydrology_dem
>         /raster
>             /raster_hydro_dem_modules
> 
> #image-processing-package:
>     /imageprocessing
>         /imagery
>             /image_proc_modules
> 
> #database-package:
>     /database
>         /generic (db.* driver improved by Radim)
>         /oracle
>         /postgresql
> 
> 
> #G3D-package:
>     /g3d  (was: src.contrib/GMSL/g3d)
>         /general3
>         /raster3
>         /scripts3
>         /sites3

This could go into a dir 3d-raster or raster3d in the main source
directory also. If the library is in the core/basic/main distribution,
the modules should go there too.
 
> 
> #extended-raster-package:
>     /raster_extended
>         /fuzzy_logic
>         /...
> 
> #interpolation-package:
>     /raster
>         /r.bilinear
>         /...
>     /sites
>     /vector (was: mapdev)
> 
> #simulation-models-package:
>     /raster
>         /casc2d
>         /topmodel
>         /erosion
> 

Again i would vote for another system to track the functionality
(interpolation, ...). See above. 

The core modules should go to :
  core/raster
  core/vector
  core/sites etc.

more loosely coupled modules could go into:
  model/'modelname' (fuzzy_logic, ...)
  sim(ulation)/'simulationname' (casc2d, topmodel, erosion, wildfire)
  ext(ernal)/'nameofexternalmodule' (???)

> -----------------------------------------
> Note: Useful modules from src.contrib section shall be merged into
>       directory structure.
> 
> Questions:
>   - core-package: shall we move the "/lib/plugins" to "/plugins" ?
>   - shall we keep the unused directory?

The unused directory should be keept with the old GRASS5.0 code, but is
not needed for the new GRASS5.1 tree.
 
> Proposal:
>  - the number of import/export modules scripts needs to be heavily reduced.
>    At time there are 92 tools for import/export/tape analysis...
> 
>  - Idea: The raster database structure should be changed to the G3D
>    structure: all files related to a raster map should go into one
>    directory. Currently many files are spreaded in many directories.
>    An example for the G3D data structure can be found here:
>    http://www.geog.uni-hannover.de/grass/grid3d/index.html (sample dataset)

This is very reasonable, but how to keep compatibility to the old raster
files?

cu,
Andreas
-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



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