[GRASS5] new vector2

[Eric G . Miller]

On Thu, Dec 28, 2000 at 07:06:17PM +0100, Radim Blazek wrote:
> 1) Little or big? Dig files are written (version 4) in portable vector
> format which is big endian byte order (note for David: I was wrong in
> my last mail).  On little endian machines (i386 for example) byte
> order of each number must be changed. My test with d.vect says that
> such conversion takes 8% of time.  That is long time. The question is
> if we should keep big endian or change to little endian. Exists any
> statistic about platforms used by GRASS users? Maybe ftp server log
> for binaries downloads could help, is it somewhere on the Web Markus?
> Somebody knows any web page with informations about numbers of
> computers for each platform in use in the world? Any idea is welcome. 

As was mentioned, maybe it is possible to always write data in native
format, but perform a byte swap conversion on read if necessary.  It
would require a bitfield or such to specify endianness.  I don't know if
this would cause more headache than it's worth, since partial
updates/writes would also need a conversion check.  Maybe it's just
better to choose one and live with the conversion slow down.

> 2) It is possible to compile version 4 vector library with #define
> NO_PORTABLE  and all vector files will be written in native format
> instead of portable.  Speed on little endian machine is increased but
> such non portable vector files may be not be used on big endian
> computer then.  Somebody ever used such option?  Should be this
> feature keept in new vector format/library? My suggestion is do not
> support that option and be sure that all vector files in the world are
> always portable.

I agree with dropping it.

> 3) I want move header information (ORGANIZATION, DIGIT DATE, ....)
> from dig file into separate dighd text file - separate coordinates
> from other informations.  Idea is taken from
> documents/grass6vector_api/vector/head.html.  I expect some changes in
> header fields in future (projection, units maybe) and changing dighd
> text format will be easier than changin binary file. This should also
> prepare GRASS better for using OSVecDB where coordinates will be saved
> in DB table - I am not sure here.

Sounds good to me.  I'd like to get full tabular attribute data
supported in any new GRASS vector format.  I think it is very important
to have such a thing.  I guess it should key in on an ID pairing
point/line/area ID's to separate point/line/area tables.  I think this
is most important (puts the "Information" in GIS!).  I wouldn't worry
too much about OSVecDB at this point since it's not clear where that
might lead.

> 4) I want remove bounding box from dig file because it is not
> reliable. Bounding box should be saved in dig_plus only.

Can't comment on this...

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'