[GRASS5] Maximum number of categories

[Radim Blazek]

On Monday 26 April 2004 12:49, Paul Kelly wrote:
> Hello Radim
>
> On Mon, 26 Apr 2004, Radim Blazek wrote:
> > The 'coor' format was designed for 5.7 without any compromises.
> > AFAIK, the suggested change (number of cats 1 byte -> 2(4) bytes)
> > is the only required.
> > I know that 5.7 is devel version and it is devel version exactly
> > for these reasons. However, we (including me, I think) said
> > few times that 5.7 can be used already for work.
> > To have support (reading) for both 5.0 and 5.1 'coor' formats
> > means only few rows of code.
> >
> > I think that I'll do both steps of the change (i.e. first reading,
> > then writing) without long delay but in 2 cvs commits.
> > The problem may appear only for groups using more installation
> > of GRASS and sharing the data. In that case, they can either:
> > 1) make first update for reading on all machines and then
> >    also for writing
> > or
> > 2) stop the work for a while and update all installations directly
> >    to reading+writing.
> > Is it OK?
>
> I think after you add the code for reading then you could release GRASS
> 5.7.0 (with code from 5.3 copied in to make it usable of course). Then the
> code for writing will only be in the development CVS versions but if people
> have problems reading files you only have to tell them to make sure they
> are using 5.7.0 (rather than checking the date of the snapshot they used).

I prefere not to release 5.7.0 with a format which has known limits.
I want also replace shapefile+postGIS by OGR before 5.7.0 (change in the format).
I'll return to original plan to wait a while between code for reading and writing.
I think that it is almost the same to say that they have to use 5.7.0
or cvs older than some date.

> I also think you should use the opportunity to expand the other two items
> you mentioned in the binary coor formats to cover all possibilities for
> expansion for the forseeable future, if you think there is the slightest
> chance it might be needed.

Currently elemets are written as:
1 byt - header:
        0 bit: 1 - alive, 0 - dead
        1 bit: 1 - categories, 0 - no category
        2-3 bit: store type
        4-5 bit: reserved for store type expansion
        6-7 bit: not used

1 byte - number of categories (if categories are present)
n_cats * 2 bytes - field (2 bytes per field)
n_cats * 4 bytes - cats (4 bytes per cat)

4 bytes - number of coordinates (linear elements only)
n_coor * 8 bytes - x coordinates
n_coor * 8 bytes - y coordinates
[n_coor * 8 bytes - z coordinates]

That means 4 bits (+1 reserved) for element type i.e. maximu 32 types
and we have currently 8 types defined including not used face, kernel
and volume. Possible new type could be Polygon but it will not be 
possible to read files with polygons in older version anyway.
So I think, that first byte header may be left as it is.

I'll change only the number of categories and fields to 4 bytes ->

4 bytes - number of categories (if categories are present)
n_cats * 4 bytes - field (4 bytes per field)
n_cats * 4 bytes - cats (4 bytes per cat)

Radim