[GRASS-user] RE: Problem querying layers other than '1' in gi s.m

[Moritz Lennert]

On Tue, September 26, 2006 17:06, Radim Blazek wrote:
> On 9/26/06, Moritz Lennert <mlennert at club.worldonline.be> wrote:
>> Radim Blazek wrote:
>> > On 9/22/06, Moritz Lennert <mlennert at club.worldonline.be> wrote:
>> >> > There are more, examples:
>> >> > - Overlapping areas, e.g. a road on a bridge and a road below
>> >> > - Many records with different time for the same point
>> >>
>> >> Both of these examples use different layers to store information, not
>> >> different category values in the same layer, or ?
>> >
>> > No. One layer, more cats per geometry.
>>
>> What's the advantage of doing this in one layer ? Why not use one layer
>> with one category value and store different time records for the same
>> category in the one table linked to that layer ?
>
> That would be also possible in theory but GRASS does not work in this
> manner.
> The reason is that this way it is not possible to model for example
> overlapping
> areas. Imagine  2 areas, bridge over another road, each road has one
> record in table.
>
> Map:
>            +-------+
>            |   A   |
> +---------+--------+-----------+
> |   B     |  A/B  |   B       |
> +---------+--------+-----------+
>            |   A    |
>            +--------+
>
> Table:
> +------+--------+
> |  cat |  road |
> +------+--------+
> |   1   |   A   |
> +------+--------+
> |   2   |   B   |
> +------+--------+
>
> Now try to fill in cats to the map. It is impossible. You need to give
> more cats to the overlappig part.
>
> In theory you could move the relations to a database as suggested Trevor,
> but it would be difficult and not efficient to reflect any operations
> on geometry
> in database. It is very easy to assign 2 cats to the overlapping parts
> from 2 input areas, to do that in database (from GRASS) is much more
> complex.

Thanks for the explanation. I understand the overlapping areas argument.
What about the time series ?

> If you want, you have to move to database everything, i.e. also geometry.

The PostGIS solution. But am I right in thinking that PostGIS is
non-topological, with the consequence that you get all the potential
'spaghetti geometry' problems ?

Moritz