[GRASS5] new vector2
Radim.Blazek at dhv.cz
Tue Jan 9 03:06:15 EST 2001
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.
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