OK, that bit of soap box behind me:
I actually started working with maps back at ANL when I joined the Visual Interfaces Section. Our little part of ANL wasn't like you would think of a government lab. We weren't handed money from a line item that made it into the US Budget. Nope, we were almost exactly like consultants. So we went out in search of organizations within the government, DoE and DoD, that had line item funding and were looking for how to spend it.
Enter our group, which convinced a number of folks that the new affordable computer craze (Sun workstations were starting to be seen as reasonable computing platforms) could help them visualize the reams of tabular data output from their models into more concise visualziations on maps. The military had models like TACWAR and AEM that took many input files and generated a model of a conflict between forces. Our idea: Put icons on maps and let you click on the icons and present the tabular information in windows that popped up as a result of those clicks. Cool!
Back in those days our development environment consisted of running SunView and using either vi in a shell window or textedit. Sad to say I had not yet been exposed to Emacs and the benefits of integrated GDB debugging. However Sun did have dbxtool and a decent version of make to help us create the applicaitons we wanted. Usenet groups had plenty of SunView programming knowledge and the documentation as well as the APIs seemed quite reasonable. I think the first set of machines I started on were Sun 3/260 boxes along with 3/50 and 3/60 boxes. These machines had the good old Motorola 68K processors in them and had resonable speed (OK not the 3/50 but then with only 4MB of memory and booting and swapping over the network you couldn't really expect it to). Most of the development was done on the 3/260 because it had the most amount of memory and a color display which was kind of important to draw good looking maps.
So one of the first applicaitons we did was put a little GUI front-end on the output of a model run. Show a map of the area, show little icons denoting forces, airbases, and what all, have an inidcatior allowing you to move forward in time of the model run and be able to click on icons to bring up information about them. Here's a sample picture (Please Note: Any and all images associated with the work I did were all generated from unclassified SAMPLE data! I never had access to anything else.)
As you can see there are coastlines and some rudimentary country boundaries being drawn along with the icon overlays. At this point the idea of how to build all this seemed fairly simple. But there were still two significant problems. The first was that we wanted the icons on the display to be animated and we didn't have a high-end graphics board in any of the machines at the time. The second, and far more limiting issue, was that none of us had any background whatsoever in the field of GIS! What is the difference between a projection, datum, or a coordinate system? There was plenty to learn!
First thing we had to do was settle on a projection and after reading up on a number of them we chose the Mercator projection because it was simple and it looked good when you were zoomed in a reasonable amount. It wasn't until quite a bit later that we learned about all the headaches with the aforementioned projections, datums and coordinate systems though we did support UTM fairly early on (as depicted above). Now we had to figure out how to draw the maps on screen. The early Sun framebuffers were 8-bit colormapped(indexed color) displays that allowed us to load the colors we wanted. But to animate the red and blue forces we had three choices.
- Use double buffering
- Our graphics card did not support double buffering :(
- Use XOR technique
- Unfortunately this causes colors to go all "disco" on you as something is drawn over something else and moves. It also presents somewhat of a problem when many things are moving at once.
- Draw as fast as you can
Only one problem. Our sponsor was coming to visit and we were giving a high profile demonstration of all our work to them. This wasn't working. Something in the input files was causing the application to bus error. Not segmentation fault, bus error! Major bummer! It is now the morning of the demo and our sponsor is there. The only machine(s) that can run the program are in the room that all the demos are going to be done in. I'm up about 2 hours in. I go sit down in the demo room and I sit down at the only other machine that can run the application. It is immediately to the right of the demo machine. I grab the monitor and pull it as far right as possible and start debugging with dbxtool! The demos start and after the first one completes Bob shoots me a knowing look with raised eyebrows. Done yet? I just shake my head no. I keep debugging. The sponsor looks over at me a couple of times. I slide my chair a bit further to the right (the room was small) and pull the monitor even more to the right. I keep debugging. About 15 minutes before I'm up I figure it out. I can't recall the exact problem but I do recall it was a stupid problem and wanting to blurt out an obscenity as I figured it out. I barely contained myself.
The demo went off without a hitch and more $$ kept flowing. Looking back on it I can't help but laugh at the experience. There were more like that. I had the pleasure of working with some great folks in our military during this time both at the Pentagon and at US Central Command. Stories for another time but I can't leave without giving you a hint of one of those stories. It revolves around the 13th and 14th octets of an Ethernet packet and US Central Command.
Sun Framebuffer History
Segmentation Fault vs. Bus Error why a bummer?
Posts
No comments:
Post a Comment