Project Update: One year on

Around one year ago, I was working very hard on some unpleasant projects at work at what seemed like a dead-end position in terms of where I wanted to be in my career. One aspect of this was that I wanted to be hard-core developer where as my current position was more consulting-oriented for a particular vendor.

Not being in a development position for about 3 years prior, I wanted to try to get some development experience under my belt in order to help landing a job in the field I wanted to be in. Given that I was not getting this opportunity at my job, I felt contributing to an Open Source project would be personally gratifying and giving me the chance to get deep into the code of an application and prove myself.

I made it a goal of 2009 to contribute to an open source project. This was my intention.

I focused on World Wind, given my enthusiasm for NASA, space travel, and geography. It was C#.NET which was a language I hadn't used in years and seemed interesting enough.

I found the code difficult, it took a long time for me to make any contributions, at first this was because of lack of documentation, but also lack of clear process or community support. No fault of anyone on the WorldWind project but it seemed to continually lose support, members and momentum throughout my involvement in 2009. What I didn't realize when I started is that although WorldWind has the NASA name, NASA has officially moved all their support to the Java WorldWind SDK project and virtually abandoned the .NET version. Not only does this mean that their full time developers who originally wrote WW.NET no longer made any contributions, they also removed the JIRA defect tracking site for the .NET project. This makes it impossible to track our progress, or even determine the goals of what needs to be fixed. I even got frustrated with this so I created a "bug tracking" page on the World Wind wiki just so we had something tangible to work against.

So after a year spent part-time on this OpenSource effort, I have made a number of contributions, the largest being perhaps the download code refactoring. I've also contributed to the project management side by documenting issues and pushing along input and contribution from the team members still active. I regret not being able to get into developing new features rather than just bug fixing, but in the Fall of 2009 my real-world job took precedence as I was assigned a literal Death March project.

As things stand we have a stable build with a number of fixes implemented. We have been discussing making a release of this build as World Wind 1.4.1, but as of this week I am still unclear on what steps are done to build and package this release. I gather it involves updating the installer and getting NASA to do some testing to sign-off on the changes. At the very least we have been giving people guidance on how to build their own WW app from the latest source with our changes. I suppose my efforts will live on.

In 2010 I am considering embarking on a personal web-site project. This will probably take most of my time outside of work, but I am very excited about this effort as I have control over it and can make a difference. Contributing to World Wind was an good experience but I feel it is time to move in a different direction, at least for the time being.

How does Visual Studio include Referenced Libraries?

A problem was raised on the forums a number of times about World Wind building in Release mode.

If you checked out the source from SVN, and opened the project in Visual Studio, then tried to build in release mode you would receive errors such as:

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "Tao.OpenGl.Glu". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "ICSharpCode.SharpZipLib". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "Tao.OpenGl.ExtensionLoader". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\Apache2\htdocs\html\WWsrc\PluginSDK\T iledWFSPlacenameSet.cs(10,7): error CS0246: The type or namespace name 'ICSharpCode' could not be found (are you missing a using directive or an assembly reference?)

Answer given by forum member, James_in_Utah:

I think the problem is that those DLLs may not be checked in for the "Release" mode build. Try building in Debug mode. That should work. Then find the dlls mentioned, Tao.OpenGl.Glu.dll, ICSharpCode.SharpZipLib.dll in the Debug target directory and just copy them to the Release mode target directory. We really probably should check these into the release mode build target directory in SVN, but I don't have privs to do that.

I added these two .dlls to the Release folder in World Wind SVN and commited the changes.

This brought the question to my mind, this seems to be a bad practice to check in to source control the contents of the output directory. I see that the .dlls are referenced under project references. Shouldn't there be a way that on build it copies the required .dlls to the Release folder or Debug folder as necessary?.

Unfortunately no one on the forum seemed to have a response and a quick web search revealed no answers.

Stars3d fix

I commited my changes to the Stars3d plugin. This was Issue #4. After a few days this was registered by ohloh as my 3rd commit. Also after some time my kudos rank registered this work and bumped me up to level 4. Hooray (sarcasm).

Right now the dev forums for World Wind are like a ghost town, I've replied several times and not heard anything back, no one else is currently working on fixes, and the one guy who was, has not checked in his changes to the trunk.

Since I am so busy with work, I can't do more, would like to keep this momentum going forward and maybe pick up some interest.

I went to Amsterdam two weeks ago for work. Next week I will be in London for two weeks for the same. Doesn't look like I will work on this anytime soon.

ohloh kudos

It seems that when I made commits for the two fixes that ohloh did get updated and track my commits to SVN which is good. But although I have an account there with a username which is the same as my SVN login "ammianus" it didn't associate that those commits were made by the me who had set up the ohloh "ammianus" account.

I guess it makes sense, since these are external systems, how can ohloh assume that just because someone made a commit to some repository and they happen to have the same screen name that they are the same person. I guess it makes sense so people can't accidentally take credit for other's work, although it seems there is nothing preventing someone from maliciously doing so.

While my starting "Kudos" rank was 1 (lowest), it looked like the "ammianus" who was logged as making commits to WorldWind had a level 4 Kudos rank. I thought that was cool. But when I associated my ohloh account to those commits, my rank went back down to 1. I wonder if the system takes some time to update? We'll wait and see for the gadget on the right to update.

Meanwhile, while I was traveling last few weeks on business and generally busy with work, seems that all momentum on the WW.NET seems to have petered out. I'll try to kick start things, I have one more bug fix to commit up my sleeve.

