.NET Successors to VBA IDE and DOCELL are Needed

ArcGIS 10.0 (formerly known as 9.4) will be the last release to support VBA. Expect to be told to simply download Visual Studio Express for free, and create assemblies containing extensions, commands etc. that can be installed without touching the registry.

Still, I find it nice to have code that travels with the mxd. Since compilers are part of the .NET framework, it should be possible for ESRI to offer an IDE that compiles code stored in the mxd and runs it within the ArcMap (or ArcCatalog) process.

But Why Stop There?
It should also be possible to to generate MSIL for languages other than just C# and VB.NET. What would those languages look like? I suggest ESRI should provide small tightly focused languages that address specific problems – domain specific languages (DSLs) in other words. The System.Reflection.Emit or Expression Trees available in .NET could be leveraged to do this.

Take DOCELL, for example. This was a language introduced in ArcGrid (at 6.0.1?), and is nearing the end of its supported life. When ArcGIS was introduced, ESRI suggested that DOCELL scripts be replaced with ArcObjects code. A few lines of DOCELL code that could be interactively tested now require many lines of .NET code that must be compiled. A DSL would be an appropriate replacement for DOCELL.

In addition to DOCELL, DSL’s that operate on map topologies would be interesting. A lot of topology tasks involve trees. XPath is a good example of a DSL that finds nodes in trees based on patters. Suppose I have a water distribution network, and I’d like to find all valves on 6 inch pipes down stream from pumps with a particular capacity. This really isn’t much different from an XPath query. If there were an XPath equivalent for working with trees grown from map topologies, writing searches like this would be much easier. The details of recursion could be hidden.

Lex/Yacc for GeoCompilers
Maybe something similar to lex/yacc could be provided. A lex-like program would scan a geometric network (or topology) to produce tokens that a yacc-like program could use to create compilers. These compilers, in turn, would be used to compile programs written in a language specific to the geodatabase. Take the NHD geodatabase for example. Writing ArcObjects programs against this data model is a bit tricky for most ecologists whose primary skill is ecology – and not programming. Imagine a having different programming languages available specific to the NHD. This would make the ecologists’ job would be much easier. Compilers would live within the geodatabase where they would be updated when schema changes occur.

Web2.0 Routing Analysis

In a recent interview with Government Computer News, Jack Dangermond describes the differences between Google and ESRI. Google is focused on visualization, while ESRI is focused more on spatial analysis services with authoritative data.

In my opinion, Google’s iPhone routing application (described here by Peter Batty) constitutes spatial analysis for the masses – or at least for the masses interested in transit.

I think ESRI could compete with Google in this arena by providing a service where their business partners could develop Network Solvers to complement the one offered by ArcGIS Online. The architecture for integrating these solvers would be similar to that used by Network Analyst.

Instead of relying on advertising revenue, ESRI could offer something similar to Amazon Web Service’s cost calculator, but extended so that business partners could set a price for usage of their solver. This price would be added by ESRI to the ArcGIS Online bill sent to those who use the service, in addition to charges for cpu usage, geodatabase i/o etc., on a pay-as-you-go basis.

Put the Author back in Authoritative
Consider, for example a travelling salesman (TSP) solver. While there are some TSP algorithms that work on the client side, I suspect many might be too chatty and are best implemented behind the firewall. A business partner could develop a solver, expose it as a service, then sell a routing application at Salesforce.com’s AppExchange that consumes it.

If ESRI could also web-enable model builder (as I’ve describe here) the solver could also be exposed as a geoprocessing tool.

Wanted: XAML for Spatially Enabled Workflows

After working with XAML for a couple of months now, I’m shifting gears to enhance a data exporter I wrote several years ago.

I sure wish there were examples of spatially enabled Windows Workflow Foundation (WF) applications for this sort of thing. The glamor of Silverlight/WPF is overshadowing a lot of useful things XAML offers for workflow. David Chappell has a good overview of WF here. Indeed, it seems like XAML could be used to implement a lot of the vision outlined by Paul Torrens in his ArcNews article.

What I’d like to see is a thin-client IDE where I could graphically design spatially enabled workflows on a remote server. A good example would be a parcel notification system on a municipal web site. Instead of relying on city staff to write apps, a web site could be provided to allow citizens to design workflows around city activities that impact them. Maybe what is needed is a Spatial Activity Library (SAL) to complement the lower level Base Activity Library. Perhaps each geoprocessing function in ArcToolbox could be wrapped and made available in a SAL and published by ArcGIS Server.