The Memory Leak

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.

When I first started blogging I thought I’d write only about how a GIS developer might go about programming applications. But in reading recent blog posts, I realized I’m missing half the story. So, here are some thoughts on how GIS developers get programmed.

As discussions between adherents of different programming packages and methodologies become heated, I find it helpful to look at several things: Nostalgia, the Stanislavski Method of Physical Action, and the Stockholm Syndrome.

Nostalgia

This word was originally intended to describe what we now refer to as “Post Traumatic Stress Disorder“. I’ve seen many a user succumb to this when a sofware package they know & love gets replaced by something “better”. When Arc8.0 came out many programmers became nostalgic in the original sense of the word. I still occasionally hear people wish for the return of AML … but lately this has been nostalgia in the modern sense of the word.

Stanislavski Method of Physical Action

This method of acting involves going through a lot of repetitive physical action in rehearsal to get inside of an emotion. I wonder though, when people repeat the same series of physical keystrokes/mouseclicks over & over if somehow there’s a common emotional state at which they arrive?

Stockholm Syndrome

Sometimes, at first, using new software can make me angry. In looking back, the hardest to learn software has often turned out to have the most lasting impact. I haven’t used vi in years. It was hard for me to learn, yet I remember it, and wish I could use those keystrokes in editors today. I’d like to think these fond memories are based on sheer utility, but I suspect there’s something else going on, perhaps as a hostage I’ve become loyal to my captor?

We’ve all heard the jokes about “drinking the koolaid” of a particular software vendor. Seriously though, maybe we should think about what sort of vulnerabilities to mass hysteria evolution has wired into our genes as we seek recognition from our group’s alpha male.

In sum: not only do we program software - software programs us. We need to be conscious of this.

I read about VCs putting money into location based spam. To me this is the wrong approach. I’ll just start turning off my cell phone. It’s an annoyance with no benefit.

When I go into Google Maps and “Get Directions” from one address to another, I would like to see a button at the bottom that says “save my journey”. Pushing this button would save the path described. Google could then offer a broad range of services based on journeys I’ve saved. Any service they offer me that uses my journey could also present an unobtrusive ad for a business somewhere along that path.

Here in San Antonio the service might include alerts from TransGuide. Better yet, Google could track my progress along my saved route to determine traffic conditions via cell phone geolocation, similar to Inrix’s dust network. Of course this would take a critical mass of subscribers, but Google’s good at getting massive. In exchange for letting Google track me, and send me ads, I would get accurate traffic conditions.

Journey based advertising could be very focused. The location of the origin and destination of a journey would provide important demographics so that a business located along a journey could target their ads. Who knows, maybe Starbucks might start building cafes in poor neighborhoods if they knew the demographics of the cars driving past.

I really like the new file based geodatabase.  It seems to me that this means ESRI could bring back some of the good ol’ direct access methods … remember RELATE with the LINK option?  Remember in avenue how quickly you could iterate through a bitmap?  I know, I know … it’s not proper relational db practice, but hey, its fast.  Maybe a selectionset bitmap class could be offered in ArcObjects?

A few years ago there was a lot of interest in native xml databases. But not much recently. ESRI mentioned supporting “feature level metadata”, but not sure what happened there either. If they did do that, I’m sure the next thing people will want is a way to query features in a featureclass based using XQuery instead of Sql. Seems like it should be possible to write a custom layer XmlLayer (that implements ILayer) and provides something a bit more xml-centric.

In addition to questioning whether spatial is indeed special, maybe we should be more general and ask if the relational database model is always best for geospatial datasets. This becomes apparent to me when I think about feature level metadata. One man’s metadata is another man’s data. If ESRI stores metadata in a bag hanging off the side of each feature, people will have difficulty querying it. Perhaps ESRI should push for an OGC standard for spatial XQueries of native XML databases, then write wrappers so that tabular (georelational) featureclasses could appear as if they were bona fide Xml documents, and therefore XQueryable.

FUD factor: if ESRI doesn’t do this maybe Google will. I really would like to upload my cross - town commute as a polyline into google so that I could search for products sold by stores that I drive past. This would be yet another ad revenue stream for Google.

Long ago I remember writing DOCELL routines for ArcGrid. Apparently this is no longer supported. However, it is possible to write a lot of tedious ArcObjects code to loop through each pixel in a PixelBlock. It seems like it should be possible for ESRI to use CodeDOM so that a user could write just a single method that gets called by ArcGIS for each pixel. This method would be added to code generated and compiled at runtime.

I wonder how hard it would be to put ArcPad on a PDA, strap it onto a Lego Mindstorm robot and have it run a data collection mission. If you had a swarm of these all tied to a control station, it seems like you could use this as a testbed for hardened robots for serious applications like fire detection.

Seems like more geographers should be following the efforts of people finding ways to use the graphics card for general programming. I had always thought you could only do integer operations on the graphics processor, but here’s an interesting paper describing “float-float” operations. I suppose this means one could handle double precision geometries from a 9.2 geodatabase. I wonder how much faster building topology could be done on the gp. Maybe there could be an option on the topology toolbar that would allow me to leverage the graphics card. Granted each graphics card is different, but it should be possible to write adapters to abstract away the differences.

I’m surprised Chris Scotese hasn’t ported his plate tectonic modeling applications to ArcGlobe.

Long ago (well, not that long geologically speaking) I worked on integration of ARC/INFO with a plate tectonics modeling package. Plate movement through time is described as a sequence of rotations about a pole. These movements are inferred from geologic field work that is constantly being refined, or at least updated. The math gets really hairy, but it seems like internally ArcGlobe has to perform these calculations anyway. If ESRI were to expose a method that allows a polygon to be rotated about an arbitrary pole a specified number of radians, then porting a plate tectonic app would be a lot easier. Even better would be if I could take a sequence of rotations and sum them all up to a single rotation.

I really like seeing the cool stuff people are doing with 3D GIS. It could be improved, however, if fly-through paths were based on laws of aerodynamics. Granted, putting aerodynamics into GIS would be a major undertaking. But what about taking an open-source flightsim package such FlightGear, and use it to generate flight paths that the GIS would then use for generating animations?

Or, maybe add a globecontrol to flightgear so you could be flying through your GIS, controling throttle, flaps, etc.