[GRASS5] grass5.1 directories proposal

[neteler]

Happy new year to all developers!

As grass5.1 shall take off as soon as possible, we should start the
directory structure debate. My draft proposal is looking like this:

grass51/

# core includes libs, docs, import/export and basic modules:
    /core (the GRASS basic package)
  /include : global include files

  /lib (read src/libes/README for further design comments)
      /bitmap : bitmap library for X Window Bitmaps
      /btree : binary tree library
      /coorcnv : coordinate conversion and datum support library
      /datetime : DateTime library
      /dbmi : database management interface database drivers
      /display : display lib (was: D/ )
      /drivers
    /cell : CELL driver (was: display/)
    /digitizer: raw library for general digitizer support
    /htmlmap: HTMLMAP driver
    /paint : paint library (from paint/ )
    /xdriver: XDRIVER
      /dspf : G3D display files library
      /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)
      /fonts : hershey fonts
      /front.end : cmd/inter frontend
      /g3d : G3D raster volume library
      /geom : geometrical calculations... (will be detri)
      /gis : main GRASS library (remove import/export routines)
      /gmath : generic mathematical functions (to BLAS/LAPACK libs)
      /ibtree : integer clone of btree lib (needed?)
      /icon : icon library (required for PS/Paint)
      /imagery : imagery library including image3 extra library
      /init : GRASS startup (was: src/general/init/ )
      /java : GRASS JAVA support (was src.garden/grass.java/ )
      /linkm : linked list memory manager
      /lock : locking mechanism for GRASS monitors and files
      /ogsf : ported gsurf library (required for NVIZ)
      /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
      /raster : GRASS raster library
      /rowio : row in/out library
      /rst_gmsl : library for interpolation with reg. splines w.t.
      /segment : segment library
      /sites : GRASS sites library (extract from gis/ )
      /testsuite : testsuite
      /vask : Curses management library
      /vector : GRASS vector library
    /Vlib : portable GRASS vector functions
    /dig_atts : library to read and write from attribute files
    /diglib : more GRASS vector functions
    /georef : Imagery Georeferencing Programs
    /libes : transformations from one coord. system to another

  /docs
      /docs
      /html
    /html_docs_go_here

  /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
    ...

#now a set of basic modules follows:
  /display
     /basic_modules_go_here

  /general
     /basic_modules_go_here

  /gui
      /python
      /tcltkgrass

  /misc
     /basic_modules_go_here

  /paint
      /paint_modules_go_here

  /postscript
      /ps_modules_go_here

  /raster
      /basic_modules_go_here

  /sites
      /basic_modules_go_here

  /vector
      /basic_modules_go_here

#now topic-oriented packages follow:

# vis-package:
    /visualization
  /nviz
  /sg3d
  /xganim

#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
      
#extended-raster-package:
    /raster_extended
  /fuzzy_logic
  /...

#interpolation-package:
    /raster
  /r.bilinear
  /...
    /sites
    /vector (was: mapdev)

#simulation-models-package:
    /raster
  /casc2d
  /topmodel
  /erosion

#more?

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

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:
   Bereich Geographie – Naturwissenschaftliche Fakultät – Leibniz Universität Hannover (sample dataset)
   
Comments are welcome!

Markus

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

[Justin_Hickey]

Hi Markus

This looks like a great start, but I have a few comments.

Markus Neteler wrote:

            /ogsf : ported gsurf library (required for NVIZ)

If this is required only for nviz, then it should be stored under nviz.

        /libes : transformations from one coord. system to another

I think we should call this "lib" for consistency.

        /exchange (import/export modules)

Hmmm. I think we should associate the name of this directory with data.
Something like /dataExchange or /dataPort. Exchange just doesn't seem
clear to me.

Questions:
  - core-package: shall we move the "/lib/plugins" to "/plugins" ?

No, since they are libraries they should be under /lib.

  - shall we keep the unused directory?

If it contains old code, then no. If it contains code that could
possibly be used in a future release, then we should rename it. Perhaps
something like /futureCode or /newModules or some other pertinent name.

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)

I can't really comment on this one since I am not familiar with G3D, but
from a directory management point of view, it sounds good.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

[Eric_G_Miller]

