[GRASS5] new vector2

[Radim Blazek]

Justin Hickey wrote:
> Radim Blazek wrote:
> > Conversion on disk i.e. rewrite file into native BO on the hard disk
> > will not be automatic.
> 
> Why not? I don't understand why the byte order has to be maintained for
> the file. In most cases, since Grass requires a user to own a file to
> have write access, then I would expect that user to use a local file.
> Also, many users don't even know about the byte order problem. Thus, I
> would suggest that the default behaviour would be to always write in
> native byte order. If you want to provide the option of writing in
> non-native byte order to advanced users, then I would suggest passing an
> argument to the pertinent functions. This may be more work than writing
> a new module, I don't know, but it somewhat hides the low level
> functionality from the user. Again, only a suggestion.

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

> Now a couple of suggestions that you may already know, and I apologize
> if that is the case. I saw that XDR maintains byte order regardless of
> the machine byte order. Since we are already using XDR, maybe we should
> look into using it for the vector format. After all, it is a data
> description language. But you may have already considered this.

In grass5.0 there are already conversion functions for conversion from native
into BE which is now BO for rotable files. I want only modify that function for
new format (very similar to old) and that is almost done. I have considered
XDR shortly and I have found easier to modify old functions. But you  
may be right that XDR is better. I'll look into XDR once more.

> If we do decide to do our own byte swapping routines, then I suggest we
> use a socket function like ntohs() that will do nothing if the byte
> order matches or swap the bytes if they don't match. This seems to be
> the most efficient method to me. Again, this may be what you were
> planning. I just thought I'd mention it.

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

> Please don't take this the wrong way. I'm only trying to understand the
> reasons for some of the features you proposed, as well as making some
> alternative suggestions that could save people some work.

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


Radim



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