[GRASS5] grass5.1 directories proposal

[Markus Neteler]

Hi Andreas,

On Fri, Jan 05, 2001 at 05:53:41PM +0100, Andreas Lange wrote:
> 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)

Well, something like that I had in mind :-)
 
> 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

-> especially here a new feature: extend the location settings of required
   (coordinates)

> 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.
Why not having wrappers:

 - r.import, r.export
 - v.import, v.export
 - s.import, s.export

calling the required module? They should auto-detect the format by file
extension or whatever.
 
> 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.). 

That would be great. Something like graphical GUI programming for
non-programmers.
  
> 
> 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.

You think put everything into lib/-top-level? Then the directory names
should be more explanatory than now (at least some like "D"/"display" are
very confusing).
 
> ..
> >             /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. 

That's true for external libs. But we need included libs for libs managed in
GRASS CVS. Another idea is that many libs are non-standard for most systems.
So users have to collect all these libs manually, a boring job. Perhaps
there is something else between managing them in GRASS CVS 8which in fact
doesn't make much sense if the lib is managed elsewhere) and leaving the
users "alone".
 
> ..
> > 
> >         /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 ...)

Ok, why not. At least the number of modules should be reduced... 
But: We need to keep in mind that we want to modularize the monolithic GRASS
system into packages. This should be somehow reflected by the source code
organization.

> ..
> > 
> > #now topic-oriented packages follow:
> > 
> > # vis-package:
> >     /visualization
> >         /nviz
> >         /sg3d
> >         /xganim
> 
> /viz is shorter IMHO, or is there a copyright?
Obviously yes:

http://tess.uspto.gov/bin/showfield?f=doc&state=ifec08.2.32
(and others). Search list here:
http://tess.uspto.gov/bin/showfield?f=toc&state=ifec08.1.1&p_search=searchss&p_L=50&BackReference=&p_plural=yes&p_s_PARA1=&p_tagrepl%7E%3A=PARA1%24LD&expr=PARA1+AND+PARA2&p_s_PARA2=VIZ&p_tagrepl%7E%3A=PARA2%24COMB&p_op_ALL=AND&a_default=search&a_search=Submit+Query&a_search=Submit+Query

Maybe we can ignore these TMs?
 
> > 
> > 
> > #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.

I am not sure because only a few people want g3d. So we should keep the core
package size as small as possible.
  
> > 
> > #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. 

If possible, please send a draft proposal here how such a system can be set
up (I simply don't know and want to learn).

> 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' (???)

That's close to my idea :-) We need nice, short, explanatory names...
 
> > -----------------------------------------
> > 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.
O.k.

> > 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?

Yes, no idea. We need to work out in details if we really want to change it.
Maybe we concentrate on other problems first. 


Thanks for your comments,

 Markus

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