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]