Archive for December, 2006

Domain Specific Languages for GIS?

When I first heard about domain specific languages (DSLs) a couple of years ago, I figured there would soon be folks really digging into this for GIS.  The discussion here about GIS scripting is interesting, but would be more helpful to have a DSL discussion.  I guess ESRI’s modelbuilder is a DSL IDE, looks similar to the one discussed here.  I always liked the way unix allows you to chain commands together into one long single command, piping the output of one command as the input of another.  No IDE needed - its all command line.  Seems like unix-friendly DSLs would be a natural step for the opensource folks. OGC mentions DSLs here as “GML Application Languages”, but I can’t really follow this to anything concrete.

.

Flu Geography

I’ve seen a lot maps showing the spread of avian flu. I have not heard much discussion about how the flu might alter our spatial behavior or impact internet usage.  Likely the first thing will be to keep the kids home from school.  Many more employers will allow remote workers.  Instead of going to the stores, more people will opt for delivery.

All these changes will increase our reliance on the internet.  Internet facilitated home-schooling might reach a critical mass so that after the flu subsides many children may not re-enroll in public schools.  More offices may realize enabling remote workers is cost effective, not just during a pandemic.  Internet based grocery shopping will finally become profitable - viral marketing in the most literal sense.

Modeling Infection

Since this blog is about GIS programming,  let’s consider Conway’s Game of Life as a type of GIS modeling.  It would be interesting to see a tool that would allow you to load up some real-world GIS data into a dynamic layer, push a button, and say “there goes the neighborhood!”.  Property values seem to change in an infectious way.

New urbanism claims a 5 minute walk to get an ice cream cone is the litmus test of neighborhood health.  I think this could be modeled.  I wonder how the density promoted by New Urbanism will fare after a flu scare.  Suburban sterility may become more appealing.  Anyway, seems like a Game of Life approach could be used to model some New Urbanism.  Use parcels for cells and distance instead of adjacency.

Infection of Modelers

These are just ideas, but they may also be thought of as memes.  While I really like using ESRI software, sometimes I fear that its proliferation has effectively innoculated the geospatial community so that ideas that cannot be implemented with ArcGIS are simply ignored.  Think of it as herd immunity.

Just as gene therapy has been identified as having potential benefits, maybe the geospatial community should consciously enroll into meme therapy.  I think James Fee’s exploration of Manifold serves as a good example of this.

ArcSDE MultiUser Editing

I attended a new class offered by ESRI the past few days, “Managing Editing Workflows in a Multiuser Geodatabase“. It really does a good job of exploring “State Trees“. I’ve never really dug into state trees before, as far as I can tell ArcObjects doesn’t expose anything about them. I recommend this class to ArcSDE admins, but suggest waiting until Geodatabase Toolset (gdbt) has been ported to 9.2. In the class we spent a lot of time looking at State Trees by connecting dots on paper with ids from sql queries. In looking at gdbt help doc, there are tools to graphically explore state trees.
Since ArcSDE is now a “technology” included with ArcGIS Server (and no longer a “product”) it would be nice to see the folks over at the ArcGIS Server blog discussing ArcSDE. All you ArcSDE admins out there: make noise for ESRI to expose state trees via ArcObjects. This would enable arcobjects programmers to write lots of useful tools for you. Right now, writing a tool involves directly querying the underlying SDE_XXX tables. This sort of thing is normally avoided, but without any ArcObjects support, I don’t see any choice.

Somehow the current editoperation is tied to a state in the state tree. It’s good to see the new “IsInEditOperation” method, now how about the stateID ?

Also would be useful for a “BeforeSaveEdits” event that we could use to validate changes before saving (and pass back a cancel = true boolean to make the system not save).

The Long Tail of GIS Consulting

The Long Tail has been used to describe how small niche writers can become successful through the internet. Amazon is often mentioned, but I think eBay is an even better example. Joe Francica has discussed its relevance for geospatial data. I find it relevant to GIS Consulting.

Let’s say ESRI comes out with a new ArcObjects release. According to Kirk’s Law: Writing code is always more fun than documenting it, so documentation will always lag. This lag presents a business opportunity. Let’s say there’s some cool new functionality offered by ISomeObscureInterface. If you’re like me you search EDN, then Google. If you’re like some people, if you don’t find anything you whine about how evil ESRI seeks to impurify the precious bodily fluids of the geospatial community by releasing poorly documented ArcObjects libraries.

Or, instead, you could choose to exploit this opportunity. Dig in, figure out the interface and post code showing how to use it. There’s a good chance a prospective customer will find you. I once worked for a company that spent more money advertising than developing the skill-sets needed to deliver what the ads promote. It brings to mind the movie, “How to get ahead at advertising”.

For a business plan, instead of spending money on silly advertisements, it makes more sense to write sample code for poorly documented aspects of ArcObjects.

It is tempting to keep this strategy secret for competitive advantage. However, I think the more consultants that start doing this, the more successful the strategy. So, I encourage others to do as I have done. If you prefer a less mercenary view, think of this as nurturing an ecosystem where distributed cognition can thrive, maybe even resulting in hippy poetry.

Breadth vs Depth

It is just not possible to master all libraries of ArcObjects. The total area of understanding (breadth x depth) is limited by number of hours in a day. So the issue is how much time to spend mastering ISomeObscureInterface in depth instead of broadening into ISomeOtherObscureInterface. More specifically, is the long tail just for specialists? Solutions to complex geography problems require skilled generalists. I am hopeful that blogs will provide a marketplace where generalists may thrive as well. So maybe we will see an evolution of synoptic GIS planning discussions.

It all boils down to disintermediation: skilled consultants finding work directly for clients without funding an army of suits.