[GRASS5] grass5.1 directories proposal

[Andreas Lange]

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

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