[GRASS5] Re: [GRASSLIST:5030] Re: Grass Data Model used for areas

[Radim Blazek]

On Sunday 24 November 2002 07:41 pm, David D Gray wrote:
> The WAY TO GO. We must concentrate IMHO in future editing facilities in
> GRASS on a more intuitive interface, but if that is TAM, it means the
> map must be built incrementally as it is developed (BAYG or 'build as
> you go'). Also an 'expert' mode must remain avilable, so that terrible
> errors caused by other peoples' software can be fixed ;)

Topology in v.digit/g51 is always up to date because map is opened at level 2
and each call to Vect_write_line() updates topology. What should be 'expert'
mode? I thought that we are always in 'expert' mode in v.digit :)

> It is more difficult to go TAM -> NTAM, and this is where topological
> cleanliness and information stablity is crucial.

Do you mean NTAM -> TAM?

> > Currently I know only about one real disadvantage of TAM: Overlaping,
> > usually artificial area objects like bridges and tunnels cannot be
> > represented in TAM. If one road is on the bridge and seccond one under
> > the bridge it is difficult (impossible?) to do that in TAM.
>
> It is possible, if difficult. The main point is that you need some kind
> of attribute, a hidden attribute or 'ghost code' maybe, to specify which
> TE is on top anyway, both in TAM and NTAM. In both cases you need to
> know the history of the map's construction to correctly assign level if
> you have no such index. That is bad information structure, as entities
> do not 'encapsulate' all the properties of their construction depending,
> for example, on the sequence of import.
>
> You can build a TAM coverage with overlapping structures, if you assign
> topological features _locally_ like left/right polygon of a boundary
> while you are importing/building/editing, instead of holistically at the
> end. It might be possible to (re)build a map at the end, but overlapping
> features might not build unambiguously : we have this problem in the
> stable vector format for lines now.

To assign left/right polygon to each boundary does not seem to be best for
editing, I think. Anyway, it is not solution if the boundary is shared by 
more levels.

>  A level may occur
> in a layer representing, for example area cover, but such that entities
> in the same layer might overlap, like roads at a complex motorway
> junction. This can be handled by 'ghost codes'. There are several
> levels, and any TE can be aware of only those sharing its level, so if
> two overlapping areas share one edge, the edge is in two levels, but the
> other boundaries only in one. The build process then builds the two
> areas OK. This would be easy to implement in v.build, as it would just
> be a question of doing separate build runs for each level. Assigning the
> levels would be more difficult.

I think that build which works with levels is not as easy as it could seem
to be , especially if topo should be updated by Vect_write_line(). 
I don't plan this for grass51 as we have still a lot of other work, but
it may be solution for future. 

Radim