Floris' Blog

Distances and globes… There must be signposts pointing to far-away locations all over the world. Those signposts probably list the distances as a bird would fly, but that’s not the only to measure a distance between two points. One could also use a route planner, or use the straight line from A to B, which would go through the earth.

The following snippet calculates the distance between two points in two ways: direct, as well as following the great circle (a circle that follows the earth in such a way that it results in the shortest path between the points while following the curvature of the earth). Note that this doesn’t account for elevations.

Code:

To obtain the necessary geometry, supply an instance of gov.nasa.worldwind.Model.

Showing icons on the map is done by adding a IconLayer to the map. Icons can then be added to this layer. You can provide your own images to be shown. These images are then shown with their center-bottom at the given position. Additionally, you can provide a pedestal: an additional icon that is used as a pointer (and is the same for all icons on the layer). An offset allows the icon to be offset in a vertical direction from the pedestal.

The following shows icons for Amsterdam and Paris. The marker for Amsterdam is given a tooltip (that is always visible this way). The triangle is the pedestal, the circle the icon.

Code:

One of the things that I’ve wanted to do with WorldWind is display tracks from my holidays where I recorded a GPS-track. Doing so is rather easy (one can directly use a GPX format track, no need to convert it like with Google Earth), but be aware of some caveats.

WorldWind makes loading GPX files easy with just a call to a new GpxReader-instance. The result is a collection of tracks. These tracks can be directly fed to a TrackPipesLayer:

Code:

This produces a somewhat unsatisfactory result: while the layer looks nice with the white lines and red points, it is slow for larger tracks and the size of the objects is so big that it obscures the track itself:

To change the diameter of the pipes, you need to pull some WorldWind code to your own codebase and modify the diameter settings (they are there, but not mutable). In the end that resulted in a mess that didn’t perform, and pipes disappeared underneath the earth where there was a discrepancy between the elevation model in WorldWind and the elevations obtained from the GPS.

Better results are obtained through the RenderableLayer:

Code:

The code is a little bit more involved. When the layer is created, we iterate over all TrackSegments (each track can be made up of multiple segments). Each of these segments is transformed into a Polyline. To do so, we need to supply an Iterable<Position> instance. The TrackToPositionIterable class does exactly that.

The downside of this solution is that GPS height information isn’t used on the map. The result is somewhat faster though, and the track is sticking to the surface, overall providing a more usable result.

In case you’d want to modify the track data: changes to the TrackSegment objects seem not to be propagated to the Polylines. The iterator is used only once, during construction. Therefore you’d need to remove the Polyline, construct a new one and add it. Additionally, you’d need to make a call similar to “layer.firePropertyChange(AVKey.LAYER, null, layer);” to trigger an update of the screen.

The time of year has come where I find myself having some time to play around with applications and frameworks that have been on the list for some time. One of these is Nasa’s WorldWind: an application somewhat similar to Google Earth. There are several versions: one in C# which seems to be just the application, while the other is a Java library that allows one to embed maps in your own application.

This turns out to be really easy:

Code:

The actual creation happens inside the createWorldWindComponent() method. A new canvas is created, initiated with a default model, and off you go!

The default model applies some layers to the globe. These layers are iterated over in the showLayers() method. This results in:

Stars                          | 1.0 | 1.0 | true  | true  | false | true 
Atmosphere                     | 1.0 | 1.0 | true  | true  | false | true 
Fog                            | 1.0 | 1.0 | true  | true  | false | true 
NASA Blue Marble Image         | 1.0 | 1.0 | true  | true  | false | false
BlueMarble (WMS) 05/2004       | 1.0 | 1.0 | false | true  | true  | false
i-cubed Landsat                | 1.0 | 1.0 | false | true  | true  | false
NAIP California                | 1.0 | 1.0 | false | true  | true  | false
USGS Urban Area Ortho          | 1.0 | 1.0 | false | true  | true  | false
Place Names                    | 1.0 | 1.0 | true  | true  | false | true 
World Map                      | 0.6 | 1.0 | true  | true  | false | true 
Scale bar                      | 1.0 | 1.0 | true  | true  | false | true 
Compass                        | 0.8 | 1.0 | true  | true  | false | true 

