Archive for December, 2007|Monthly archive page
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.
Normally San Antonio has a leisurely pace, but with only a few shopping days til Christmas, its been a bit more hectic. Part of the reason we chose to live in San Antonio was for the pace of life. Other places seem more rushed. The recent cold weather also seems to a factor, perhaps triggering some hunter-gatherer hoarding behavior buried in my nordic evolutionary memory.
I wonder if the perception of time is somehow related to latitude? The sense of time doesn’t seem to get much attention from geographers. Which one of our five senses is used for time? How many San Antonio Minutes = one New York Minute?
In his book Lies My Teacher Told Me, James Loewen describes an experiment he conducted in Vermont. This seems like an easily reproducible experiment – very quantitative. He suggests class perceptions are the only factor here, but I think geography (latitude?) is also big factor.
Several years ago, two students of mine provided a demonstration: they drove around Burlington, Vermont, in a big, nearly new, shiny black American car (probably a Lexus would be more appropriate today) and then in a battered ten-year-old subcompact. In each vehicle, when they reached a stoplight and it turned green, they waited until they were honked at before driving on. Motorists averaged less than seven seconds to honk at them in the subcompact, but in the luxury car the students enjoyed 13.2 seconds before anyone honked. Besides providing a good reason to buy a luxury car, this experiment shows how Americans unconsciously grant respect to the educated and successful. Since motorists of all social stations honked at the subcompact more readily, working-class drivers were in a sense disrespecting themselves while deferring to their betters.
VGI Mobile Traffic Cams for Time challenged Parents?
Michael Goodchild writes about where we might be headed:
A third type of sensor network, and in many ways the most interesting, consists of humans themselves, each equipped with some working subset of the five senses and with the intelligence to compile and interpret what they sense, and each free to rove the surface of the planet.
Are we there Yet Daddy?
I think cars as sensors will happen first, specifically as mobile traffic-cams. I don’t think much intelligence will be required to collect the data, and the data will be most valuable when freedom to rove is restricted (i.e. stuck in traffic). It would be great if I could click on a map and get real time video feed from cars ahead on the map I could decide which alternate route to take to the mall. I read somewhere that people often prefer paths that allow them to drive faster instead of paths that get them to their destination slightly sooner. I bet even more so when they have kids in the back seat.
That’s all for now, someone’s honking so I better go.