Archive for the ‘9.3 WishList’ Category
An iterative waterfall?
While Agile is on my mind, I thought I’d write a bit about Agile Geodatabase design.
Let’s say I follow ESRI’s steps from the bottom of this page to create a geodatabase.
1. With Microsoft Visio or Rational Software Corporation’s Rational Rose, design a geodatabase in UML and export it to an XML Metadata Interchange (XMI) file or Microsoft Repository. To learn how, see http://support.esri.com/geodatabase/uml.
2. Add the Schema wizard to ArcCatalog.
3. Generate a geodatabase schema from the XMI file or Microsoft Repository with the Schema wizard.
4. Once you have generated the schema, you can modify it with tools in ArcCatalog if needed.
5. Once the schema is ready, you can load data into it.
In step 4 let’s say I decide to modify the schema. At that point my schema is out of synch with my CASE model. It can quickly become a pain keeping the model in synch with the geodatabase. Then there is also the pain of keeping Data Access Layer Components (DALCs) in synch with the geodatabase. In essence, these steps represent a waterfall.
So here’s my suggestion: ESRI should provide a Geodatabase Designer within Visual Studio. It would provide a look and feel similar to the VS Class Diagrammer, but it would not replace the Class Designer. Instead, it would provide a graphical way of editing an XMI schema containing geodatabase types. A command would allow it to generate code (.NET classes) the way Dave describes here. Likewise, there would also be a command to synchronize the XMI schema with a geodatabase, as well as with the DALC’s.
I know this is all rather vague, but my point is until we have easy-to-use tools that support the round trips needed in iterative development we’ll end up with waterfall processes. Escher notwithstanding, waterfalls are very un-agile.
Update: Here‘s an example of how a designer can be built for Visual Studio.
With growing interest in Agile GIS development, this might be a good time to suggest how ESRI could make Agile easier. Since the Agile Manifesto demands frequent deliveries of working software, ease of deployment becomes more important. Below is a suggestion to make ArcGIS desktop more Agile by making it more like ArcGIS Explorer.
I really like how ArcGIS Explorer custom tasks can be installed by end users without Admin privs. Details are here. This capability is Agile friendly. With Desktop however, I don’t see an easy way to build installation packages that don’t require Admin privs for installation. Since many sites I work with require someone from the IT department (with Admin privs) to come install software updates, things can really slow down, especially around the holidays.
While it would be possible to write an ArcMap extension that discovers and loads extensions from .NET assemblies in a manner similar to ArcGIS Explorer, loading commandbars is problematic. Last time I checked, accessing IDocument.Commandbars inside of IExtension.Startup crashes arcmap. Extensions really need to all be loaded before commandbars since the commands on the commandbars often expect extensions to be loaded. So while I could have an extension that loads other extensions via Reflection, Activator.CreateInstance, and IExtensionManagerAdmin.AddExtension, I don’t see a way to do this for command bars.
The crux of the problem seems to be exclusive reliance on COM Categories for discovery of customized components. It would be great if ArcMap would also scan special file folders at startup. These folders would be named similar to the COM Categories, e.g. ESRI Mx Commandbars. Arcmap would then use Reflection to instantiate these objects at startup. I guess we might need some metadata telling it which classes I want registered, or maybe it would be OK if there is no metadata just assume that if a class implements IToolBardef, then it should get loaded.
How do we prevent someone from replacing our assemblies with malicious ones? I’m not clear if/how ArcGIS Explorer accomplishes this, but we should probably think about it. I guess strong naming could be used.
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.
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.