Archive for the ‘ArcGIS Server’ Category

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.

ArcGIS Server, Balkanization and Unintellisensibility

With five ArcGIS Server SDK’s to choose from, it would be helpful to have some sort of matrix summarizing relative strengths weaknesses of each. For now, it sure looks Balkanized.

I’m One of Those Types
Yes, I’m the type of guy who can’t stand stereotypes. You know, the kind that blurts out “generalizations are bad!” when cornered. Generally speaking, generalizations are bad – but not when it comes to IDE’s. I’ve gotten so spoiled on VS intellisense, working with javascript feels awkward. And not because it’s not an MS product – autocompletion in Sql Server Management Studio is quite annoying as well. From what I can tell, static types are what make intellisense possible. With Silverlight I can use intellisense to write all my client side code, if I so choose.

That may change with addition of dynamic types in C# 4.0. Generally speaking, dynamic types are a good thing, but it seems like it’ll make C# more like javascript. Here’s a good writeup showing how dynamic types simplify JSON interaction. Perhaps an understated advantage of SOAP over REST is static types. I guess as long as I have two monitors I’ll survive – with one of them eternally opened to the API reference docs.

Sense and UnIntelliSensiblity
Kirill shows how dynamic types can simplify use of COM libraries in .NET – at the expense of becoming unintellisensible.

This suggests ArcObjects programmers will be able to write code that is visually more elegant than currently possible – yet unintellisensible. It may look pretty during a code review, but I sure feel sorry for any non ArcObjects programmer tasked with altering it. It looks like it would even be possible to write an obfuscator disguised as a prettyfier. It would take Kirill’s first example, strip out the “using”, replace the static type with a dynamic type, and voila, prettier code.

Silverlight Mapcontrols, XAML, and GeoProcessing

Last week I dug into the Virtual Earth Silverlight CTP mapcontrol. Since most of my work involves C#, I like being able to write web apps without shifting gears to code in javascript. Silverlight lets me do this, plus it offers a performance advantage over javascript.

While the VE mapcontrol has some good samples, I couldn’t find what I wanted: a simple sample showing me how to interactively draw a polygon on a map. So I downloaded the ArcGIS Silverlight Beta mapcontrol. I found the sample I needed right here. I’m really curious what the equivalent code would look like for the VESL mapcontrol.

I was recently working with XML deserialization of Geoprocessor tools. I was trying to determine (and override) the logic used by the UI controls in the IMdElementEditor. I hit a dead end though. After working a bit with Silverlight, I think it would be great if the Geoprocessor were re-written around XAML.

If this were done, it seems like a silverlight version of modelbuilder could be offered. I would like to connect to my account at ArcGIS Online and use modelbuilder to create/edit and run models that operate on layer packages located on the server. The geoprocessing would occur in a sandbox on the server, with an option for the modeloutput to be a layer package on the server, or streamed back to me as an Element Layer. This sort of capability would help differentiate ArcGIS from Virtual Earth.