[GRASS5] The status of 5.0

[Markus Neteler]

On Wed, Mar 20, 2002 at 01:11:54PM -0700, Roger 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.

Roger,

I can really understand your situation - sometimes it's really annoying with
vector data in the current GRASS 5.0 version...
 
> 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.

.. added to RT.
 
> 2. v.make.subj died with a segmentation fault.

Please file a more detailed report:

http://grass.itc.it/bugtracking/bugreport.html
 
> 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.

Please write also to:
http://grass.itc.it/bugtracking/bugreport.html
-> mark area as "wish"

> 5. v.out.shape exported only closed polygons.  I found no way around that
> behavior.  Is that inherent in shape files?

Hi David...

> 6. v.proj was useful only because I was able to use the version that I
> rewrote to perform the nad27->nad83 conversion.

Roger, maybe you can share the code with us? Datum transform is a
highly wanted issue...

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

I never had this problem. Please another bug with platform etc.

> Removing blocks of lines with v.digit is amazingly slow.

...a wish?

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

No idea, maybe v.support should do that.

> 9. v.extract did not work.

v.extract was fixed by alex Shevlakov in 12/2001. It works in pre3.

> 10. v.out.ascii gave me a header with a blank line imbedded in it, and
> v.transform would not read that header.

As far as I used v.transform, it doesn't need a header. From
http://grass.itc.it/gdp/html_grass5/html/v.transform.html
"An example of the pointsfile file: 

 1       1       589000   4913000
 1       17000   589000   4930000
 17000   17000   610000   4930000
 17000   1       610000   4913000
"

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

I didn't try your way, but rectifying e.g. xy-DXF files *inside* a
projected location is possible. So you may try to import the vector
file directly into the projected location and proceed from there.

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

I added this feature to some modules, a good idea to continue on that.

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

Sounds like an rather easy fix - please also to
http://grass.itc.it/bugtracking/bugreport.html

> 14. Several of the modules refer to GRASS4 in their user messages.

Quite important to know, which. Please list them.

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

I fear the latter. We should get at least a basic 2D vector engine
working, before calling it "stable".

Markus