The Maine Department of Environmental Protection (MDEP) has been pursuing Enterprise GIS development to the limits of the available tools for the past nine years. This development effort has utilized many different technologies, and a broad range of personnel. This paper is an attempt to give a general snap shot of a point in time in a continuing effort. We will make revisions to this information available on our web site as we gain new understanding of the new technologies and how best to apply them to real world problems.
This paper is a cooperative presentation. The biographies of the authors are included in Appendix C. Our team includes:
| Christopher Kroot | Maine DEP |
| Michael Smith | Maine DEP |
| Stuart Rich | St. George Consulting Group |
| Jason Sardano | St. George Consulting Group |
As our development efforts proceed, we are constantly exploring new technologies to see if we can use new tools to do a better job of delivering requested functionality to our users. We are currently very involved in learning the Unified Software Development Process (USDP) and it accompanying Unified Modeling Language (UML). We believe that consistent use of this process and its associated modeling language will allow us to more clearly communicate design objectives and functionality between our users and our developers.
We are also closely monitoring the emerging object relational capabilities of the Oracle database platform. It would appear that there are dramatic new opportunities to integrate ArcSDE with the Oracle Spatial Option of Oracle 8i. These advances should allow us much greater ability to integrate our spatial data with our relational environmental data. We will know much more about these capabilities in the next few weeks.
We will revised editions of this paper, our power point presentations, and all of our accompanying design documents available on our web site. Design documents from 1999 are included in a section labeled Appendix A. Design documents for 2000 are included in a section labeled Appendix B. In order to get the latest copy of this information, log on to http://www.stgeorgeconsulting.com and follow the links to Esri_UC2000. If you do not find the information there that you need, please feel free to call any time (207) 594-3048.
This section of our paper was created by Christopher Kroot of the Maine DEP.
Building an Enterprise Wide GIS using ArcInfo 8.0, Oracle, and Citrix
The Department of Environmental Protect has identified 110 staff that could benefit from the use of a Geographic Information System (GIS) that integrates spatial and attribute database access and querying capabilities. Staff would also require the capability to produce both hardcopy maps and attribute reports. The MDEP has spent eleven years building its GIS program and now in the process of developing an Enterprise GIS to deliver this functionality to users. The process of developing and implementing this GIS is complicated by the DEP having one main office and four regional offices. The users in these offices have a broad range of responsibilities, and though there are overlaps in program areas, there are requirements that are unique to each program area. The DEP continues to conduct user analysis sessions to identify these requirements and to work with staff to design and develop solutions.
The DEP utilizes Esri Geographic Information System (GIS) software as its standard for GIS. The DEP has developed applications in ArcInfo 7.x, ArcView 3.x, and Map Objects 2.x. The DEP has implemented the Esri Spatial Database Engine (SDE). SDE is built on top of an Oracle RDBMS and enables the DEP to server spatial data to its regional office from a central database. These software products provided useful applications for the DEP, but none were able to deliver on the requirement of an integrated, enterprise wide GIS that integrates spatial and attribute database access and querying coupled with map creation and production.
The MDEP joined the beta program for ArcInfo 8.0 in 1998. ArcInfo 8.0 promised to enable GIS application developers to develop and implement an integrated enterprise GIS application.
Esri has provided users with a large array of software packages that have strength ranging from: geoprocessing, application development, ease of use, data automation, cartography and map production, spatial data serving, integration with RDBMS, and internet services. This has fostered the use of many software products which become expensive to maintain and difficult to use. ArcInfo 8.0 enables an organization to provide the services listed above within the framework of a consistent development environment.
The MDEP uses an iterative approach to software development. The idea is to identify the major software development requirements and develop models to determine the feasibility of development. This insures that that most difficult and risky components of the system are developed first. Problems that require changes in scope can be identified quickly and prevent costly changes later on. Each successive iteration includes additonal functionality and a higher level of specificity. Each iteration starts with modeling which is validated by users. This model is then used to develop the next prototype. The prototype is verified against the model and by users, then the process starts over again.
The DEP has learned through experience that frequent interaction between developers and users is critical to creating the best end product possible. This is especially critical when using an iterative approach to software development. A high level of developer and user interaction on an on-going basis provides both developers and users with valuable information as the application progresses. This enables the developers to learn more about what the users do for their daily work, and for the users to learn more about what Geographic Information Systems may do to assist them in their daily work. Many of the end users are still maturing in their understanding of GIS and how it may be used to assist them in being more productive in their work. The DEP considers this high level of developer and user interaction necessary in order to insure the development of the highest quality Enterprise Geographic Information System.
The MDEP has adopted the Unified Software Development Process (USDP) for the development of Enterprise Geographic Information Systems. The USDP is a software development process and it purpose is to provide a standard methodology for turning user requirements into software systems. The MDEP still has a lot to learn about the USDP, yet so far has found it to be the best methodology for developing Enterprise Geographic Information Systems. There are three main concepts in the USDP; Use Cases, Architecture Centric, and Iteration.
In the past the MDEP has used Functional Hierarchy Diagrams (FHD) to diagram user requirements. An FHD consists of boxes with a single user requirement in each box. These user requirements were taken directly from user interviews and put into the box exactly as described by the user. For example “Create a buffer” or “Import a CAD file” or “Overlay soils on wetlands”. These diagrams were very good at capturing and diagramming simple user requirements. They provided a valuable communication tool for the programmer and the user to insure that the required functions were developed. The FHD has limited abilities to specify how data will be interacted with. The MDEP has used Entity Relationship Diagrams to diagram the databases required for our applications and the associations between entities. The ERD is useful to communicate the four basic levels of cardinality; one to one, one to many, many to one, and many to many. The ERD will not enable the designer to capture the myraid of other relationship/association information that exists when our databases are considered in respect to organizational workflow; such as: a well may not be created if there is not an associated site, if a well is deleted then all samples related to that well must be deleted, if a permit application is received then a master facility ID must be setup and all other program databases must be searched to determine if the facility already exists. In order to capture these types of relationships and others, the MDEP is learning how to create all information system documentation using the Universal Markup Language (UML). The UML is a standard set of terms used to describe the models used to develop information systems.
Use Cases are similar to the FHD in that they capture the user requirements, but the similarities end there. Use Cases have two other critical types of information that they capture.
1) The Use Case documents who all the users are who may utilize the function, not just the user who described the functional requirement during a user interview
2) The Use Case asks the all important question what is the value to the users. What organizational objective does the function support and how important is it to the organization.
The second major concept in the USDP is that it is Architecture-Centric. The first step in this process is to identify the use cases that have the most significant impact on architecture. Knowing the functions and their value to an organization by itself is not enough. The Architecture considers the entire universe in which the software system will operate. It will help answer a number of critical questions:
1) The overall organization of a software system
2) The major organization workflow processes that the system interacts with.
3) The system software required
4) The application software required
5) The development tools required
6) The hardware devices required
7) Networking and telecommunication requirements
8) Legacy systems
9) Standards and policies
10) Non-functional requirements such as reliability, reusability, stability, performance
11) Distribution requirements
12) The behavior of the interfaces and interactions of the structural elements listed above as described in collaborations
13) Which structural elements are static (meaning that there is limited or no capability to change) and dynamic (meaning we can change to meet the requirements determined by the use cases)
The third major concept in the USDP is iterative and incremental development. The overall system is divided into modules of small projects. The idea here is to identify the use cases which require functionality that is the most difficult to realize and that will extend the current functionality of the software system. These modules to realize these use cases will be developed first. One of the objectives here is to minimize the risk. Instead of completing the functionality that realizes the easy Use Cases first only to find out that the system cannot be built when trying to realize the more challenging use cases, or that the realization of the more challenging Use Cases requires the simple Use Cases already complete to be redone.
Once the most challenging Use Cases have been identified they are then broken down into the smallest possible components. The development of these components are in turn broken down into a series of steps. Each step will go through incremental development where each increment realizes additional functionality.
The MDEP has identified general categories of users that require use of the enterprise GIS.
|
An initial requirements analysis identified the following user considerations:
· May not know what data is available Spatial & Attribute.
· Do not want to have to look for the data.
· Should not have to create basic cartography..
· May not know how to perform spatial/attribute queries on RDBMS.
· May need to share projects via networks.
· May need to distribute products via networks.
The initial user requirements analysis with MDEP senior management identified the following requirements:
· Build an Enterprise-wide system with centralized databases and applications.
· Limit the number of software and hardware components.
· Allow single point of access to department wide data.
· Access and distribution via networks.
Property Issues:………..
1) Where to place new wells/public wells.
2) Where excavations have to stop.
3) Is a building permit required.
Decisions at public meetings
1) Whose property is affected.
2) Who will fund drilling/remediation.
3) Contamination, safety, drinking water decisions.
Program funding
1) Reports to EPA for NPL funding.
DEP/EPA reports
1) Why MDEP requires building
City/municipal decisions.
If excavations required maps point out where not to dig due to utilities, road, electric, sewer
Monitoring well placement
Site excavation planning
Replacement well location
Placement of vapor extraction sheds
Public water supply filter placement/concern
Distance measurement
Determining contamination of plumes
Topological analysis using contours
Spatial referencing of residential locations in relation to contamination.
Assess future potential risks to ground water and the environment
Tank placement sensitive areas
Where to conduct sample
Distance to MW, PW, DW from contaminated water source
1) Do we need to sample for certain contaminates
2) Do we need to drill new well because of distance from contamination, tidal water, or ground water elevation change.
QA/QC of consultant data
Do analytical results corresponds with monitoring well locations.
· Core applications shared by all users
o Map Atlas Creation
o Integrated Spatial and Attribute Queries.
· Specialized components for specific needs:
o Planning
o Ground Water Protection
o Emergency Response
o Air Quality
Etc……..
The MDEP GIS Unit developed the following guidelines for software tools to utilize for development.
· All applications are modeled and well documented.
· Case tools: Oracle Designer 2000, Visio 2000 Enterprise
· Department wide Business data in Oracle.
· Small databases in Microsoft Access
· Spatial Applications ArcInfo 8.0 technology.
· Visual & non-visual objects coded in C++.
· Prototyping using Delphi.
· Modify ArcInfo 8.0 and Manipulate custom objects using Visual Basic for Applications.
In order to develop an Integrated Enterprise Geographic Information System the MDEP is in the process of customizing ArcInfo 8.0, ArcCatalog, ArcMap, ArcSDE, the Geodatabase, and Oracle. This system is being developed using the following software:
· Oracle 8.i and Oracle 7.x
· Esri ArcInfo 8.x, ArcMap 8.x, and ArcCatalog 8.x
· Esri ArcSDE 8.x and the Esri Geodatabase 8.x
· Developing prototypes of COM objects
· MS Visual C++ for coding COM
This section of our paper was prepared by:
Michael R Smith
Senior GIS Programmer/Analyst
Maine Dept. of Environmental Protection
Once MDEP's use cases had been identified, the process of building a hardware and software architecture could begin. The use cases determined the need for users to access the system anywhere via the Internet or WAN, use the system regardless of what type of computer they had, share projects, have centralized data and applications, link directly to Oracle business tables, and have excellent cartographic and analytical capabilities. MDEP, through an iterative process, was able to construct a system which meets all these use cases in a manner that utilizes mostly existing technology and is cost-effective. MDEP's solution utilizes thin-client software from Citrix, data serving software (SDE) from Esri, GIS software (ArcInfo 8) from Esri, database management software from Oracle, NT-based application servers, and a single UNIX data server. This paper will outline the technical details of MDEP's systems architecture, focusing on the servers, network, OS, and out-of-the-box software used.
MDEP used an iterative process in designing a system that satisfies the use cases. The first step was to identify all the possible solutions which satisfied most or all of the use cases. We considered the following scenarios:
1. Web-enabled GIS using ArcIMS
2. Desktop GIS with ArcInfo 8 on user's desktops and data served over improved LAN/WAN architecture
3. A thin-client approach serving ArcInfo 8 from a centralized server
After examining the above three options, we determined the thin-client approach using ArcInfo 8 was the best choice to satisfy MDEP's use cases. We did not consider using ArcView because previous experience showed that it does not fully support SDE and relational databases, and because using a standard customization language in ArcView (such as Visual Basic) is cumbersome. We did not consider using ArcExplorer due to its extremely limited cartographic and analysis abilities. ArcIMS was not suitable for us because it lacked out-of-the-box capability to do most GIS analyses, did not support the geodatabase, and had very limited cartographic abilities. We previously tried Map Objects, but that product had many of the same limitations as ArcIMS, plus connections to Oracle were very slow. We initially considered a desktop implementation of ArcInfo 8, but determined that was not acceptable because our WAN could not support GIS data transfer without costly upgrades, and users PCs would also have to be upgraded and converted to Windows NT. A desktop implementation would not have worked over the Internet either, thus not satisfying one of the key use cases. Once MDEP determined that the thin-client ArcInfo 8 solution would best satisfy the use cases, we deployed the architecture in several iterations:
1. A borrowed low-end NT Citrix server from a local Citrix reseller with ArcInfo 8 (Beta II) running on it, querying an MDEP low-end NT server with ArcSDE 8 (Beta II) as the database and Oracle 8.0.5, servers connected using 100Mbs Ethernet. Testing showed this configuration could support 6 concurrent users with acceptable performance.
2. A new MDEP Dell PowerEdge 6300 server with 2 CPUs running NT, Citrix MetaFrame, and ArcInfo 8 (PreRelease), querying an MDEP Sun Enterprise 4500 server with 1 CPU running Solaris 7, ArcSDE 8 (PreRelease), and Oracle 8.0.5, servers connected initially at 100Mbs Ethernet and then upgraded to 1000Mbs Ethernet. Testing showed this configuration could support 12 concurrent users with acceptable performance. Consultation with Sun/Oracle informed us that we would first see contention with lack of RAM and disk I/O. Testing indicated that this was true, and plans were made to upgrade RAM and buy a faster disk array.
3. Upgraded the Dell to 4 CPUs, and the Sun to 2 CPUs, also added memory to both. At this stage, we were running ArcInfo 8 (Release Candidate II) and ArcSDE 8 (Release Candidate II). Testing showed this configuration could still only support 12 concurrent users due to I/O contention with SCSI bus.
4. We added a Sun StorEdge A5000 fiber-channel array to the data server to reduce disk I/O contention and support 24 concurrent users in this fashion.
5. Long-term plans involve adding a second Citrix server and doubling the resources on the Sun to support 48 concurrent users, and moving all Oracle business databases to the Sun.
The iterative process is key to our deployment, because it allows us to test and scale up along the way. It also follows the Rapid Application Development (RAD) concept, because user feedback is received at every step of the iterative process. No new iteration is made without testing the previous one and getting feedback from users about what improvements need to be made.
MDEP determined to use separate data and application servers. This decision was based on the eventual need to load-balance application servers, and to eliminate complexities with trying to maintain redundant servers with data. The need to load-balance servers was a side effect of ArcInfo 8's reliance on NT and Intel architectures (which are limited in scalability, thus requiring multiple servers). NT/Intel servers are typically less reliable than their UNIX counterparts, so system redundancy (accomplished by having dual servers) satisfies the system reliability use case. RAID 1 for operating system disks was provided for additional reliability. System policies were enabled which denied the user's any ability to write data to application servers. MDEP's thin-client approach required us to use a terminal environment. The use cases were best satisfied using ArcInfo 8 desktop applications (ArcMap, ArcCatalog, ArcToolbox). Since ArcInfo 8 desktop applications require Windows NT, we chose to use Intel-based servers with Windows NT Server 4.0, Terminal Server Edition (WTS) and Citrix MetaFrame Server 1.8. The thin-client approach is possible without using Citrix software (using only WTS), but there are several drawbacks which we preferred to avoid:
· WTS cannot publish applications, only desktops (users get confused having a desktop within a desktop), Citrix can do both
· WTS requires roughly 30Kbs per connection (uses RDP), Citrix only 20Kbs (uses ICA)
· WTS only works with Windows clients, Citrix works with Windows, DOS, Macintosh, Linux, UNIX, OS/2
· WTS does not support load-balancing, Citrix does
Our first iteration test server was a generic PC with a single 200MHz Pentium Pro CPU, 512 MB RAM, and a single 9GB SCSI drive. This server was used only as a prototype, to see if the concept MDEP had created would work. We tested it and found it suitable for 6 concurrent users.
Once the prototype had been shown to work, MDEP purchased a more robust production server, a Dell PowerEdge 6300, initially equipped with 2 500MHz Xeon CPUs (2 MB cache), 1GB RAM, 100Mbs and 1000Mbs Ethernet interfaces, 2 9GB SCSI drives (configured in a RAID 1 array), and a 4mm DDS-3 tape backup device. This server was initially used during the beta period for ArcInfo 8, and served Maine DEP's GIS beta group (a group of 12 users selected to test the effectiveness of our architecture in their daily regulatory work). Testing showed that it could adequately support 12 concurrent users. After the beta group approved the design, MDEP went ahead with plans to upgrade to an architecture that could support 24 concurrent users, by buying 2 more CPUs for this server, an additional 1 GB RAM, and 2 more 9 GB drives (to support expanded pagefile). This server should support 24 concurrent users (testing is pending the arrival of a fiber-channel storage array for the server). MDEP's plans eventually call for adding a second, identical application server and Citrix load-balancing software.
As stated before, MDEP determined to use separate data and application servers. The consolidation of data in one place was a primary use case which is satisfied by having a single data server. Another use case satisfied with the data server was the need for the architecture to be extremely robust, reliable, and scalable. With the application server, the need to use ArcInfo 8 forced MDEP to use Intel-based servers with Windows NT. However, this requirement was not in place for the data server. With the exception of an initial test server on NT, we chose to use a UNIX-based data server for storage of all data. This server's file systems were divided (from the user's perspective) into two areas - those with RDBMS-based data and those with standard file systems. Our initial test server was an IBM PC 300PL with Windows NT Server 4.0, 192 MB RAM and 2 IDE disk drives. This prototype server was only used to test conceptually whether our model of separated servers would work. The performance under NT and on this small server was too poor to consider using in a production environment. MDEP determined that the best server to satisfy its use cases was a Sun Enterprise 4500 because of its extensive scalability. During our initial testing, the data server had a single 400MHz UltraSparc CPU (4 MB cache), 1 GB RAM, 100Mbs and 1000Mbs Ethernet interfaces, a 6x9 GB SCSI disk array, and a 70GB DLT backup device. Software included Solaris 7 as the OS, Oracle 8.0.5 as the RDBMS, ArcSDE 8 (beta II and later, PreRelease), ArcInfo 8 workstation (for command-line work), and Samba 2.0.4 (to provide SMB file services). Testing indicated that, when using the 1000Mbs Ethernet interface, this configuration was capable of hosting 12 concurrent SDE users. MDEP's protocol for deployment of this system in a production environment was to be able to support 24 concurrent users. To meet this goal, we upgraded the data server to 2 CPUs and 2 GB of RAM. Consultation with Sun engineers and monitoring of server resources indicated that we were experiencing excessive disk I/O contention, which would need to be alleviated prior to supporting 24 concurrent users. To this end, MDEP has ordered a Sun StorEdge A5200 fiber-channel disk array, which will increase disk array bandwidth to 100MBs. When this is implemented, we will be able to support 24 concurrent users with this system. Other long-term plans include adding 2 more CPUs and 2 GB RAM to support 48 concurrent users, and additional hardware resources to support hosting of all MDEP business databases on this server. Our choice of a scalable UNIX-based server was based on these long-term goals which are not practically realistic with Intel-based servers on Windows NT. Reliability of the system is a key use case; this is why we chose Sun hardware for our data server (our experience is that Sun equipment is unsurpassed in reliability, you set it up and it just works). RAID 1 disks for the operating system will provide increased reliability, we have not implemented this yet.
In addition to the above data server, an older DEC 5/250 Alpha server running Digital UNIX v4.0.D is used currently for serving business databases using Oracle 7.3.4. This server has a single 275MHz Alpha CPU, 512MB RAM, 67GB of disk space, and a 10/100Mbs Ethernet interface. Many of these databases could be linked back to spatial data through the use of complex queries, if that were supported in the architecture (unfortunately, Esri still doesn't support this in any of their products, so it must be custom coded). Long-term plans are to phase this server out of production, putting these databases on the Sun.
A major use case that had to be satisfied by this architecture was to allow all users to access the system, no matter where they were, or what type of computer they were using. Another one was that users had to be able to share projects, including printing to remote offices, or collaborating with users in different offices. These use cases were addressed in both the choice of a thin-client architecture and the abilities of MDEP networks and the state WAN. MDEP has a central office in Augusta, and serves 5 remote offices as well. In addition to these offices, users want access at home or in the field through the Internet. Testing indicated that, when using a Citrix thin-client solution, our existing networks would suffice, with the exception of the link to our Presque Isle office (56Kbs). That office is slated for a WAN upgrade to 384Kbs, so it will have plenty of bandwidth then. DEP LANs vary from 1000Mbs backbone and switched 10/100Mbs to desktops in our main building, to shared 10Mbs for all users in some of our regional offices. We initially started a major LAN upgrade to support a desktop ArcInfo 8 implementation, but ceased this when we discovered the utility of Citrix (legacy 10Mbs shared LANs and slow WANs are more than enough for Citrix in most cases). The state's WAN supplies connections varying from 100Mbs to 56Kbs between state offices, and 6Mbs of Internet bandwidth. A firewall prevents direct ICA connections, but users out of the state WAN (at home or in the field) can access MDEP's system either through 56Kbs remote access links, or using a VPN software. The key network components for our architecture are:
· An extremely high-speed server backbone (switched 1000Mbs Ethernet) so large GIS data files can be quickly served to the application server. This portion should be switched, to provide the maximum throughput between application and data servers.
· Enough LAN and WAN bandwidth to support simultaneous Citrix sessions (minimum of 20Kbs per session).
Thus the existing LANs and WANs, with their proposed upgrades, coupled with the use of a thin-client architecture, provided us with the means to satisfy the above stated use cases. Additionally, the high-speed network link between data and application servers provided fast response times and adequate performance for users.
Most of the identified use cases could be satisfied with out-of-the-box software. We chose the following software packages:
· Windows NT Server 4.0, Terminal Server Edition (WTS) - NT is required to run ArcInfo 8 desktop applications, and this is the only thin-client version available; satisfied the use cases pertaining to our choice of ArcInfo 8 (see below), if at the expense of the use cases pertaining to stability
· Citrix MetaFrame Server 1.8 - provides numerous enhancements to WTS, including a thinner protocol (20Kbs minimum), ability to publish applications, load balancing, and client independence; satisfied the use cases pertaining to universal access over networks
· Solaris 7 - UNIX operating system for Sun computers - far more reliable and robust than NT, useful for most enterprise applications. We chose this platform for our data storage and serving
· Oracle 8.1.5 (8i) - provides the relational database management for our data
· ArcSDE 8.0.1 - works with Oracle to serve and store spatial data as Oracle records
· ArcInfo 8.0.1 - provided us with the extensive tools necessary to meet use cases involving advanced cartography and analysis, as well as use cases arising out of data management needs (geodatabase)
· Samba 2.0.4 - provided us with the ability to store PC-based filesystems on a UNIX server using SMB share services, this is the area where users may store projects and small data files, sharing them with other MDEP users; satisfies the universal access and project sharing use cases
· Custom software - some additional custom software was required, which was in general written as COM objects using Visual C++ and Visual Basic. See the following paper for details.
Testing was done to satisfy use cases pertaining to system stability and performance, as well as to ensure compliance with other use cases. Extensive testing was done at various iterations in the development process, and is outlined in a separate document (Citrix deployment document) at http://janus.state.me.us/dep/gis.
By examining available commercial products, most of the use cases were satisfied. With this architecture, users had universal access to their data and projects, had the ability to share these universally with any other MDEP employee, and still had all the cartographic and analytical tools they needed. The few exceptions could be custom-coded due to the open programming interfaces of the software selected. This deployment architecture has proven to be very effective for delivering GIS applications to any of our users on the state WAN. We have plans to create a similar architecture outside the state firewall in the future to deliver these applications to stakeholders outside of the State system.
Data Management and Integration for Maine DEP Enterprise GIS
This section of our paper was prepared by:
Stuart Rich
Some of the most important user requirements at the Maine DEP involve the integration of spatial data with environmental data stored in complex relational database management systems (RDBMS). While we have made great strides over the past twelve months in our ability to develop and deploy sophisticated GIS applications over the Wide Area Network due to advances in application tools and system architectures, there are some serious data storage and management issues that remain. We are hopeful that some of the recent advances in RDBMS technology will resolve some of these issues.
As we began our user interviews a number of years ago, there were a number of user requests that consistently surfaced as priority users needs. Our users were consistently requesting the following types of functionality:
For the past several years, we have been searching for a spatial data model and set of software tools that allows us to deliver on a significant segment of these user requests. While we are making some significant progress in some areas, we are still frustrated by our inability to address some of these core requests.
One of the more important and difficult use cases that we identified early on in our analysis was the need for users to integrate their spatial data with their environmental data in real time. This is a need that we have been pursuing for some time with frustratingly few results. The databases that store our environmental data tend to be large, complex relational databases. There are typically many layers to these relational models with the relationships being enforced with compound keys. (The primary key for the table is made up of several fields.) The development of solutions to these problems requires a choreography of development tools, spatial clients, and spatial data management platforms. We have attempted many different solutions to this critical problem. Among them:
ArcInfo 7.X Some of our early development work was done with command line ArcInfo and AML. Much of our more complex spatial data management and sophisticated cartography is still done with ArcInfo 7.X. ArcInfo 7.X is still the most powerful spatial data management application available. The coverage data model is still the most reliable complex data model. Having said all that, one of our most important objectives as an organization is to move GIS to a mainstream technology that is an integral part of every user’s desktop application set. This objective will clearly never be achieved with command line ArcInfo.
ArcView 3.X We made some initial attempts at integrating spatial and environmental data with ArcView 3.X but found that this architecture had many fatal flaws:
Map Objects. We did some very interesting projects with Map Objects and found that the ability to integrate the Map control into a modern development environment opened many exciting possibilities. It is possible to create some very elegant spatial applications with Map Objects that allow the user to interactively investigate the spatial relationships that exist within their environmental data. Map Objects development still has some major drawbacks however. The printing capabilities of Map Objects are extremely limited and there are no real data management tools where one might create interesting spatial relationships.
ArcIMS. We are very early in our trials of ArcIMS. From what we can see so far, this tool has great potential as a general spatial communications tool. From a developer’s point of view, ArcIMS offers an elegant object model to modify and extend to create simple applications for users to interact with pre-determined spatial analyses. From the point of view of our DEP users, however, the cartography capabilities are still very limited and there are very limited data management capabilities.
ArcSDE. We have been road-testing ArcSDE for several years now. There are some significant advantages to spatial data management with ArcSDE. In the first place, ArcSDE offers all of the security and stability that you would expect of the Oracle Relational Database Management System (RDBMS) that serves as its foundation. And because of the spatial indexing structures that are built in to ArcSDE, it is possible to serve up very large spatial datasets with outstanding performance. As an added benefit, ArcSDE is the only Esri spatial data format that is visible to all of the Esri client applications.
The Geodatabase. One of the most exciting new capabilities of ArcInfo 8 is the Geodatabase. This new technology allows users to create new and innovative spatial data models. It allows developers to manipulate and extend these models in new an interesting ways. From the point of view of a GIS analyst attempting to model our complex world, the Geodatabase represents a huge advance in available technology. For all of its promise, however, the Geodatabase still has a number of pretty serious limitations:
Oracle Spatial. Over the course of the past several years, the major RDBMS vendors have developed spatial extensions to their database platforms. Leading this effort has been Oracle with what was initially the Oracle Spatial Cartridge, and is now an integral part of Oracle’s Enterprise Database Server (Oracle 8i). While these new database capabilities are still maturing, some of their spatial data storage capabilities are already very powerful. Oracle Spatial fully supports the new spatial extensions to the SQL language allowing users to do many types of spatial queries from an SQL prompt. The major promise of this type of storage architecture is that it will allow for the development of data models that fully integrate spatial and business data to the point where the distinction finally becomes inappropriate. Current limitations of this technology include rather crude spatial data management tools, (import & export utilities etc.) immature geo-processing tools and a general lack of client applications to directly utilize this spatial data (although MapInfo is moving very rapidly in this direction).
In order to try to determine what the most promising system architecture is for us, we have been doing a number of small scale, iterative tests and design refinements as we slowly weed out those technologies that either do not work, or are inappropriate for our user’s needs. This testing regimen is focused on two general areas of interest:
These tests are focused mainly on testing the “out of the box” functionality of the various data models and determining how the various client applications can utilize the new data model. For instance, we have performed the following tests:
We converted coverages to shape files and tested the performance of serving them over the network. For specific information on this performance testing, see the Maine DEP web site for their deployment paper. (http://janus.state.me.us/dep/gis/) We then converted the same coverages to SDE layers and ran the same performance tests. We found significant performance advantages to serving SDE layers over the network, particularly when zooming in on large, dense datasets. However some of the complexities of the coverage data model (the inter-relationships between the various components of a region coverage for example) are lost in the conversion to SDE. Even with the performance advantages of SDE, there are serious network implications to serving large extent dense data layers over the network. These network implications must be addressed either with an application centric approach that enforces certain scale sensitivity constraints on the users, or with a systems architecture approach that moves all spatial clients to a server centric model (Citrix) or both.
We have attempted all manner of combinations of spatial clients, and development environments to determine which is the most appropriate deployment architecture to meet our user’s needs. We have found that there is no single deployment architecture that meets all of our user’s needs, but rather that the most appropriate architecture is dependant on the types of functionality that are required and the audience that that functionality is being delivered to. For instance, we have found that very high-end geo-processing and very sophisticated cartography are still best served by command line ArcInfo. Simple interactive map publishing to an anonymous audience is probably best handled with ArcIMS. But for the most of the needs of the internal users at Maine DEP, the most effective deployment architecture that we have found is ArcInfo 8 with narrowly focused custom extensions served over the Wide Area Network (Intranet) with Citrix.
The testing of our custom extensions of ArcInfo 8 require much more input from our user community. It is very important for our developers to get a lot of input from the user community throughout the development process. Our developers are on site at Maine DEP several days a week and we try not to invest more than a week’s worth of development time in any portion of the system without some sort of feedback from users. When we have run into problems in our development, it has almost always been because we either did not do enough analysis and modeling to fully understand the functionality required of us, or we went too long between check in with our user community.
At the time of this writing (May 31, 2000) we are anticipating some major architecture testing to be done over the course of the next few weeks. We will soon be upgrading our systems to Windows 2000, Oracle 8.1.6, and ArcSDE 8.0.2. We hope to have initial performance reviews of this new spatial data architecture to report at the User’s Conference in San Diego.
Over the course of the past twelve months, we have made significant advances in our ability to deliver integrated GIS capabilities to the users at the Maine DEP. We still have some significant limitations in the core functionalities of the tools available to manage and store our data, but it would appear that the foundations are being laid to resolve many of those obstacles. We anticipate that the integration of ArcSDE and Oracle Spatial technologies will deliver some exciting new capabilities over the course of the next twelve to twenty four months that may truly enable Enterprise Wide GIS capabilities.
Technical Notes for the Maine Department of Environmental Protection Atlas Creation System
This section of our paper was prepared by:
Jason Sardano
St. George Consulting Group
The Maine Department of Environmental Protection (MDEP) users frequently produce map series to answer spatially oriented questions. During the production of these atlases, the users spend a vast majority of their time performing repetitious work. The idea behind the Atlas Creation System is to automate as much of the repetitious tasks as possible, allowing the users to focus their skills on more demanding work. The Atlas Creation System does this in the following ways:
· Allows the user to define a grid which will control the indexing of the atlas maps
· Store the id’s of the selected atlas grid cells
· Persistently symbolize features based on MDEP standards
· Perform a batch print job on the chosen grid cells
ArcMap will be the host application that will serve up the Atlas Creation System. The user will push a custom button on ArcMap’s toolbar to invoke the Atlas Creation System. Once pressed, the button will display a dialog box; which will ask the user if he or she would like to create an atlas or open an atlas. If the user chooses to create an atlas, then the Atlas Creation System will present the user with another dialog box. This dialog box will prompt the user for various bits of metadata; i.e. the user’s name, the purpose of the atlas, the data layers that are part of the atlas, etc. If the user chooses to open an atlas, then the Atlas Creation System will present the user with a different dialog box. From this dialog box, the user will specify which atlas they are interested in opening. The metadata stored by the Atlas Creation System will be displayed to the user as an XML page. If the user is satisfied by the data, then the user will respond to the dialog box and the Atlas Creation System will take the appropriate actions and populate ArcMap with the specified data. When an atlas is opened, the Atlas Creation System will display another dialog box that is used as an overview of the atlas. This dialog box will print the appropriate maps of the atlas when the user interacts with the dialog box. The user will interact with this dialog box while editing the ArcMap using out-of-the-box functionality.
Originally, the Atlas Creation System was to be developed using C++. After reviewing the requirements of the software, it was determined that tasks required of the Atlas Creation System could be implemented using Visual Basic. To conform to Arc Info’s COM-based architecture, the Atlas Creation System was created as an ActiveX dll. The architecture of the Atlas Creation System was built using the strategy of Generalization. The Atlas Creation System consists of 6 classes: 1 that is an active class and 5 that are passive classes. The classes are as follows:
· AtlasManager (Active Class)
· AtlasCreator
· AtlasOpener
· AtlasIndex
· AtlasPrinter
· AtlasXML
The AtlasManager class controls the lifetime of all the other classes listed above. It is responsible for determining what the user’s request is, and to send that request to the appropriate class. User requests are handled through the use of forms. Since the forms are private variables in the classes listed above, they are not listed as part of the class structure.
If a user needs to create a new atlas, then the user will ask the AtlasManager to create an instance of the AtlasCreator. The AtlasCreator contains a form that the user will use for metadata entry. If the user successfully enters all of the appropriate data on the AtlasCreator’s form, then the AtlasManager will read this data into memory. After storing the data, the AtlasManager will call the AtlasXML class to store the atlas information to an SDE table as a BLOB.
Once the atlas’ metadata has been created, a user can open the atlas; the AtlasManager also controls this. The AtlasManager will make a call to the AtlasOpener object, which will display the atlas metadata to the user as an XML page. When the user decides on which atlas to open, the AtlasOpener will send a message to the AtlasManager; signaling the AtlasManager to open the atlas. The AtlasManager will invoke the AtlasXML to open the atlas.
The AtlasXML class has two functions, to load an atlas or to save an atlas. When the AtlasXML saves an atlas, it will write all of the AtlasManager’s data to an XML stream and save it to disk temporarily. Next, the AtlasXML will examine the SDE table to see if the atlas has already been saved. If the atlas has not yet been saved, then the AtlasXML will save the XML file to the SDE table as a BLOB. If the atlas has already been saved, then the AtlasXML will still save the XML file to the SDE table as a BLOB, as well as save the ArcMap document which displays the atlas’ data in another SDE table as a BLOB. When the AtlasXML opens the atlas, it explores the SDE table to see if the atlas’ ArcMap document has been saved in the SDE table as a BLOB. If the ArcMap document exists as a BLOB, the AtlasXML will save the BLOB to the file and load the ArcMap file into ArcMap. If the ArcMap document does not exist, the AtlasXML will read all of the data stored in the XML BLOB and load the appropriate data into the current ArcMap document.
The AtlasIndex class contains a form that displays the State of Maine as well as the atlas grid that was chosen by the user. The form will allow the user to select the individual grids (a grid is a regular geographic frame based upon USGS quads, scale at a given page size etc.) that they want to be a part of the atlas either by manually selecting the grids or by doing a theme on theme selection between features and the grids that they “lay on”. The AtlasManager will read the ids of the selected grids and store this information to the XML BLOB.
Once it is time for the user to print the atlas, the user will ask the AtlasManager to print the atlas. The AtlasManager will call the AtlasPrinter to perform the printing task. The printing is accomplished by zooming into the extent of each individual selected grid cell, switch the ArcMap view to layout view, printing the contents of the layout view, switching back to the map view, zooming to the extent of the next selected grid cell, and continues until all grid cells have been printed.
This section of our paper was prepared by:
Ben Knight
St. George Consulting Group
The Data Form is an application specific object designed solely for MDEP to use in viewing water quality monitoring information for specific sites and/or wells. The goal of creating the Data Form was to provide MDEP users with a multi-leveled view of water quality data. There are four levels of data: Site, Well, Sample, and Parameter. Each level has multiple fields that contain important data such as location, concentration, and owner information as well as many other things. The form provides a complete presentation of all of the attributes in the Groundwater database organized into functional categories on a multi-tabbed interface. This presentation allows the user access to several different layers of the data model in a single, intuitive form.
The Data Form is a multi-tabbed form with one tab for each of the main levels and additional tabs on each main page for additional information. It returns vast quantities of data based on a spatial feature selection of Sites and/or Wells in Arc Map.
Since it is based on a spatial feature selection, and since the Query Builder System can be used to create spatial feature selections, the two objects can be very interactive. Yet they provide very different views of the resulting data. Whereas the Query Builder System returns specific fields of information all mixed together in a single grid or on a single form, the Data Form provides all possible information in a neatly organized and grouped format.
The form is implemented as an ActiveX control created with Borland Delphi5. This ActiveX control surfaces several properties and methods to the Windows environment. By utilizing these methods and properties within the VB environment of ArcMap, we are able to synchronize the display of map features with the active records on the data form.
This section of our paper was prepared by:
Ben Knight
St. George Consulting Group
The purpose of this document is to describe the concepts involved with creating a link between spatial data and business data. While this ability is important it hasn’t yet been addressed by Esri or anyone else completely. Yet at this point it appears that the tools are available to create the link and provide users with a relatively simple way to ask questions of both their spatial and business data.
The goal of the Query System is to provide users with the ability to extract useful information from both their business data and their spatial data individually or simultaneously. Of course there are many things involved with the realization of this goal. Some of these sub-goals consist of:
1. Allowing the user to ask questions using SQL without forcing them to become experts in SQL.
2. Allowing the user to see the location of the spatial features that the data relates to and/or the data that relates to a specific feature.
3. Allowing the user to combine business data queries (attribute queries) with spatial data queries (spatial queries).
4. Allowing the user to save and re-execute these queries at a later time or date.
5. Allowing the user to view their business data in multiple ways.
Each of these sub-goals has important implementation implications.
The Structured Query Language is a very powerful way to extract information from a database, if one knows how to use it. If one doesn’t know how to use SQL then getting useful information out of a complex database can be frustrating and possibly seem impossible for anyone but “data gods”. Obviously this is a problem, but there are two obvious solutions. Teach everyone SQL, which could be expensive and time consuming, and probably not something that the users want to spend time doing. Or, Provide the users with a Query Builder.
A Query Builder should be easy to use and yet at the same time provide a great deal of power. The method that we have chosen to go about providing this ability involves a drag-drop interface where users can see a visual representation of the tables of the database. From these tables they can drag fields that are appropriate to the question that they want to answer. Then they use a simple interface to describe values to return or to count, sort or group records. When they execute the query it will return (hopefully) the information that the user was going for, at which point they have a number of options, including viewing the results and saving the query.
Depending on the results of a query a user may want to view the data in any number of formats. Some of these might include a spreadsheet-like view, a form view, or a chart or graph. Each of these methods has their own variables as far as formatting is concerned and so each can be treated separately with the caveat that they should all be able to interact with the format of the result of the query.
By putting ArcSDE 8 in Oracle Spatial we can easily include the fields of the tables that represent spatial features. We can also easily create the link between spatial features and the business data that accompanies them. Once the user includes a field that represents a spatial feature as part of the query it is possible to get the Feature ID and Feature Class name. With these two pieces of information it is possible to manually create a selection in Arc Map of the features returned by a business data query.
While seeing a group of features is neat, it’s not really useful. What is more useful is to be able to see which specific feature is tied to the specific data that the user is viewing. This is accomplished by means of a custom made COM object that draws individual features with a symbol that can be specified. This object is used to change the size and/or color of the specific feature (line thickness in the case of line/polygon features) to denote that it is the “active” feature, again through the knowledge of the Feature Class and Feature ID.
There are two ways that spatial and business data queries can be combined. The first is by using the capabilities of Oracle Spatial to include the spatial part of the question with the business part all in SQL. The second way is by creating a feature selection in Arc Map and a business data query through the Query Builder. Since both of these methods have the same final type of result, spatial features from a known Feature Class and with known ID’s, it is relatively easy to combine results from both queries to obtain the union, intersection, or difference of the two result sets.
Saving a business data query is very simple since the final result of it is basic SQL. However there currently doesn’t seem to be anyway to intercept a spatial query generated by a user in Arc Map. This is a critical limitation for our designs as many of the analyses that our users do on a daily basis require saving a spatial selection to be re-executed at a later date.
The ability to save queries is very important, esp. for users at MDEP, since any output must be reproducible. Since it is easy to create queries that could be very difficult to exactly reproduce it is imperative that users be able to save these complex queries so that they can be exactly reproduced at a later date. Another difficulty here is that the data that the query returns may change frequently. This makes it necessary to save the data as it was when the query was executed, with the obvious answer here being versioning. However, the good folks at Esri implemented versioning such that the entire Geodatabase is replicated whenever a new version is created instead of replicating a single feature class or, even better, simply recording changes. What this means is that whenever an important, frequently changing feature class needs to be recorded, larger, unchanging or rarely changing feature classes are also copied. This has serious implications on processor usage and the sizing of data storage systems.
This section of our paper was prepared by:
Amar Das
St. George Consulting Group
Maine Oil Spill Application System (MOSIS) is a software system that allows different groups of people with varied backgrounds effectively communicate, organize, manage, decide and act in the event of an oil spill on the Coast of Maine. MOSIS is intended to be most useful in the first 48 hours of response after a spill occurs.
MOSIS is a legacy application at Maine Department of Environmental Protection, which is currently being rebuilt using ArcInfo 8 technology. The first MOSIS was built in command line ArcInfo. Later on, it was revised using ArcView and went through multiple iterations as ArcView was upgraded. In all these renditions of MOSIS, system developers failed to deliver many functionalities requested by the users. This was mainly due to the immaturity of GIS in terms of dealing with an enterprise wide database, and cartographic limitations of ArcView compared to ArcInfo 7 and earlier versions. The current ArcView version of MOSIS is used locally by Maine DEP, USCG, Cleanup companies and the oil industry. The new Arc 8 application will be accessed over the internet.
MOSIS divides the entire coast of Maine into a grid system, which is sequentially numbered. This allows people at the command center to effectively communicate with the response people in terms of exact location and deployment strategies for operation response (mitigation) equipment. It allows even a novice user to create and print a map. Users can easily add booms, response vessels, staging areas, vacuum trucks, command posts, and skimmers to the map and produce an operational response strategy. Plumes can be animated for predicted wind speed and water current. NOAA trajectory model data can be downloaded, interpreted into SDE layers and displayed. NOAA charts can be displayed as a backdrop image, which are of immense help for the Coast Guard. Other uses include managing user access by predefined privileges, GPS data conversion into SDE layers sent by response personnel, querying and updating the related business and spatial database, exporting the enterprise database to a personal instance, publishing maps to the web, and mass e-mail generation.
DEP uses an iterative development process for all its system and tries to promote maximum user interaction. The Unified Modeling Language (UML) is selected for building a model to promote user interaction with the system developers and for system developers to incorporate distinct solutions for each user requirement. For the current revision of MOSIS, use case diagrams are built from existing user requirement definitions in MS Word and Designer 2000. From the use cases and scenarios, class diagrams are built considering the tools that will be utilized for MOSIS development. It is important to note that both of these diagrams are evolving as changes in user requirements and upgraded abilities of the tools used in MOSIS development evolve.
Prototypes are built after completion of the class diagram using integrated development environment (IDE) such as Visual Studio and Borland. Interested users are encouraged to talk with the developer at any stage of build. Once completed, the prototype application is presented to the users. User reactions are carefully captured. Subsequent changes are made to the logical, physical and build stages as deemed necessary.
The cartographic and analytical abilities of MOSIS will be built using ArcInfo8 technology customization. Both business and spatial data will be stored in a centralized Oracle database. Spatial Database Engine (SDE) will provide for spatial database access and management. The system will be built as an Arcinfo8 extension and will be deployed on a Windows NT Terminal Server hosting Citrix Metaframe and ArcInfo8. Oracle will reside on another Unix machine running Sun Solaris. Users having access to DEP’s network will access the system using Citrix client on their local machine.
Though MOSIS matured in the last couple of years, there are still certain functions that can not be implemented using the current tools. Some of these limitations in MOSIS capabilities arise from inability to declare a group of keys as primary identifier for a SDE layer and conduct database joins based upon that key, inability to save a complex spatial query for later use, inability to store images as SDE layer and inability to persist layers symbol at the database level. We hope future development in Arcinfo8 and related technologies will allow us to overcome these limitations.
The MDEP considers its development strategy of using ArcInfo 8.0, Oracle 8.i, and Citrix a huge success. The MDEP currently has trained 30 staff in how to use ArcInfo 8.0 out of the box. The fact that users can access the applications from any of our 6 office buildings, share projects, and have fast response times has made the initial deployment a huge success. ArcInfo 8.0 out of the box provides much more GIS functionality to general MDEP staff then ever before.
There are functional requirements that ArcInfo 8.0 does not provide to our users. This functionality is being developed as extensions to ArcInfo 8.0. Our users have viewed the first prototypes of the Atlas Creation and Query Systems and have validated that the new systems will deliver the required functionality. The MDEP expects to beta test the new applications in the fall of 2000 and put them into production in the winter of 2000.
The objective of limiting the number of software products used in GIS was also successful. The MDEP and its developers now can focus on Oracle, ArcInfo 8.0, C++, VB, and Delphi.
The MDEP has tested providing access to MDEP staff ArcInfo 8.0 projects to staff in other state agencies. These tests have been successful, enabling MDEP staff and staff from other state agencies to share projects and work cooperatively from their respective offices.
The MDEP has tested having developers who work off-site in their own offices access MDEP servers to do development work. This testing was successful and provides a great benefit in the development process.
The MDEP will use the custom applications that we are currently building as the foundation for an Enterprise Wide Geographic Information System that will support all of our business requirements. The MDEP will use the Atlas Creation and Query System, and the Print System to create products to support regulatory decisions in all program areas (Air, water, land, watersheds, coast, lakes, etc….). The beauty of this is that all program specific extensions will utilize the same core extensions (Atlas Creation, Query, and Print System) and out of the box ArcInfo 8.0. This makes it easy for users and efficient for developers.
The MDEP has over 200 staff that require training in GIS. One hundred of these will actively develop projects and conduct analysis, the rest will utilize products created by the first 100. The MDEP evaluated the Esri virtual campus and determined that it did not meet the training requirements of MDEP staff. It was clear that the MDEP could not afford to send staff to Esri for training of to have Esri come and provide in-house training. The cost would be way to high.
The MDEP GIS unit has created a custom ArcInfo 8.0 training class. This class consists of over 300 power point slides and 200 pages of exercises. The class begins by discussing the issues surrounding a ground water contamination site in Maine. The class covers ArcCatalog, ArcMap, and a little of the ArcToolBox. The class takes the user through all of the steps from acquiring and adding data, converting data formats, symbology, querying, and cartography. The class also discusses other software products that are used like Adobe Illustrator and Rockware graphing software. The functionality of ArcInfo 8.0 is taught in the context of a real life project, where the user learns the required sequence to follow and each of the steps.
The MDEP has taught the class twice to beta users and three times to general MDEP staff. Staff like the fact that the class has continuity and teaches the functionality in the context of a site assessment.
The MDEP has many ArcView projects that provide analysis capabilities required in the future. These projects will be recreated using ArcInfo 8.0 out of the box and the custom ArcInfo 8.0 extensions. There are no tools to automatically do this migration at this time. The MDEP staff with the assistance a contractor will manually recreate these projects.
Please see our web site (http://www.stgeorgeconsulting.com)
Please see our web site (http://www.stgeorgeconsulting.com)
Christopher Kroot is the manager of Geographic Information Systems at the Maine DEP and the President of Training & Research on Environmental & Ecological Systems (TREESystem). The primary focus of Mr. Kroot’s research and development over the last ten years has been to develop enterprise information systems to be utilized for environmental and ecological modeling, mapping, and decision making. The challenge has been to design, develop, and implement enterprise information systems that provide organizations with the capability to integrate large environmental spatial databases with business data stored in relational database management systems. A key objective has been to develop enterprise information systems that would enable the scientist, researcher, regulator (etc.) to access, manipulate, and analyze data themselves, without the assistance of a computer professional. Mr. Kroot’s recreational passions include rock and ice climbing, high altitude mountaineering, sailing, kayaking, biking, and swimming.
Michael R. Smith is senior programmer/analyst in Maine DEP's GIS Unit.
He is responsible for administration of spatial data and the GIS servers, acquisition of new data, GIS infrastructure design, and user support. He is also the president of Borealis Computing of Maine, Inc., which offers systems design and administration services to GIS shops, and a partner in Enterprise GIS Associates, providing a full range of services for designing and implementing enterprise GIS solutions. He has a B.S. and M.S. in Wildlife Biology and has been using GIS to support environmental decisions for 10 years. When not at the office he is usually chasing birds.
Stuart has an undergraduate degree in Forest Management from the University of Maine at Orono. He has been developing database applications for over ten years on platforms ranging from Windows desktop machines to IBM RISC UNIX environments. He has developed a water quality monitoring application for the Georges River Tidewater Association, and an inventory control application for the CCMP at Bigelow Labs. He has developed several Oracle database applications for the Maine DEP.
Jason has an undergraduate degree in Marine Biology from the University of New England. He will have a MS in Spatial Engineering from the University of Maine at Orono in December. His experience includes various programming assignments and work for Bigelow Labs and UNE in the area of remote sensing.