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