[GRASS5] GRASS 5.0.0 stable release

[John Huddleston]

Markus,

    I have compiled all the source under src directory for Windows
NT using Cygwin tools.  However, there are areas under the other
source directories that do not build.   I would prefer for you to wait
until I have finished these sections before tagging a stable version.

John Huddleston

----- Original Message -----
From: Markus Neteler <neteler at geog.uni-hannover.de>
To: <grass5 at geog.uni-hannover.de>
Sent: Friday, June 09, 2000 3:12 AM
Subject: [GRASS5] GRASS 5.0.0 stable release


> Dear developers,
>
> some weeks ago we discussed to release GRASS 5.0.0 stable
> (and GRASS 5.1.0 experimental). The easiest way to
> achive this would be to tag all stable modules with
> a "GRASS_5.0.0_stable" tag (or similar).
>
> You will have seen that I did not start this job. Reason
> is that I think we need stable import/export modules
> first before releasing a stable version. A GIS with
> data exchange problems cannot be called stable without
> annoying the users (especially the new users we want to
> invite).
>
> Another problem is that numerous modules exist twice or
> more in modified versions. This confuses everybody.
>
>
> What's the current status?
>  Here is the list of *important* modules we should test and
>  eventually update (complete?):
>
> m.in.e00     - working o.k.
> m.in.ntf     - working o.k. ?
>
> r.in.arc     - working o.k.
> r.in.arctiff - working o.k., but no FP TIFF, limitation: if r.in.tiff
working
> r.in.ascii   - working o.k.
> r.in.bin     - limited to 4bit? (there was some discussion recently)
> r.in.dem     - ?
> r.in.doq     - ?
> r.in.gif     - limited to 256 colors
> r.in.png     - limited to 256 color palette
> r.in.tiff    - on selected platforms working o.k., on Linux/PentiumII
broken
>
> -> r.in.tiff is important and should be fixed
>
> r.out.arc     - working o.k.
> r.out.arctiff - working o.k.
> r.out.ascii   - working o.k.
> r.out.png     - working o.k. (no limitations?)
> r.out.tiff    - working o.k., but no FP TIFF
> -> looking good
>
> s.in.ascii    - working o.k.
> s.in.dbf      - not existing (Andreas?)
> s.in.gps      - not working - any replacement available?
> s.in.grid     - ??
>
> s.out.ascii   - working o.k.
> s.out.e00     - working o.k. ?
> s.out.gps     - not working - any replacement available?
>
> v.in.arc      -|-> which one to keep
> v.in.arc.poly -|   v.in.arc.poly shall fix open rings problem
>
> v.in.arc.pg   - working o.k., but might be updated to v.in.arc.poly code
>
> v.in.ascii    - working o.k.
> v.in.atlas    - ?
>
> v.in.dlg      -|
> v.in.dlg.scs  -|-> we should remove two of them and keep the working
version
> v.in.dlg2     -|
>
> v.in.dxf      -|- fixed yesterday -|
> v.in.dxf2     -|- fixed yesterday -|
> v.in.dxf3d    -|- fixed yesterday -| -> one v.in.dxf is enough!!
> v.in.dxf3d.sh -|----------------   |
>
> v.in.gps      - not working - any replacement available?
> v.in.sdts     - working o.k. ?
> v.in.shape    - working o.k.
> v.in.shape.pg - working o.k., but needs synced with v.in.shape
>
>
> v.out.arc      - working o.k., maybe spaces in output table need to be
>                                adjusted
> v.out.ascii    - working o.k.
> v.out.atlas    - working o.k.?
> v.out.dlg      - working o.k.?
> v.out.dxf      - working o.k.?
> v.out.e00      - not existing, important! (Michel?)
> v.out.idrisi   - ?? keep it?
> v.out.mapinfo  - ?? MapInfo 3.0 code
> v.out.mif      - ?? keep it?
> v.out.moss     - ?? keep it?
> v.out.sdts     - working o.k.?
> v.out.shape    - not yet working, close to be finished
>
> r3.in.ascii  - working o.k.
> r3.in.grid3  - ??
> r3.in.v5d    - ??
>
> r3.out.ascii - working o.k., but not yet sensitive to g3.region settings
> r3.out.v5d   - working o.k., but not yet sensitive to g3.region settings
>
> pg.in.dbf    - working o.k.
>
>
>
> Internal conversion tools:
> r.to.sites  - working o.k.
>
> s.to.rast   -|    more or less working o.k.
> s.to.vect   -|--> all sites modules require a new function to easily
> s.to.rast3  -|    select which attribute shall be converted (in case of
>                   multi-attribute table. Maybe the select function
>                   implemented in s.surf.rst can be modified (there it
>                   imports into quad-tree structure, we need a plain list
>                   only). This shall be a option "field=<number>".
>
> v.to.rast   - working o.k.
> v.to.sites  - working o.k.
>
> r3.to.sites - not written yet
> r3.to.rast  - not written yet (I use g3.region to set one layer, then
>                                r3.out.ascii, then r.in.ascii)
>
> Working import/export modules are alpha and omega of an accepted
> GIS system. So we should take care for this high priority.
>
> Thanks for listening
>
>  Markus
>
> --
> Dipl.-Geogr. Markus Neteler *  University of Hannover
> Institute of Physical Geography and Landscape Ecology
> Schneiderberg 50 * D-30167 Hannover * Germany
> Tel: ++49-(0)511-762-4494  Fax: -3984
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write
to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'


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