• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)
• *NEW* AGI Components for Silveright (BETA) (What's New) (Download)

This release finally brings Insight3D to AGI Components for Java! Scott Hunter has the details over at the Insight3D blog.

This release also includes a huge number of features, improvements, and important bug fixes. Check out the "What's New" links above for the full list.

• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)
• *NEW* AGI Components for Silveright (BETA) (What's New) (Download)

One exciting thing about this release is that we've officially made the Silverlight version of AGI Components available as a public beta. We consider it a beta because the documentation is incomplete, and it hasn't been as well-tested as our official releases. Check it out and less us known what you think!

This release also includes a number of important bug fixes for Insight3D, and a few smaller features.

Oh, and of course this release includes the big features added in AGI Components 2010 r6. I didn't announce that release on this blog, but I really should have. Insight3D gained the ability to load and display KML documents. We also added a new library that makes it really easy to visualize Platforms, Links, and other service providers in Insight3D. Please take a look at the "What's New" pages above for the complete list of what was changed in both 2010 r6 and 2010 r7.

We've received a number of questions and comments on how to represent aircraft and ground vehicle trajectories for use with mission analysis.  Route Design Library makes it a lot easier to create and analyze these kinds of trajectories.  Now, users will be able to specify waypoints, heights, and speeds to define a route and generate a trajectory over the surface of the Earth or other Central Body.  Previously, the WaypointPropagator (still available in DGL) provided a way of specifying waypoints and creating a Point.  However, many users have found it difficult to use in certain cases since it requires careful handling to make sure the properties on each waypoint are consistent with the surrounding waypoints in order to avoid exceptions during propagation.  With Route Design Library, that process has been simplified, allowing for a looser definition of waypoints to make it easier to specify a valid route.  I will discuss a few of the key features and paradigms here.

Procedures and Profiles

The key features of Route Design Library are its "procedures" and "profiles".  "Procedures" define the behavior of the route around certain locations or areas of interest.  In general, most users will only need to use the different waypoint types to specify how to execute a turn at a given waypoint.  However, we also provide other procedures such as takeoff, landing, circular and racetrack holding patterns, and a raster search pattern useful for covering a search area.  Likewise, there are three different "profiles" provided to specify the vertical and temporal behavior along the surface route.  Some procedures include their profiles implicitly, as is the case with takeoff and landing.  Often, the procedures will require using a profile such as a ConstantHeightProfile or TerrainAvoidanceProfile which I will talk about in the section below.  The other profile StandardTransitionProfile is primarily intended for the connection segments which glue the user's procedures together.

Geometry: Points, Axes, and Scalars

Of course, the primary output of the library is a DGL Point object which can be used with Platforms in the rest of the library.  However, we also provide a number of Scalar objects for various analysis properties along the route such as ground or total speed and height with respect to a reference surface like MeanSeaLevel.  Lastly, there are two Axes types: AxesAlongTerrain and AxesFromBankAngle. The former provides a simple way of representing the orientation of a ground vehicle as it traverses over a terrain with its z axis aligned with the local terrain normal.  The latter provides a simple way of representing an aircraft as it 'banks' around turns, balancing gravity and centripetal forces.

Overdefined Hassle vs. Underdefined Configuration

One of the things we looked at when creating Route Design Library was the problem of creating "overdefined" design spaces.  When a system is overdefined, it is often unclear to users how to specify all of the parameters in a way that won't cause problems.  An overdefined system places the burden on the user to ensure that all of the inputs are consistent and valid, often creating a lot of hassle early in the design process as users keep running into exceptions as they try to determine how to create valid inputs.  In Route Design Library, the user's input can be underdefined, meaning that there are a number of heuristics in place which allow the system to create a valid route based on just a few user inputs.  Primarily, the system revolves around the users specifying behavior at the "procedures" and then allowing the propagator to create "connections" to combine the procedures together into a complete route.  This allows users to focus on those parameters which they want and let the system connect the rest in order to create a valid route, instead of having to fuss in order to finally create the valid route.

Since the specific performance characteristics of aircraft are often not available during the initial mission design, it doesn't make a lot of sense to create a highly detailed route which is inevitably inaccurate compared to the real-life flight path.  Instead, the goal is to allow users to simply create a reference trajectory from which they can analyze the wireless communications, asset coverage, and scheduling feasibility of a given route before working on developing the final flight path.  If some of the flight characteristics are available, users should be able to use them to determine the inputs needed to create a fair approximation of the final route.

Route Design Library also has the ability to include analytical terrain for use with profiles.  By specifying a terrain surface, the TerrainAvoidanceHeightProfile can aid in designing a route by providing a simple way for users to specify aircraft routes which maintain a given height above mountainous or rapidly changing terrain.  The system will reconfigure the user's input to attempt to avoid the terrain by reconfiguring the surrounding procedures until the system either creates a valid route or encounters an error which prevents the route from avoiding the terrain (e.g. If the user has fixed the surrounding heights below the terrain and the system can't update them).  However, if there is an error, it will not throw an exception! (except of course in cases where there are NaNs in the user's input).  Instead, the propagator will return the invalid or discontinuous route with meta-data in the form of ProcedureConfigurationResult objects indicating what the error was and where it occurred in the route.  This way, the user has the chance to visualize the discontinuity in order to see what went wrong, rather than throwing an unrecoverable exception.

Non-Euclidean Geometry Hidden from the User

Anything that moves over the ground (or water) requires some special handling.   When dealing with satellites, the dynamics for Newtonian gravity are well defined and the only use for the 'ground' is as a projection surface onto which to plot the "ground track" for the satellite.  When thinking in terms of aircraft or even ground vehicles on cross country shipping routes, most people don't tend to think of the 'ground' as being curved and may overlook the relationship between the 'flat' map projections used in navigation and the three dimensional reference frames used by satellites.  Aircraft manuals and documentation will often refer to "ground speed" and "true speed", but what do these really mean in terms of the Fixed Frame of the Earth?  One of the things we decided was that, when defining a 'route', users do not want to have to calculate the coriolis accelerations and other effects of moving over a rotating curved surface.  As such, users specify the speeds at waypoints as if they were the 'local' or 'flat' dynamics and Route Design Library takes care of accounting for the additional dynamics observed by satellites communicating with vehicles along the route.

As mentioned before, the Route Design Library makes use of analytical terrain surfaces for the TerrainAvoidanceProfile.  In addition, the library uses terrain surfaces to specify the reference from which the "height" is measured for a given profile.  So, instead of just dealing with Cartographic values which are by default referenced to the WorldGeodeticSystem1984 Ellipsoid, Route Design Library can create routes which have their heights referenced to MeanSeaLevel or in the case of ground vehicles referenced to the mountainous terrain over which they are driving.  It is also possible to transition from one to the other.  So, in the case of an aircraft taxiing on a runway before takeoff, it is possible to transition from having the height referenced to the runway surface to an Ellipsoid height or height above MeanSeaLevel.  The library takes care of any additional dynamics needed to transition between the local dynamics and the dynamics in the Fixed Frame as seen by a satellite.

Remarks and Future Development

In the end, we hope Route Design Library is easy to use programmatically so that users can design their own systems which can iterate when designing scheduling and mission analysis programs.  It also makes it much easier to use with Insight3D, since it is much simpler to visualize the route itself and identify the location of any errors in the route.  For now, the library focuses mainly on heuristic and approximate routes intended for creating simple routes quickly and easily.  In the future, new procedures and connections may be added to allow trajectories based on performance characteristics and numerical flight mechanics.  As always, it is also possible for users to extend our types to create their own as well.  If you or someone else on your team has any questions about Route Design Library, how to extend it to implement custom functionality, or if you have a feature request, please feel free to post on our ADN discussion forums.

• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)

