[GRASS-dev] Re: [bug #4437] (grass) v.in.ascii & 'Vector ASCII Format Specification' differ

GRASS GIS GRASS GIS developer
1

FWD to the list

On Tue, Jul 04, 2006 at 11:21:07PM +0200, Maciek Sieczka wrote:

On Tue, 4 Jul 2006 15:16:21 +0200 (CEST)
Markus Neteler via RT <grass-bugs@intevation.de> wrote:

> am I right that Hamish updated the manual?

There was an update in the v.in.ascii manual. However, there are still
differences between the manual and
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass6/doc/vector/vector.html#ascii
regarding vector feature types.

v.in.ascci is missig the lowercase ("mark as deleted") types. Are they
still supported in Grass 6.1? v.in.ascii man contains more usefull
comments which are missing in "GRASS 5.7/6 Vector Format and API"
description.

I believe both documents should give exactly the same information, to
avoid confussion.

I don't know what is the right, actuall information though.

Maciek

2

"v.in.ascii & 'Vector ASCII Format Specification' differ"
  https://intevation.de/rt/webrt?serial_num=4437

Markus:

> > am I right that Hamish updated the manual?

yes, sorry I should have closed this bug some time ago.
[doing so now]

Maciek:

> There was an update in the v.in.ascii manual.

more to the point, the vector specification linked below was updated to
meet reality.

> However, there are still differences between the manual and
> http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass6/doc/vector/vector.html#ascii
> regarding vector feature types.
>
> v.in.ascci is missig the lowercase ("mark as deleted") types.

I don't think it's a problem, the lower case versions aren't worthy of
mention in the v.in.ascii help page as they represent deleted features
which will be skipped during import.

> Are they still supported in Grass 6.1?

yes, but that just means that they are ignored.

> v.in.ascii man contains more usefull comments which are missing in
> "GRASS 5.7/6 Vector Format and API" description.

the vector format specification is not a tutorial.
which comments do you think should be added to the specification?

> I believe both documents should give exactly the same information,
> to avoid confussion.

yes, the technical info should (& does?) match, but I don't think we
should clutter the specification with redundant examples.

> I don't know what is the right, actuall information though.

no erroneous info should remain. reopen the bug if you see a conflict.

Hamish