On Thu, Jan 04, 2001 at 11:49:06AM +0700, Justin Hickey wrote:

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

I can't really comment on this one since I am not familiar with G3D, but
from a directory management point of view, it sounds good.

There might be other benefits to using the g3d format. It uses a tile
based system which is (a) more likely to compress better than an entire
row [less variability]; (b) for fp data random seeks/reads/writes
for cells aren't really supported/possible due to keeping separate NULL
file in sync; and (c) is more efficient for high
resolution display and is easier to generalize to current cell
resolution.

The library code for modules would have to make this transition
transparent and would have to be able to emulate the row based access
methods unless we want to rewrite every raster and imagery module! The
inefficiency of translating tile access to row access could be
substantial (writes would seem most difficult since some kind of caching
may be needed).

--
Eric G. Miller <egm2@jps.net>

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

[Andreas_Lange1]

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@Rhein-Main.de - A.C.Lange@GMX.net

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

[Justin_Hickey]

Hi Andreas

Andreas Lange wrote:

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.

Interesting idea.

..
> /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.

That would be fine if we only have a few, but if we have more in the
future, I'd prefer to group them together. Just my opinion though.

..
> /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.

But these are under our source tree. Are you suggesting we don't offer
these libraries and have the user install them separately?

Just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

[Radim_Blazek2]

Andreas Lange wrote:

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 agree.

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 ...)

I agree.

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.

I agree.

The unused directory should be keept with the old GRASS5.0 code, but is
not needed for the new GRASS5.1 tree.

I agree.

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

New vector?:
MAPSET/vector/vector_name/coor (binary file) - (former dig/)
                         /head (text file) - (head of former dig/)
                         /topo (binary file) - (former dig_plus)
                         /cats (text file) - (former dig_cats)

Please suggest better file names (short).

Radim

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

[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~%3A=PARA1%24LD&expr=PARA1+AND+PARA2&p_s_PARA2=VIZ&p_tagrepl~%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:
> Bereich Geographie – Naturwissenschaftliche Fakultät – Leibniz Universität Hannover (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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

[Andreas_Lange1]

Hi 2 all,

my first draft for a module categorization is not ready, but i hope to
work on it in the next days. I think there is still the need for more
discussion.

Markus Neteler wrote:

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.

This would be another method of importing. But i have no idea how much
work the format-autodetection is. But i think many things can not be
automated, but need user input, as there are many different possible
imports (to new location, encompass location to new data, import to
location and encompass data to extent of location 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.

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).

The directory names should be really more explanatory than "D". And if
there is a categorizing this is ok for me. I think that the library
source code directories are only important to programmers, so we should
not waste too many thoughts on them.

> ..
> > /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".

I can see no real difference between libraries that are developed for
grass and managed in CVS and libraries developed externally but then
checked in to CVS. If they are managed in CVS (and maybe partially
changed for grass) they are no longer external IMHO.

There should be another method of including those libraries, but i don't
know how. Any further ideas?

> /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~%3A=PARA1%24LD&expr=PARA1+AND+PARA2&p_s_PARA2=VIZ&p_tagrepl~%3A=PARA2%24COMB&p_op_ALL=AND&a_default=search&a_search=Submit+Query&a_search=Submit+Query

Maybe we can ignore these TMs?

As its just a directory name we could ignore the trademarks. But i am no
lawyer.

I want to rise another question:
Is the separation of the raster/vector/sites/imagery core modules really
feasible and/or desirable?
It is my personal belief that a) building shared libraries and linking
the modules to them and b) making the specialized models (hydrology,
simulations etc.) optional modules will be the more realistic approach.
If you have arguments why we should split the core package into
packages, please try to convince me, i am open to any arguments.
The size of the binary package will shrink down dramatically with shared
libraries. I can not imagine how useful work can be done e. g. with only
the vector modules or only the raster parts. The libraries depend in
many cases on one another and there are even modules from one realm
(r.*, s.*, v.*, i.*) that depend on libraries from the other or provide
functionality for the other part (e. g. some site modules are some sort
of vector functions). And it will be IMHO very confusing to explain to
the user that he has to install another package in order to overlay a
single vector onto his raster data.

cu,

Andreas

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

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