There's a bunch of exciting new stuff in this release. First and foremost: Route Design Library. Route Design Library makes it easy to define an aircraft, ship, or ground vehicle route using waypoints, holding patterns, and more. It is a huge usability improvement over the WaypointPropagator.

Also in this release are two long-awaited Insight3D features. The new BingMapsForEnterpriseImageGlobeOverlay class makes it easy to show detailed Microsoft Bing Maps (formerly Microsoft Virtual Earth) imagery on the Insight3D globe.

Second, this release introduces per-item picking, which makes it much easier to determine which individual item in a primitive batch was picked.

AGI Components 2010 r5 includes many more features than I've mentioned here, and some important bug fixes. Please take a look at the complete list of what's new (linked above) and upgrade as soon as you're able!

Here are the details for AGI Components 2010 r3:

• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)

The Tracking Library enables developers to build online data analysis or tracking applications which integrate live and simulated data for situational awareness and decision support.

To learn more about Tracking Library, go here. To learn if "thusly" is a real word and if I used it correctly, go here.

As usual, AGI Components 2010 r2 is available for both .NET and Java.

• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)

Before we get started, we need to define exactly what we mean for one object to "see" another object. In the simplest case, we might just require that the Earth not lie between the two objects, and we might model the Earth as a simple WGS84 oblate spheroid. In more complicated cases, we might require that the other object lie within the field of view of a sensor attached to one object or that the line-of-sight between the objects not be obstructed by terrain. All of these requirements are represented in AGI Components as access constraints. The complete list of constraints that come with AGI Components can be found in the documentation for the AGI.Foundation.Access.Constraints namespace. It is also possible to define your own access constraints, but that is a topic for another blog.

