[GRASS5] Re: [GRASSLIST:2717] How to get topology of area edges
blazek at itc.it
Tue Mar 2 08:08:19 EST 2004
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/.
More information about the grass-dev