Re: [Repast-developer] Re: Repast-developer digest, Vol 1 #24 - 2 msgs

[Laszlo G. <gu...@la...>]

Hi,

I am not sure I completely understood everything in these mails below
(I have little clue about GIS's), but they certainly sounded interesting.

Could you explain me at some length what a congruency matrix is?
And I am ashamed to ask, but I am not sure I understand the centroid
thing either... ;-)

Finally, how is geometry represented in standard gis software? I mean, maybe
we could borrow something from there, too . I am fine with ArrayList, but 
who knows...

On the other hand, I have a couple of less visionary 'proposals', too. All
of these are just quick ideas, so feel free to point out the defects in them.

- I tend to like the use of ObjectLocation in the multi-occupation grids.
   Maybe, we should provide this functionality in all discrete grids.
   (I am lacking it when I want to implement moving -- it's OK that I can
    grab my neighbors, but it would also be nice if I could grab the 
neighborous
    cells/locations, too.)

- Also, I would propose to introduce another standard functionality. Something
   like DistanceFromTo()... This is because while calculating the distance 
on normal
   grids is fairly easy, it can get rather complicated in other cases. (The 
hexagonal
   lattice is one example, but I can also think of a subclass of the normal 
2DGrid,
   which contains walls and other obstacles...)

- Finally, in Node (in the networking library), it would be nice to have 
something
   like getEdgeTo(Node), which would return the edge that connects the 
actual node
   to the parameter (or null).

Well, that's for today.

Gulya

At 09:30 AM 11/28/01 -0600, you wrote:
>I guess that it is now my turn to add to the conversation.  For those of you
>who don't know, I am working on gis spaces.  Up to now, I've been using raster
>spaces whose nieghbors can be calculated just like grids.  Now that I'm 
>getting to work on the vector spaces this approach is not 
>appropriate.  From what I've read in this thread, I really like the idea 
>of using radius to determine nieghborhoods.  This is how we have 
>historically calculated this sort of thing in gis using the buffer.  the 
>other approach I've seen is to maintain a congruency matrix that can be 
>searched to find neighbors.  This might work for hexagonal spaces, but 
>becomes problematic in gis spaces (even though that's where I've seen it) 
>because of the non uniform nature of gis shapes.  I think that using the 
>centroid and a buffer (either oval or circle) to calculate neighbors is a 
>good way to approach the general space interface.  As Skye says, the grid 
>can use this functionality and add the moore, vn neighborhoods in the 
>subclass.  Lord knows it will make my task easier if I don't have to deal 
>with those concepts (I wouldn't even
>know where to begin).
>
>So, that's just what I'm thinking.
>

[and]

Ooops, one more thing. In gis, we generally think of buffers a circular 
radii (is that the right word? :)). As a matter of fact, all of the 
libraries I use and have seen (for gis) have a method called: buffer(double 
distance). Just something to think about. On the other hand, they also 
return a single object (a new geometry) instead of a collection, so I'm 
going to have to change that anyway. But nonetheless.
-Tom,
who continues rambling