Still working on issues

I am still working on the issues for World Wind 1.4.1. There hasn't been a lot of traction but at least one other dev was using my custom wiki bug tracker.

I did check in my Download code and Atmosphere plug-in fixes into the main trunk of World Wind code.

Now, I will start watching the WW project on ohloh for updates. Since I checked in to sourceforge svn using my ammianus id, my ohloh profile should reflect these commits to the WW project. Since it is my first check-in to trunk I don't know if it will work. They seem to refresh their statistics from SVN every 2 days or so.

Fire up the bug tracker

I feel like I have had a pretty productive weekend in terms of WorldWind accomplishments. This entry is actually on time and not stale at the time of writing which is also a good sign.

First of all I finally got my act together and created a complete bug tracking wiki-article on the World Wind site. This page has a table containing general information and priority to bugs, then for each bug I created a section in the bottom half of the page for more detailed description and comments. It probably took me an hour or two to develop this, it's not secure and has a lot of manual editing to update anything, but its something. Its the first time I've been on this project we have been able concretely state what we know needs to get done and to say who is doing what. I have not gotten a whole lot of response, but so far one other active developer has stepped up and begun fixing items from that list. I've picked up another item as well.

Setting up that page was one thing, the second task was to populate it with data. I spent most of this morning reading and replying to threads in the WW Bug Reports Forum. From this I tried to glean the data to see what issues had been found by users but never addressed. The sad thing was a number of threads more than a year old with no replies where I could see no fix was ever made. Ok, I've been at it for 6 months and have not fixed many bugs myself, so I can understand it. I don't like it too much though.

Maybe I enjoy "process", but I feel I am not alone when finding things like proper defect tracking help software development rather than are a burden. I have taken the initiative to provide this data and calling it out. I am not quite sure what the reaction will be from more senior developers, hopefully there will be more positive responses so I will continue.


On the front of fixing bugs, I took a look at two Issues I came across with "Plug-in" code. The first I looked at was the "Starfield" plugin. The issue with this plugin is that it loads by default on start up. However, if you try to uncheck it from the Layer Manager, it will not unload the visible background stars. I would like to go into the Plug-in architecture more later. But basically there is a single Stars3d.cs file containing the Plugin code plus some initialization and data files that get stored in a Plug-ins directory in the application folder. After some trial and error I got this to work by a simple line change in the Stars3DLayer class's Render(DrawArgs) method, approx inserted after line 151

if (!this.IsOn)
return;

IsOn is an inherited property of the RenderableObject base class for the layer. It gets set true or false by the LayerManager when the check/uncheck happens, there seems to be no other hook to the plugin itself when that event is handled in the LayerManager UI.

I made a further enhancement so that the SaveSettings(),ReadSettings(),Dispose() methods would actually save the sate of that check, either On or Off so that if you check it off, the next time you start WorldWind it will stay off (but still loaded).

Open Questions: I'm not sure if there is a some other way that the WW is supposed to know not to render a layer if IsOn == false?
Is there a "business" reason why they wouldn't want the plugin's last state (checked or unchecked) to be persistent?


The second issue I stumbled upon when trying to understand how the LayerManager worked by looking at other plugin code. I tried one called Atmosphere.cs which didn't seem to do anything but repeatedly cause System.NullReferenceException. I traced through this and found a fix pretty quickly. A summary of what I found and my fix can be found in this Bug Report thread


PS: Thanks to The Wandering Geek Blog for the tip on how to configure the blogger styles to render the code blocks nicely with a background. e.g.(Atmosphere.cs):
// Set new one (to avoid being clipped) - probably better ways of doing this?
float aspectRatio = (float)device.Viewport.Width / device.Viewport.Height;
device.Transform.Projection = Matrix.PerspectiveFovRH((float)camera.Fov.Radians, aspectRatio, 1, (float)(2*world.EquatorialRadius) );
device.TextureState[0].ColorOperation = TextureOperation.BlendCurrentAlpha;

Download Code checked in

This is also a few weeks late, I finished testing on the last weeks of my vacation in mid-July while still in Korea. The folks at WorldWindCentral were kind enough to provide me commit access to SVN, so I have started my own branch to check in the changes. So far this has not been commited to /trunk yet.

Here is the the URL for my shiny new SVN branch:
https://nasa-exp.svn.sourceforge.net/svnroot/nasa-exp/branches/ammianus

As far as the Download code I also I posted a detail list of the fixes I have done here:
http://worldwindcentral.com/wiki/1_4_1_Issues#Download_code_error_response_handling

Logical changes include new error response handling:
* 4xx / Client error are cached as failures and WW will not retry to download them during that session (cache is in memory only and cleared when WW is exited).

• 400 Bad Request


• 401 Unauthorized


• 403 Forbidden


• 404 Not Found


• 206 Partial Content


• 200 OK && Content length == 0

* 5xx / Server Error are recorded and a timeout period will begin before requests are allowed to this server again. A message is displayed in the top right of the UI stating the timeout length. If server response contains "retry-after" header, that period is used, otherwise default is 2 minutes.

• 500 Internal Server Error


• 501 Not Implemented


• 502 Bad Gateway


• 503 Service Unavailable

Changes made to source files:

* WebDownload/WebDownload.cs
* PluginSDK/QuadTileSet.cs
* PluginSDK/Renderable/GeoSpatialDownloadRequest.cs