[GRASS5] new vector2

[Justin Hickey]

Hi Radim

Radim Blazek wrote:
> I see some problems with automatic conversion: example:
> - mapset  PERMANENT - contains larger (500MB) vectors in BE order
> - mapset  my_mapset     - user's current mapset
> - user works on LE computer
> Now user want view some vectors from PERMANENT:
> - he type: d.vect map=v1 at PERMANENT
> - user cannot write into PERMANENT and he can convert only into
>    v1 at my_mapset  but:
>    - v1 at my_mapset may already exist
>    - user hasn't enough space on disk (hw/sw limit) for that large 
>      file
>    - $DATABASE is completely read only on cdrom for example
>        (I know that it's impossible now and you need write access but >         it should be changed I think)
>    - if conversion into v1 at my_mapset was succesfully done the command
>       d.vect map=v1 at PERMANENT cannot go on because map is now
>       v1 at my_mapset
>    - after running d.vect on all vectors in PERMANENT your $DATABASE
>        doesn't occupy original 500MB but 1GB

Ahh. OK I see what you are thinking now. I agree that this would be
dangerous. However, this is not the type of automatic conversion I was
thinking about. Here is an example:

 - user downloads a BE file (v1) from the internet into own mapset (ie
   has write access)
 - user is using a LE machine
 - user tries d.vect v1
 - read function in vector library detects wrong BO
 - message appears saying something like "file will be converted ...
   please wait"
 - read function reads in file, swaps bytes, and then overwrites file v1
   (BE file no longer exists)
 - read function passes swapped data to d.vect

Thus, the automatic conversion will only overwrite a file. It will never
copy it. The only problem is a possible lack of disk space for a
temporary file to perform the conversion. However, I'm not sure if we
would need to have a copy on disk. Perhaps grass reads the whole file
into memory, I don't know. But if we do need to create a temporary copy,
then we provide a check for disk space and if there is not enough, we
skip the write out phase and only swap the bytes in memory.

In other words, the automatic conversion will only occur if the file is
writable. Thus, the read function will have to test if the file is
writable before it tries the automatic conversion.

For writing a file, we simply write out the data in native BO since
grass can read either BO. Thus, I still do not see a need to write files
in non-native BO.

> Yes but I don't see some ntohd/f/() - double, float and because it is 
> defined: unsigned long int htonl(unsigned long int hostlong);
> I am wory that it doesn't convert between various type lengths.
> long may be 4 or 8 bytes and we need conversion to/from 4 bytes

OK, I thought they were more standard than that. I just feel that using
system functions is usually more efficient than using our own.
Unfortunately, they must be standard to use them. :-(

> All comments/suggestions/criticism  are welcome because that is the 
> only way how to keep quality in GPL SW.

Agreed. It's just sometimes the tone of my writing is mis-interpreted so
I tend to warn people about it. :-)

Talk to you later.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

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