[GRASS5] Re: [GRASSLIST:2717] How to get topology of area edges

[Hamish]

> > > >  I'm attempting to read GRASS's ascii vector output into a
> > > >  graphics
> > > > display program that I'm writing...  I produce this output (with
> > > > v.out.ascii) from a valid GRASS vector layer containing area
> > > > polygons. What appears in the resulting data file is a line that
> > > > denote an area and a number of points followed by these
> > > > points... i.e.
> > > >
> > > > A 4
> > > > easting northing
> > > > ...
> > > > easting northing
> > > > ...
> > >
> > > note that should read
> > >
> > > A 4
> > >  northing easting
> > >  northing easting
> > >  northing easting
> > >  northing easting
> > >
> > > as long as the file format (and vectors in general) is changing
> > > for 5.7, is it too confusing to switch to x,y? maybe with an added
> > > header line"FORMAT: X,Y" or something? Now would be the time if we
> > > are ever going to fix that...
> > 
> > "FORMAT: X,Y" is good idea, but still could make much confusion,
> > there are many scripts working with ascii format.
> 
> I agree about the creating confusion. BUT the existing way creates
> confusion too. Question is, which way causes LESS confusion and is
> easier to work on in the future?
> 
> Will those 5.0 scripts not break & need updating to work with the new
> 5.7 ascii format anyway?
> 
> 
> > Maybe another directory?
> 
> Moving things into the vector/ directory just cleaned things up, do we
> 
> really want to go back and add more clutter?

[replying to myself..]

... maybe make an "ascii" file in the new vector/$MAPNAME/ directory for
the changed format. Putting new 5.7 data in dig_ascii/ seems wrong.
That should be reserved for old GRASS 5.0 files.. Otherwise we never get
away from the dig_* directory clutter even when 5.0 is history.

This would allow us to change the file format more drastically too: e.g.
do we really have to specify how many vertices will follow each feature?

L 341
 y1 x1
 y2 x2
...
 y341 x341

is a pain to do; r.in.poly format is much easier to deal with for making 
quick & simple custom import filters, as I do for Matlab->GRASS..

What about:
A 341
 x1 y1 double_1a double_1b "label_1a" "label1b"
 x2 y2 double_2a double_2b "label_2a" "label2b"
...
 x341 y341 double_341a double_341b "label_341a" "label341b"


seems more logical to me than a huge att table at the end.....??


WEST EDGE:  etc  are also a pain to have to figure out. Couldn't we do this
in code? Or maybe that is useful for setting up new mapset regions..

maybe meta-data could move to "vector/$MAP/hist" too? Maybe not, self-
contained in one file can be good I guess.



just some ideas,
Hamish