Calculation and Compilation in Arcmap

Who says a calculator can’t learn natural language ?

So whatever happened to VBA in the Field Calculator? Before 10.0 I grew accustomed to using VBA to leverage all sorts of geometry related interfaces. With 10.0 Esri has replaced VBA with Python and VBScript. I’m not sure why support for .NET wasn’t added, considering that both the C# and VB.NET compilers are part of the standard .NET Framework installation.

The .NET Framework provides modules that can compile source code and turn it into an assembly in memory. Maybe once ArcGIS supports .NET 4.0, I’ll adapt this proof-of-concept to use AvalonEdit. The Visual studio project files can be downloaded here.

    public CompilerResults Compile()
    {
        CodeDomProvider provider = CodeDomProvider.CreateProvider(m_Language);
        var parameters = new CompilerParameters();
        parameters.GenerateInMemory = true;
        parameters.GenerateExecutable = false;
        foreach (string reference in m_References)
        {
            parameters.ReferencedAssemblies.Add(reference);
        }
        //
        var results = provider.CompileAssemblyFromSource(parameters,m_Source);
        if (results.Errors.Count == 0)
        {
            var type = results.CompiledAssembly.GetType(TYPENAME);
            if (type == null)
                throw new Exception("type not found: " + TYPENAME);
            object o = Activator.CreateInstance(type) as IKalkulation;
            if(o == null)
                throw new Exception("unable to createinstance");
            m_kalkulation = o as IKalkulation;
            //
            if (m_kalkulation == null)
                throw new Exception("unable to cast to IKalkulation");
        }
        return results;
    }

That allows us take the dynamically generated class (that implements IKalkulation) and loop through each row in a featurelayer (or standalone table) performing the calculation using C# code entered into a form.

    while ((row = cur.NextRow()) != null)
    {
        i++;
        var obj = this.m_kalkulation.Kalkulate(row);
        row.set_Value(idx,obj);
        row.Store();
        //System.Threading.Thread.Sleep(300); use for testing cancellation
        int newPct = (int)((double)i * 100.0 / (double)total);
        if (newPct != pct)
            worker.ReportProgress(newPct);
        pct = newPct;
        if (this.CancellationPending)
            break;
    }

GIS: Where are the Languages at?

We spend a lot more time debating which general purpose language is better for GIS (C#, VB, Python, Java etc.) than we spend asking what GIS-specific languages should look like. Notice how the language choice is hidden by the compiler – it is an implementation detail. The job of the compiler is to convert human readable formal language expressions into machine language. In addition to general purpose languages like C#, VB.NET, etc., I think GIS deserves its own languages. Sure, we have the shape comparison language, but I think there is room for improvement. It should be possible to write codedom providers for things like rasters, topologies and networks.

Raster Languages

Esri once supported a product called ArcGRID which allowed several expressions (DOCELL, IF, and WHILE) that are no longer supported in Spatial Analyst. It would be possible for Esri to write a CodeDOM provider that would compile these expressions. Otherwise the same approach taken with the proof-of-concept could be adapted to work with pixels instead of IRows.

Topology Languages

Likewise, workstation ARC/INFO allowed one to easily find polylines where two polygons meet that have the same attribute – simply set up two RELATEs based on LPOLY# and RPOLY# and RESELECT the polylines based on expression where left and right attribute are not equal. In ArcMap this requires some tedious code. It seems like Esri could write a CodeDOM provider to allow topology rules to be used as search expressions and not just enforcement of business rules.

Network Languages

For geometric networks custom traceflow solvers are a very powerful tool. Imagine being able to utilize a language that made it easier to recursively build trees based on some network connectivity logic. Traversing the network using IForwardStar is just too tedious. A friendlier language is needed. Either a codeDOM provider or an IQueryable LINQ provider could support languages specifically geared towards network traversal – and would make things like ad hoc custom tracing easier.

Language is a virus. -William S. Burroughs

In other words, if your language doesn’t go viral, it won’t survive. With Stackexchange putting so many different carriers in close contact with one another, a new spatial language seems as inevitable as the next flu season.