MASON has always gone a long way out of the way to make sure that implementers don't 
accidentally do things that will compromise performance. That is certainly one of the great 
strengths of the library. But as we attempt to do more complicated things, we reach a fork: 
we can make things elegant and reasonably straightforward for the advanced coder but 
allow greenhorns to shoot themselves in the feet, or we can make things complex and 
difficult to implement, but ensure that no one is accidentally doing silly things. I think with 
GeoMASON we have reached that fork and, indeed, moved past it.

Because, honestly, it is going to be just as hard for a new coder to figure out that he needs to 
schedule an update to the spatial index as it would be to teach same coder not to 
capriciously remove items from a structure that takes a long time to update. In fact, the new 
coder may be adding extra time in any case by scheduling that regular update to the index 
because he wants live updates. At the same time, perhaps we are making things a little hard 
on the experienced coder, as well, because she expects MASON fields to stay up-to-date by 
themselves, since they always have in the past.

Now, I do understand that updates to the QuadTree are quite expensive, so we might not 
want to do them very often. In fact, I would perhaps suggest that one might want to lazily 
schedule that update to the spatial index only when one has made an actual change to the 
field contents.

However, I have an alternative suggestion: the REAL problem, I think, is that we're having to 
put agents onto the GeoVector spaces instead of on more efficient, basic MASON grids or 
continuous fields, if we want them to align to the underlying GIS landscape. Might it not be 
more efficient to instead add an adapter class for the basic MASON fields that make them 
symmetric with the Geo fields? That is, flip the y-axis and allow origins other than (0,0). Or 
even add new functionality to the existing MASON fields so that they can be used 
symmetrically with the Geo fields. That way, I believe the agents would show up in the 
correct places, but we could do without the QuadTrees and use the much more efficient 
MASON representation.

Just a (longwinded, as usual) thought.

On Mon, 8 Apr 2013 22:05:40 -0400, Mark Coletti <[log in to unmask]> wrote:

>I think the problem is that the spatial index isn't being informed of the
>object removal.  Again, removing objects from the spatial index is
>potentially expensive, which is why it no longer automatically happens when
>the user removes or otherwise changes an object's position -- when the
>spatial index is rebuilt is a design decision left to the implementor as
>they'd presumably know best when to do that.
>
>In other words, I think I resolved your problem by adding the following to
>your Sim.start():
>
>        schedule.scheduleRepeating(new Steppable()
>        {
>            public void step(SimState state)
>            {
>                trailSpace.updateSpatialIndex();
>            }
>
>        });
>
>However it might be more efficient to trigger such an event only when
>something is actually removed or otherwise has its position changed.
>
>
>On Thu, Apr 4, 2013 at 4:00 PM, Luís de Sousa <[log in to unmask]>wrote:
>
>> Hello again,
>>
>> In attachment a little sample showing this last situation I reported. The
>> Trailer agents continue to be drawn after the stop() method is invoked, and
>> even when the simulation is restarted.
>>
>> Regards,
>>
>> Luís
>>
>>
>> On 27 March 2013 21:07, Luís de Sousa <[log in to unmask]> wrote:
>>
>>> Hello again,
>>>
>>> I noted today that geometries that have been removed using this method
>>> continue to be drawn in the display. I have an Agent class that
>>> inherits from MasonGeometry; this particular agent can "die" during
>>> simulation and its stop() method is invoked. When this happens with an
>>> agent stored in a Continuous2D, for instance, invoking the remove()
>>> method is enough to prevent it from being drawn again.
>>>
>>> After invoking removeGeometry() is there anything else referencing the
>>> geometry?
>>>
>>> Thank you,
>>>
>>> Luís
>>>
>>> On 21 March 2013 18:58, Mark Coletti <[log in to unmask]> wrote:
>>> >
>>> > I've added removeGeometry() and committed the changes to subversion.  Be
>>> > aware that removing things from t he spatial index can be expensive in
>>> > addition to removing things from "shadow" Bag of Geometries.
>>> >
>>> > Cheers!
>>> >
>>> > Mark
>>>
>>
>>
>
>
>-- 
>[log in to unmask]
>