For this How To, we'll build a simple access query that determines when the line-of-sight between two objects is not obscured by the WGS84 ellipsoidal model of the Earth and one object lies inside the field-of-view of the other's sensor.

For this example, we'll need the following using declarations:

using AGI.Foundation;
using AGI.Foundation.Access;
using AGI.Foundation.Access.Constraints;
using AGI.Foundation.Celestial;
using AGI.Foundation.Coordinates;
using AGI.Foundation.Geometry;
using AGI.Foundation.Geometry.Shapes;
using AGI.Foundation.Platforms;
using AGI.Foundation.Propagators;
using AGI.Foundation.Time;

We'll also need the Earth instance, which can be obtained from the CalculationContext:

EarthCentralBody earth = CentralBodiesFacet.GetFromContext().Earth;

With the preliminaries out the way, let's define the two objects. For our example, one will be the International Space Station, propagated from a TLE:

string tleString = "ISS (ZARYA)             " +
            "1 25544U 98067A   10067.86878632  .00013253  00000-0  96217-4 0  7319" +
            "2 25544  51.6483  25.6247 0007782  28.7411  11.9386 15.73741103647672";
TwoLineElementSet tle = new TwoLineElementSet(tleString);
Sgp4Propagator issPropagator = new Sgp4Propagator(tle);

Platform iss = new Platform();
iss.LocationPoint = issPropagator.CreatePoint();
iss.OrientationAxes = new AxesVehicleVelocityLocalHorizontal(earth.InertialFrame, iss.LocationPoint);

The other will be AGI's headquarters in Exton, Pennsylvania.

Cartographic agiHQPosition =
    new Cartographic(
        Trig.DegreesToRadians(-75.59677),
        Trig.DegreesToRadians(40.03883),
        0.0);

Platform agiHQ = new Platform();
agiHQ.LocationPoint = new PointCartographic(earth, agiHQPosition);
agiHQ.OrientationAxes = new AxesNorthEastDown(earth, agiHQ.LocationPoint);

We also need to create a sensor field-of-view and attach it to the International Space Station. Please note that the sensor below is completely made up - it does not represent any actual sensors on the ISS.

RectangularPyramid sensorFOV = new RectangularPyramid();
sensorFOV.XHalfAngle = Trig.DegreesToRadians(20.0);
sensorFOV.YHalfAngle = Trig.DegreesToRadians(20.0);

FieldOfViewExtension fovExtension = new FieldOfViewExtension(sensorFOV);
iss.Extensions.Add(fovExtension);

