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

[Radim Blazek]

On Thursday 26 February 2004 08:03, Hamish wrote:
> > > > 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.

I don't like vector/$MAPNAME/ascii, vector/$MAPNAME/ should be used only for
binary format, I think. You are right that old scripts cannot read new 
format anyway. What about vector_ascii/?
v.out.ascii has already -o flag, the same could have v.in.ascii.

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

I agree that number of coordinates is something redundant, on the other hand,
it is form of check and makes the format more 'robust'.

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

This I don't understand.

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

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

I think that v.in.ascii works without 'WEST EDGE' even in 5.0. 
In 5.7 is always calculated when topology is built and cannot be changed manualy. 

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

For me, all these changes are not enough important. I am not against,
but I'll not do that. Go on and do that if you want. 
I would only oppose ascii in vector/$MAP/.

Radim

Radim