Archive for the 'Military GIS' Category

GIS on Wired Science

wired science

No mention of GIS Day on last night’s episode of Wired Science, but there was a nice demo of the TouchTable.

They find what appears to be a uranium enrichment facility and suggest “this is where you might send you UN inspectors”. What a concept!

I wonder how much the price for touch screen technology will drop now that production is ramped up for iPhones.

They start out with Google Earth, then switch to a more “Industrial Strength” tool from ESRI. I suspect its the same ArcEngine (GlobeControl) app demo’d at ESRI’s 2005 UC:

Work, Play & War

What does it say about us when the latest Playstation has so much more computing power than a Workstation?

Not so long ago it was GIS practioners who had to teach people to spatially navigate digital worlds. Now its the other way around. A new generation of users raised on computer games are demanding game-like experiences from GIS. When I heard people in the Defense User Group meeting demanding 3D dymamic display, I thought OK, ESRI just needs to migrate to the Playstation 3 platform.

However, after looking at this Dr. Dobbs article, I think it will take the deep pockets of a defense project. I remember Reagan looking at some kids playing first person shooter games and commenting that the games were “training tomorrow’s warriors”. The warriors are now trained, now they just need weapons like the ones they’ve been trained upon.

The World in Red and Blue

While the red state/blue state world view has gotten a lot of attention from cartographers, I haven’t seen anyone questioning the “red force”/”blue force” world view as practiced in military. For example FBCB2, which is used for “situational awareness” appears to have some “red force tracking” issues.
It appears the military brass is learning to celebrate diversity, but has not grasped the diversity of tribal regions along the Afghanistan/Pakistan border. Last night’s episode on Frontline, “Return of the Taliban”, was interesting, also Winston Churchill’s account of this region. Seems like situational awareness apps should support viewing the network of tribes along with all the alliances and feuds. Simply coloring them all red or blue won’t do.
Yes, the map is not the territory, but it sure is a lot easier to fold. Just need to get better symbology.

Topology and RDBMS’s

I just read through an interesting article by Joe Celko where he actually admits that “RDBMS is very useful, but there are problems in the world that cannot be done with deductive methods”. Joe then describes how a tool like Cogito that can do “graph theory” (i.e. topology) is useful for discovering relationships.

In my earlier post I discussed some limitations I see in using featurelayers to describe spatial phenomena that are not yet fully understood. Here is an attempt to elaborate further.

Suppose there is a soldier on patrol policing some foreign land. Let’s say this soldier is equiped with a tablet with GIS and Cogito (or something similar) on it. As he patrols he makes observations that populate a Cogito graph. Some (though not necessarily all) of the observations would tie to a feature on the map.

I wonder if ArcGIS’s topology engine could be adapted to provide functionality similar to Cogito. Cogito’s whitepaper doesn’t go into much detail on how it manages location. Interesting how Cogito’s graphics are similar to those produced by ArcGIS schematics.

PS - here’s a whitepaper that describes the graph database.

Layers and Holism

This recent article (”Layered GeoInt“) describes how “layers” will be used to achieve “holism”. I really feel the concept of layers often stands in the way of holistic understanding. For example, say you’ve deployed something to Arcmap users and they see something in the real world they want to put onto the map. There’s a good chance what they see does not fit neatly into a single layer. So what do they do? Odds are they end up marking the map up with graphics (IElements). If you’ve been a supportive programmer for these users, maybe you’ve provided tools to let them hang attributes off these elements as xml strings (in IElementProperties.CustomProperty).

Lets suppose you developed a mechanism to share these elements with the rest of the enterprise. Now what we need is a framework for doing the following to these elements: spatial selection, identify (like the Identify tool), and select by attributes. Basically all the tools that work with FeatureLayers are also needed for these IElements.

I submit that the FeatureLayer concept is really joined at the hip with Codd’s relational model. There’s been a lot written about the shortcomings of the relational model, for example here. Usually the criticism is followed by some sort of proposal for an xml database. What is needed is an ILayer for xml.

In that spirit, I propose a new class, XmlLayer, that would maintain a collection of XmlFeatures. There would be NO rule saying all XmlFeatures in an XmlLayer have to have the same geometrytype, or the same field definitions. This would solve the “feature level metadata” requirement. XSLT would be leveraged for rendering, import, export, etc.

Some concepts, e.g. an electric circuit, are comprised by features that live in different featureclasses. Maybe things like the GeometricNetwork and database Topologies could be expressed to the map as an XMLLayer. That way all the features comprising the circuit would be in on layer.

Certainly there are scalability issues, but those issues exist for managing large collections of IElements too. Maybe some day I’ll give this a try.