Next, we create a link between the ISS and AGI's headquarters. The link allows us to control how the two platforms communicate.

LinkInstantaneous link = new LinkInstantaneous(agiHQ, iss);

In this example, we use a LinkInstantaneous, which assumes that the light or other signal transmitted from AGI's HQ to the ISS arrives instantly. This is not strictly true - light travels at a finite speed. However, because light moves pretty fast and because the ISS is pretty close to Earth, correctly modeling the speed of light will not significantly impact the results, and using LinkInstantaneous results in better computation performance. For satellites in higher orbit (or, say, orbiting Mars!), modeling light travel time can be extremely important. In that case, LinkSpeedOfLight should be used instead of LinkInstantaneous.

Now we create the two constraints that we're going to use to constrain access:

CentralBodyObstructionConstraint cboConstraint = new CentralBodyObstructionConstraint();
cboConstraint.ConstrainedLink = link;
cboConstraint.ConstrainedLinkEnd = LinkRole.Receiver;

SensorVolumeConstraint sensorFOVConstraint = new SensorVolumeConstraint();
sensorFOVConstraint.ConstrainedLink = link;
sensorFOVConstraint.ConstrainedLinkEnd = LinkRole.Receiver;

Note that we've specified the link created above as the "constrained link" and in both cases the "constrained link end" is the link's Receiver, which is the International Space Station.

The next step is to construct an access query that is satisfied whenever both constraints are satisfied. We do so succinctly by using the overloaded & operator:

AccessQuery query = cboConstraint & sensorFOVConstraint;

We can then obtain an evaluator with which to determine the intervals when the query is satisfied.

AccessEvaluator evaluator = query.GetEvaluator(iss);

We must specify a time observer in the call to GetEvaluator, and for this example we chose the ISS. With the LinkInstantaneous that we're using in this example, the choice is arbitrary. However, with a LinkSpeedOfLight, events such as the beginning or end of access occur at different times when observed by different participants in the access computation. The time observer is the object that is observing the event times.

Finally, we can evaluate the intervals when our access query is satisfied:

JulianDate start = new JulianDate(new DateTime(2010, 3, 10, 12, 0, 0, DateTimeKind.Utc));
JulianDate stop = start.AddDays(1.0);

AccessQueryResult result = evaluator.Evaluate(start, stop);

foreach (TimeInterval interval in result.SatisfactionIntervals)
{
    Console.WriteLine(interval.Start.ToGregorianDate() + " - " + interval.Stop.ToGregorianDate());
}

This example only scratches the surface of what access queries can do. The constraints in the query need not use the same link or be between the same objects. In addition to And shown above, queries can be built from any combination of Or, Not, AtLeastN, AtMostN, and ExactlyN. In short, access queries can be used to solve the kinds of problems that can be solved with STK/Chains, plus many more! See the Access Queries topic in the AGI Components documentation for more information.

Or the ArcGIS API for Silverlight:

If this is exciting to you, I want to hear from you!

The list of platforms where you can use the analysis capabilities of AGI Components is growing to be quite impressive: .NET, Java, and MATLAB for starters. Both the .NET and Java versions can be used on Windows, Linux, and Solaris.

AGI Components for .NET can also be used on the Apple iPhone and iPad via MonoTouch. The rumor is that MonoTouch will be available for Android soon, at which point AGI Components should run there, too! If you're interested in using AGI Components with MonoTouch, please drop me a line.

AGI Components for .NET can run on Windows Mobile as well. And because the recently announced Windows Phone 7 Series is likely to be based on Silverlight, there's a good chance AGI Components will run there, too.

No matter what your target platform, operating system, or device, there's probably an AGI Components for you!

Check it out:

• AGI Components for .NET (What's New) (Download)
• AGI Components for Java (What's New) (Download)

This release is a big deal because this is the first release that is available simultaneously for both .NET and Java! And in case you're wondering, yes, this is the start of a trend. We intend to release new versions for both platforms simultaneously from now on. If you're curious how we're doing it, check out Scott's post on the subject: AGI Components for Java: How it Works.