Archive for August, 2006|Monthly archive page
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.
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.
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?
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.