The Lava Layer Anti-Pattern

Post date: Dec 21, 2014 4:35:7 PM

http://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-pattern.html?imm_mid=0c9406&cmp=em-prog-na-na-newsltr_20141220_control_images

Here are BAGIS' layers.

• 1. BAGIS Version 1: ArcMap VBA. The main reason to use VBA was that it can be deployed by the end users without admin involvement (so it doesn't need to go through lengthy federal government IT security clearance which could take months if not years). BAGIS V1 was distributed as an .mxt ArcMap map document template. This development practice was discontinued after the release of ArcGIS 10.0 which supports the "new" esriaddin framework.

  2. BAGIS V2, BAGIS-H, BAGIS-P: ArcMap .NET framework with sourcecode in VB. The migration from VBA to VB.NET was natural. The VBA code can be relatively easily converted to VB (see this page) and the final products can be easily deployed by the end users without needing a system administrator. In this iteration, we developed interfaces to work with ArcGIS ModelBuilder models and used .xml files as the major data interchange format.

  3. eBAGIS: ?. eBAGIS is a major departure from BAGIS desktop versions because of its net-based client-server framework. The reasons to move to this framework are to make data sharing easier and allow thin-client computer environment for potentially mobile applications which are beneficial for USDA field crews. There are many benefits associated with thin-client software architecture. One can find these claims through an easy literature search. At this point (December, 2014), we plan to use Javascript for developing the client-side interface and Python and Django for web-based geoprocessing. We also consider developing the client-side web interface as esriaddin (VB.NET framework) so that the net-based applications could integrate better with the ArcGIS desktop add-ins (from the users' standpoint). We have been delaying our web GIS development for some time due to the uncertainty associated with the wide selection of development frameworks. It's scary that we are finally at the jumping point. The good news is that we don't have any legacy web app codes to add to our layers.

To move forward, we should consider:

• • The continuing maintenance of desktop ArcGIS add-ins and their roles in BAGIS (including eBAGIS).

  • The recruitment of future project members. I'm lucky to have the current team, but it has been difficult to find skillful programmers among "typical" geography graduates. The software development environment that we select must be easy to use.

  • The integration with ArcGIS Desktop, ArcGIS Pro, ArcGIS Server, and ArcGIS Online. Why? So that we don't have to recode the geoprocessing routines/workflows that are readily available to us.