[GRASS5] Re: Vector format proposal

[Radim Blazek]

Eric G. Miller wrote:
> Well, here's my two cents on data models.
>
> I fully agree with David regarding graphic vs. topological
> representations of "entities".  I've seen plenty of shapefiles with
> screwed up geometry to know this is a real problem.  But, I'll grant the
> topological "coverage" concept is a bit more complex to manage vs. the
> graphic representation.
>
> In regards to attribute tables: I would think a one to one mapping from
> each map entity to an attribute table via a unique integer key is the
> best solution.  So, for each AREA, LINE, SITE, LABEL, NODE, etc there is
> a table.  It might be, we want to maintain some separation between
> internal numberings and what the user uses for a key.  Otherwise we
> can't change a numbering after an edit/rebuild cycle because the linkage
> with the attributes will be broken.  A simple two integer table is all
> that is needed, the user is only presented with setting the "user_id"
> whereas the other is maintained by the system.  Example:
>
> AREA_ID | USER_ID
>       1 |       1
>       2 |       1
>       3 |       2
>       4 |       1
>  ...
>
> So, when v.digit asks for a "category number" it sets the "USER_ID" with
> whatever the user wants, but the "AREA_ID" is incremented as the next
> largest value (for that table).  A rebuild might renumber the "AREA_ID"
> to make them sequential, but the "USER_ID" is never touched.  Thus,
> linkage to external tables always works.  I think I'm getting redundant
> here ;)

USER_ID is category in grass and AREA_ID is sequential number assigned
during build process. Link to table may not be broken. Lib is written in this 
way.

Radim

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