[GRASS5] new vector2
neteler at geog.uni-hannover.de
Tue Jan 2 11:50:16 EST 2001
On Thu, Dec 28, 2000 at 07:06:17PM +0100, Radim Blazek wrote:
> Hi again,
> sorry but my last mail was somehow destroyed on the way, here should be
> full text:
> i would like to discuss some problems related to new vector format/library i am working on.
> 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.
The numbers of computers for each platform in use in the world and the
statistic about platforms used by GRASS users heavily differs (due to the
lack of the fully running winGRASS port). The major number of GRASS users
have PCs running Linux (means: little endian).
> 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.
My opinion is to remove that flag: As we don't want even to allow users to
generate non-portable data (in order to avoid later complaints) the vector
data should be always portable.
The other proposal to "mi.ro at iol.it"<mi.ro at iol.it> sounds quite good.
Do the software engineers agree?
> 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.
This proposal sounds good as well. To keep these information in another file
will increase flexibility.
> 4) I want remove bounding box from dig file because it is not reliable. Bounding box should
> be saved in dig_plus only.
O.k. (but I don't know too much about the internal vector formats...)
Thanks for working on that!
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev