The topologies of 2D agent-based models are almost completely dominated by bounded planes and torus surfaces (aka: wrapping edges, aka: periodic boundaries). These may be reasonable approximations for some systems, but certainly not for all. There are at least few things I’d like to model that occur on the surface of something roughly spherical (e.g. on the Earth). Spheres are topologically like bounded planes in that neither has holes and both can be laid flat. But they are also like tori in that they have periodic boundaries as surfaces of three-dimensional objects. In order to facilitate a growth in popularity of sphere (or ellipsoid) models, I present a technique (and eventually code) for generating such models in Java or NetLogo.

It may be important to note that this is not a new idea. Cartographers have been searching for and finding ways to represent the Earth on maps with minimal deformity for centuries. You are probably familiar with different projections that each preserve different aspects of the Earth's surface (distance-preserving, area-preserving, etc.). There are also plenty of computer models that already represent an object's coordinates in spherical coordinates which can be easily mapped onto a 2D surface (e.g. satellite tracking, military applications, cell phone coverage, etc.). So, one way to look at this mini-project is simply to make the capability user-friendly for a wider audience.

But the truth is that you can spend years studying agent-based models and never encounter one utilizing a sphere topology. My main motivation for easing the incorporation of spherical topologies into agent-based models is to expand the conceptual foundations upon which models are built. My hope is that by simply having another option some researchers will explore its properties and reveal some interesting behaviors that cannot emerge on other topologies. I believe that decisions to use the bounded plain or torus are usually either arbitrary or based on convenience and hence that making it just as convenient should be sufficient for making it just as popular. [Note: This is similar to Ken's and my position on using hexagonal tiling: it is clearly superior for certain models but underused due to the unnecessary complication of its current implementation requirements.]

This image of a azimuthal projection was found from Google images.The first projection that I am pursuing is the azimuthal projection. This technique projects the surface of a sphere onto a circle (and an ellipsoid onto an ellipse) by picking two points on the surface and making one the center of the circle and the other the outer edge. Imagine the hole in a balloon is the South Pole and we're stretching the balloon over a pizza dish until it perfectly covers one side. The idea can be most intuitively understood by selecting opposing poles as the two points; the results of that projection for the Earth (using the north and south poles) can be seen in figure 1. This choice of points is not necessary, but other results are wacky and produce unintuitively distorted images.

Let examine what agent behaviors look like on the azimuthal projection? Let's start with an example of the Earth and agents moving across the surface at constant speed (which in this case means constant angular velocity). On the projected surface the north/south component of velocity is the same everywhere but the east/west component of velocity is amplified as the agents move further from the North Pole. The South Pole is just a point (as you know), but in this projection it is the entire outer boundary of the circle. On a sphere if an agent keeps going south until it reaches the south pole…and keeps going…it will be traveling north on the exact opposite side of the Earth. On the projection this means that the boundary wraps in a specific way: an agent's exit trajectory is mirrored to the boundary exactly on the other side (180 degrees away). So it looks like it is reversing direction (see figure 2), but the important thing is that the agent is still traveling with the same east/west component as before. We are on the surface of a sphere and all points are indistinguishable with respect to the topology (one reason people choose tori over bounded planes) so it doesn't matter where the poles are and they can be moved to convenient locations as desired (e.g. to follow an agent or keep the most active region in the middle).

This image of a azimuthal projection was found from Google images.Motion on the projected disc will probably seem unintuitive. For example, looking at the longitude lines (from the North Pole to the South Pole) which are spaced evenly in terms of degrees, we know that the distant between longitude lines is greatest at the equator and decreases as one approaches the poles. But on the projection (figure 1) they get steadily further apart the further one gets from the North Pole. This means that for the central parts of the disc the visual distance corresponds to the actual distance but outside the equator the visual distance in inversely related to the actual distance. And those relationships only apply to the east/west component of direction – the north/south component is the same linear relationship everywhere. It may not be visually intuitive, but it is mathematically rather simple to convert the spherical coordinates to the azimuthal disc projection and back.

So you can all start programming your agent-based models using the surface of a sphere as the surface. You'll want to use spherical coordinates for locations and motions, and commands like "forward 1 space" will need to be converted into arc lengths. Very soon you'll have a tool box for performing these actions and whether you end up projecting onto a disc, some other 2D surface (which may also be supplied later), or you decide to model it in 3D you'll have a whole new world of modeling opportunities with the sphere topology. Soon, but not very soon, I'll be creating an example system which I'll post here so you can get a head start on making your own by seeing how to get the agent motions to match the world correctly.