That’s quite a few layers! Stars, atmosphere and fog create a bit of atmosphere, while ‘NASA Blue Marble Image’, ‘BlueMarble (WMS) 05/2004′, ‘i-cubed Landsat’, ‘NAIP California’ and ‘USGS Urban Area Ortho’ provide the map data. Note that the data is somewhat older, and especially outside the USA isn’t too detailed.
The place names layer displays names over the map. The ‘World Map’, ‘Scale bar’ and ‘Compass’ layers draw the widgets on top of the screen that show an overall world map, a bar indicating the scale and a compass. The latter is hardly necessary as world wind keeps North at the top of the screen (in contrast to Google Earth), unless you make some movements around the poles in which case it will keep North at the bottom.

Over the next few days/weeks I’ll post some more experiments with WorldWind.

The Fork/Join framework is the latest extension on JSR 166 (the concurrency utilities added in Java 5). This extension adds a new framework to allow developers to easily include fine-grained parallelization in their applications. Doug Lea hopes this will help developing software for massive multi-core machines.

The framework consists, broadly speaking, of two parts: the fork/join framework and the ParallelArray. The fork/join framework allows for flexible use, while ParallelArray is built on top of the fork/join framework and intends to make common cases simple.

The idea underlying the fork/join framework is that many tasks can be decomposed into smaller tasks, of which the results can be merged afterwards. Often these decomposed tasks can be further decomposed recursively. Of course, to allow this, one sometimes needs to chose a different algorithm that the one that is most efficient on a single thread. Compare quicksort and mergesort: The former is computationally more efficient, while the latter is better to parallelize and might therefore return results in less time, given enough cores to perform the computation.

The following is an example of using the fork/join framework:

Code:

The program generates some strings representing dates, and creates a new instance of DateSearcher passing all data plus the boundaries. This DateSearcher is a RecursiveTask, which provides the outline for tasks that will be decomposed recursively and return a value. The compute method checks amount of work to be done by looking at the boundary values. The reason to do so is that at a certain threshold it is more efficient to go over the element sequentially than breaking the sequence down even further.
If the task is still too big, however, the range is split in two and each is given to a new DateSearcher instance. The first is handed to the forkjoin-pool-workers with a call to fork, while the second is also passed to the pool, but using forkJoin(): this makes the current task wait for the result to return and is supposedly more efficient. When the result is obtained, the task starts waiting for the result from the first task, and when both results are in, the task returns its result.
The threshold in the above was picked at random. In reality one will want to perform some experiments. Some research by Brian Goetz has shown that the exact numbers are not too significant: difference of an order of magnitude still perform relatively well.

The second part is the ParallelArray implementation. This is meant to make things even easier, and should be more efficient than most people would be able to using the fork/join framework. It also allows one to do so without thinking about recursive decomposition, and without optimizing thresholds!
The ParallelArray is based around regular arrays onto which operations can be applied, or on which mappings, filters and reductions can be used. To really appreciate it one just needs to play with it. But some guidelines to its use are:

• Filters must come before mappings. This is primarily to allow one to be able to estimate the performance of the expression.
• If you need a filter after a mapping, just finish the mapping with all() to create an intermediate ParallelArray
• The actual work is only performed in the final step of the expression (on a call to methods like all(), apply(), max(), etc.

The following is an adaptation from the JavaDoc. It determines the maximum score for this year’s (fictional) students:

Code:

References:
Concurrency JSR-166 Interest Site - Information straight from Doug Lea
Stick a fork in it, Part 1 - article by Brian Goetz (make sure you read the second part, too)
JavaOne session TS-5515 - the JavaOne session primarilly on the Fork/Join framework