The Memory Leak

More discussion over at High Earth Orbit on neogeography definition.

While I’m sure many are tired of seeing this dead horse beaten, I do find value in discussing a use case often addressed by neogeography: crowdsourcing. As High Earth points out, the neo and paleo geographers would both be actors.

The problem is some of the tools needed to support crowdsourcing are not getting high enough priority by ESRI.

Case in point: ArcGIS Server’s GraphicsLayer.WriteToXml method would make crowdsourcing a lot easier. A Neogeographer draws graphics on the map, adds some attributes and saves it. Behind the scenes it gets saved to disk (via WriteXml, not arcsde via versioning). A Paleogeographer opens ArcEditor, retrieves graphicslayer to map, converts graphics to features, edits it and commits it to the geodatabase.

The only problem with this is a bug in WriteToXml. It was logged in August (NIM011262), but the SP4 doc doesn’t mention it as being fixed.

The slow resolution of this issue might give neogeographers the impression that ESRI doesn’t place high enough priority on crowdsourcing. The ArcGIS architecture needs to support crowdsourcing.

Pretend to Be An Architect
Speaking of architecture, have you ever noticed how so many architects live long and remain creative in their later years? Take a look at Johnson, Wright, and Venturi.

Contrast this with mathematicians, who seem to die too soon, e.g. Boole, Hamilton and Turing.

I think ageism lurks beneath the surface of the paleo/neo discussion. The GIS community is getting gray. A lot of fresh college grads focus on web design instead of cartography. If we can set an example by aging more gracefully maybe they’d be more interested in trying a few old school concepts. Perhaps the key to aging gracefully is to become more like architects and less like mathematicians.

A client has some ArcSDE performance issues that I need to look at.

As I have blogged earlier, the Geodatabase Toolset (gdbt) appears to be what I need. This is a freely downloadable unsupported extension.

There is still no 9.2 version of the gdbt. I don’t understand … why ESRI doesn’t post the source for this tool on arcscripts? I would understand if they were selling the product. But it’s free - what is the business case for not posting the source code?

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).