[GRASS5] The status of 5.0

[David D Gray]

Markus Neteler wrote:
> 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...
>  
> 

OTOH, few if any other applications provide any facilities for 
processing linework at so raw a level. I find with Arcview 3.x, for 
example that the support via public scripts is about as poor as that in 
GRASS, and poorer for many things because you rely on the encapsulated 
vector engine and the entry points provided by its API. If these are 
faulty you can't do much. There are usually ways to work around problems 
with GRASS, even if you have to support it with home-grown or temporary 
shell scripts or awk etc.

> 
>>4. v.cutter automatically removed all dead-end streets.  I found no way
>>around that behavior.
> 

Maybe v.spag would do the trick. But this is definately buggy on area 
lines. Convert to `line' lines and use this. v.cutter is also more 
problematic with area coverages. But even with lines they are not 
completely bug-free, I find v.spag sometimes fails in that it leaves an 
improper intersection. But - sometimes running it a few times gets them 
all. With this though, it is very slow without block-remove and 
apparently the tool in v.digit is not working.

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

This *should* produce a layer with area coverage, and one with line 
coverage in separate shape-files if you use option `type=both', but I 
can't recall if this functionality has ever been tested. I would think 
it would have been working when the module was originally released, but 
unused functionality tends to drift. Mostly you don't have combined 
layers in GRASS files, even though it supports them, so maybe it is 
another bug. I will be reviewing these export modules before final 
release, though I give the import modules higher priority because they 
really don't work at all.

As to the properties of shapefiles, it is confusing. The spec allows 
each `shape' to have its own type defined independently, but AFAIK this 
is not  yet (and probably now won't be) supported in ArcView, so 
presumably most implementors avoid this. That is why the export for 
GRASS was written to create layers in separate files.

David