[GRASS5] The status of 5.0

[Helena]

Roger ,

I think that it is a well known fact that GRASS4.* and GRASS5.0 is not good
for doing anything with vector data except for some very simple tasks.  So I
would not
rely on GRASS5.0 for any serious vector work.
HOWEVER, Radim has done some really impressive work for vector data for
GRASS5.1 and
while it is still very experimental (certainly not yet ready for routine use)
it would
be well worth to wrap-up GRASS5.0 and release it and move on to GRASS5.1.

Markus it may be worth to give us all a little update on where we stand on
GRASS5.0
and GRASS5.1 (if you are able to tell). We now have GRASS5.0  both release
and experimental
and GRASS5.1 and while there are still bugs in GRASS5.0 and annoyancies
it is quite functional and as far as I can tell, better than ever.

so these are just my comments

Helena


it is Miller wrote:

> I recently had a simple task to complete for a client.  I needed to
> download a county map from the US Census Bureau (TIGER 2000 county line
> map) and extract from that the street pattern for an area of a few square
> miles within the county.  The streets needed to be associated with
> category text that named the street and the whole thing needed to be
> produced in NAD83.  I also needed to transform a DXF map of the same area
> into the same coordinates and send that along with the Census Bureau map.
>
> What should have been a simple task ended up taking several days and may
> still not be done, mostly because several of GRASS's vector modules
> (5.0pre2) didn't work right.
>
> I didn't have time to detail all of the problems as they came up, but I
> can list some of the problems were.  There were probably others that I
> don't remember.
>
> 1. v.in.tig.basic worked, but v.in.tig.lndmk would not import data to a
> latlong location and did not associates category text with lines.  It did
> associated category text with areas, but not with lines.
>
> 2. v.make.subj died with a segmentation fault.
>
> 3. v.merge could not be used because of 2.
>
> 4. v.cutter automatically removed all dead-end streets.  I found no way
> around that behavior.
>
> 5. v.out.shape exported only closed polygons.  I found no way around that
> behavior.  Is that inherent in shape files?
>
> 6. v.proj was useful only because I was able to use the version that I
> rewrote to perform the nad27->nad83 conversion.
>
> 7. v.digit ended on segmentation faults several times while saving a
> finished file.  At one time I found myself abruptly dropped into a shell
> while v.digit was still running.  I still don't know what that was about.
> Removing blocks of lines with v.digit is amazingly slow.
>
> 8. After I removed most of the lines from the original vector file the map
> boundaries in the vector file header were not changed.  I found no way to
> change them other than to edit the boundaries in v.digit.
>
> 9. v.extract did not work.
>
> 10. v.out.ascii gave me a header with a blank line imbedded in it, and
> v.transform would not read that header.
>
> 11. v.transform doesn't work in the context of GRASS database management.
> It required that I export an ASCII vector file in one location and then
> copy that file from it's original location to the dig_ascii element in a
> second location.  The transformed file is produced as an ascii file and it
> has to be imported before it's very useful. That whole process is *way*
> more complicated than it needs to be.
>
> 12. Not a specific module problem, but a general problem:  anything you do
> to change a vector file requires the user to rerun v.support.  Why don't
> the vector modules that trigger that requirement just run v.support
> themselves, as is common in the raster modules?
>
> 13. v.info produced useless results, because the boundaries of the map
> were cited in integer degrees.  The map was well under 1 degree across in
> any direction, so the boundaries were sited with N=S and E=W.
>
> 14. Several of the modules refer to GRASS4 in their user messages.
>
> I know that there has been an effort to upgrade the vector capabilities
> for 5.1, but has a lot of work been done on the vector modules since
> 5.0pre2? If not, then I'd have to say that GRASS's vector capabilities are
> in a very poor state.
>
> Roger Miller
> Lee Wilson and Associates.
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5