[GRASS5] new vector2

[Radim Blazek]

Justin Hickey (and Michel WURTZ) wrote:

> 
> Hi Radim
> 
> Hmmm. I think you missed my question. Maybe if I comment on each of your
> points it will become clearer.

Sorry if my thoughts/english was not clear enough. 
(I will use BO = byte order, LE = little endian, BE = big endian)

> 
> Radim Blazek wrote:
> > - vector file may ben written in big or little endian (no pdp or
> >   other) and byte order is specified in header
> 
> I don't understand the need for this. The vector file should be simply
> written in native byte order, but maintaining this information in the
> header could be useful for checking byte order if it is faster than a
> system check (I don't know what the system check would be).

Vector files may exist in LE or BE. It is about format
of vector file more than about how it is created. BO information
MUST be saved in header because it is the only way how to recognize byte
order of the file. The file may be created on BE machine and used on LE machine
and I don't see any other oportunity how to recognize byte order.

> > - by default new file will be written in machine native byte order
>                ^^^
> I think new should be all files. Please explain why only new files
> should have the native byte order by default.

New files are files opened by Vect_open_new().

I think that two rules above together say the same what you want:
Format is BE or LE + Vect_open_new() opens in native BO = file 
is written in native BO. 

> >   (later add optional byte order for new files by enviroment
> >    variable GRASS_VECTOR_ENDIAN)
> 
> I don't understand the need for this.

We can simly forget this point. That was intended for flexibility only.
I can imagine following situation in some institution:
1 BE machine producing grass files (maybe creates new files by reclassification
   according to attributes in database each day)
25 LE computers used to view/query that files
It would be usefull to write that files on BE machine in LE.  

> > - vector modules (library) will work with both little and big endian
> >   vector files
> 
> I agree with this but the conversion should be handled in the read
> function. The modules should not need to be changed.

Of course - conversion is done by library in memory and modules
don't know about that. 

> > - write new module for conversion little <=> big
> > Conversion module may be used to increase speed if files are not in
> > native order.

What is not clear here? User received files created on BE computer but
he is running LE computer. However he can use that files immediately
(conversion in memory by library function) he want to increase speed.
Conversion module may be used for that.

> > - no auto conversion into native format (read only files, files shared
> >   by more platforms)
Conversion on disk i.e. rewrite file into native BO on the hard disk
will not be automatic. (conversion in memory by library is always done
if native BO is not file BO)

> > - vector written in one byte order (big for example) will be updated
> >   in that byte order (big) even on machine with some other byte order
> >   (little)
> I don't understand the need for these three.

> Michel WURTZ:... so I agree with Radim except for his last
> proposition : autoconversion can be done, but only for a file open
> for update (or read/write)

I am not sure in autoconversion for update. Michel, are there any reasons
don't update in non native BO. (You want to chage category of one line in
20 MB file for example.)





File FORMAT is most important now because other things like autoconversion
or optional writting in non native BO may be changed in future.


Radim

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