Geospatial Data Dissemination: Web Format

Environmental Data Management Best Practices

Overview

In this day and age with budget constraints and other organizations competing for limited funds, the need for digital solutions for disseminating information to the public is becoming imperative.  

Moving an organization from strictly paper products to digital or a hybrid digital and paper environment can save the organization in approval and review times as well as permit costs. The transition from paper to digital can result in big savings to the organization and permittee that has statutory-specific permit times. A component of an organization’s electronic permitting system can be an enterprise geographic data system. A geographic data system can provide a quick way to access an organization’s electronic permit data both internally and externally. The primary difference between sharing your geospatial data internally and externally is in security requirements.  

There are many internet providers; how does an organization select the best provider that meets their organization’s needs? When an organization is looking to serve their geographic data internally and externally, there are some key aspects that need to be considered. This document touches on some of these broad-reaching areas to start the process of asking questions to implement a geographic data component to their environmental data management system (see Environmental Data Management System White Paper). 

Geospatial Web System Planning 

One of the most important steps in implementing a geospatial solution is to plan the system. As an example, Tomlinson (2003) identified the following ten steps in planning a geographic information system (GIS): 

• Consider the strategic purpose. This step helps to ensure that the GIS solution will fit the organization’s strategic plan. 
• Plan for the planning. The purpose of this stage is to plan the project and end with a project proposal. 
• Conduct a technology seminar. During this stage the organization will meet with their end users to gain valuable input as to what the GIS solution will accomplish (what are the functions that the project needs to perform). 
• Describe the information products. Through discussions with the users, you should have a clear understanding of the data products needed or produced by the project. 
• Define the system scope. Based on the outcomes of the previous steps, an organization can develop the scope of the project . 
• Create a data design. During this stage the organization will plan and design the geodatabase created to hold the GIS data created during the project. 
• Choose a logical data model. This step looks at including those parts of the real world that pertain to your organization to carry out modeling and analysis that the end product will be performing. 
• Determine system requirements. During this stage the organization will discuss the hardware and software needed to house and run the other identified organizational needs. 
• Benefit-cost, migration, and risk analysis. During this stage the organization is focusing on how best to implement the GIS solution. 
• Make an implementation plan (Tomlinson 2003). This stage should result in a GIS planning book with a final report about how to implement the GIS solution once the development is completed. 

This is just one way to plan for your geospatial system. We have provided links to other geospatial planning documents to assist you with your geospatial system development. The important thing is to plan and diagram everything. 

Geospatial Web Format Choice 

The organization will need to determine the best way to present their geographic data internally as well as to the public. There are many off-the-shelf and open-source solutions to choose from. How does the organization determine the best choice to meet their needs?  

• The organization must find out if there is a standard for web development in their state. 
• The organization must determine the scope of the web-facing application. 

Knowing the scope will help keep the development focused on the needs of the project. Without a scope the project can blow the budget quickly, to the point of having a nonworking product when the money runs out. In a time with tight to diminished funds, having a well-focused project with a well-defined product may increase the organization’s chances of receiving the funds they need to develop their geospatial product. 

• Ensure that no sensitive data will be shared on the public application. 
• Determine if the application can be built with your off-the-shelf products or if you need to go through the request for proposals process to have a contractor develop the application. 

Your organization’s response to this point will determine overall cost for developing your geospatial solution. The cost could be anywhere from internal staff time to hundreds of thousands of dollars to develop the solution.  

• Know the current standard for the web software (for example, JavaScript, HTML5, cascading style sheets [CSS]). 
• Is open-source or off-the-shelf software right for your organization? 
• There are pluses and minuses to using either open-source or commercial-off-the-shelf (COTS) software, with good products available in either category. 

Geospatial Web Application Storage 

There is a global move to store data online in the cloud or in robust central data centers. There are many different data storage options available; it is important for the organization to know what their information technology (IT) infrastructure uses. This list gives the organization information to keep in mind as they plan their geospatial storage needs: 

• Ensure that data that will be available both internally and publicly are placed in an accessible data storage location for your geospatial websites. 
• Work with your state or organization IT group to have the application created in your storage environment. 
• What is the cost for your storage options? This can drive the option that you ultimately choose.  

Cloud storage and applications are very popular for serving out organizational data. The cost for serving in the cloud differs by provider. A clear understanding of those costs will save the organization overhead, development costs, and maintenance for use of this storage.  

Geospatial Web System Development and Evaluation 

This section goes through the process of making your organization’s geographic data available for internal or public consumption by way of the internet. The following questions are helpful in determining infrastructure needs when processing and evaluating geospatial strategy of the organization: 

• What are the firewall ports that need to be opened for your GIS software to work properly? 
• What is the network and subnetwork that your organization uses for accessing the web? 
• What are the firewall ports that are needed for your database software to serve the data? 
• Is your organization using Internet Information Services (IIS) to serve the maps to the web? 
• Are you using CSS to display the data in a web map? 
• What is the current protocol that you are using to create the web page (for example, HTML5)? 
• Does your geographic data solution incorporate SQL Server Integration Services (SSIS)? 
• Do you have a Secure Sockets Layer (SSL) certificate for your maps being opened on the web? 
• What is the projection of your largest data set? 

Regarding that final question, the largest data set projection is usually imagery data. When this is the case, it is best practice to project your smaller data sets to that same projection before publishing your services. Using the same projection for all data sets in the application stops the data from being reprojected on the fly by the geographic software, thereby reducing the use of the system resources for this common task. It takes time to reproject all layers into the same projection. However, the data render more quickly when they do not have to reproject the features. When it comes to projecting data, an organization is typically unable to meet all the service and application speed needs for everyone; however, if they strive to meet the needs of their main constituents, other users will have their needs met as well.  

Sharing Geospatial Web Systems 

Making organization geographic data available on the web allows the organization to share their data as web services (for example, Representational State Transfer [REST], Simple Object Access Protocol [SOAP], Web Feature Service [WFS], and Web Mapping Service [WMS]). These services can save the organization time and cost by not sending out the individual data sets on a regular basis to their constituents. They also have the potential be used in a one-service-for-many-uses scenario. One web service can be used for concurrent mapping, analysis, and modeling for all constituents connected to the service, thereby making the service one of the most efficient ways to share geographic data. However, there are some concerns when sharing your data on the web that need to be addressed; here are items to consider when looking to share your organizational geographic data on the web: 

Does or would your state Office of Homeland Security consider the data set to be a sensitive data set? 

• Determine if the distribution of the data set could be a liability to the organization. The release of certain geospatial data sets could cause personal injury both physical and monetary, causing loss of money for court costs and penalties adversely affecting the organization’s financial standing.
• Consider placing data that will be publicly accessible in a location outside of your organizational firewall. This offers a level of protection, making it harder for hackers to access the main production servers. 
• Ensure sensitive data is not in any map service that your organization will be serving to the public. This is a security and liability concern.  
• Enable WFS and WMS to use the map service in the Open Geospatial Consortium (OGC). OGC is the organization that houses and promotes open-source standards. This is important if your organization chooses an open-source GIS solution instead of a commercial off-the-shelf (COTS) GIS solution. These standards are the industry standard for sharing GIS data via the web. Most commercial GIS suppliers adhere to the OGC standard for their products and promote open-source products. 
• Ensure that all data sets, especially the organization’s authoritative data sets, have complete metadata. Metadata are data about data, as discussed in more detail in the Geospatial Metadata subtopic sheet. The metadata should include coordinate system information, fields and attribute information, and data access and distribution information. The metadata will also include extent information and scale of the data. 
• Consider optimization options for the data and services that the organization is serving. Fu and Sun (2011) listed some of the many ways to optimize your services, as follows:
  • cache the services  
  • tune the services and data 
  • failover and load balancing 
  • reduce the pressure on internet bandwidth 
  • secure web services 
• Determine who will need to have read versus write access to the data. 
• For data sourced from external parties, fill out memoranda of understanding and make them available for each participating organization so that the expectations for using their data in your overall data management system are clear. 

Geospatial Web System Quality 

The quality of this product is really tied to the speed of the services being served. The faster the rendering speed the better the viewing experience for all users, and the finer the scale of data that an organization is able to serve. This is good for the internal part of your solution but may have an adverse effect on the public-facing part of the solution. Keep in mind the end users of the solution. Refer to the Scalability and Deployment Consideration section below for more in-depth discussion about overcoming rendering issues. If constituents are not able to render the data in a reasonable time, this can make or break the constituents accepting or rejecting their use of the online geospatial solution.  

Scalability and Deployment of Geospatial Web Systems 

Scalability, configuration, and tuning of the geographic data will be determined by many factors. In this section we will step through many of the questions to ask to adequately scale and deploy your connections to your spatial data. 

• What is the speed of the organization’s internet connectivity and bandwidth?  
  This is the network speed coming into the building. This connection is split by the number of entities and individuals within each organization that occupies the building. As an example, your building may have a 1 Gb network connection coming into the building; however, you may have 10 entities with 20 people per entity in the building. Your bandwidth will be affected by up to 200 people trying to access the internet at the same time, as well as the type of networking hardware used.  

• What is the size of the web services or map services that we are serving? 
  Many data sets are well over 1 Gb in size to cover a whole state. This data set size is even larger the larger your state is. The organization needs to know the scalability, configuration, and tuning settings for their GIS and database software to adequately set up the services to render at a speed that will meet the demand of the public using the services. It may be feasible to divide one large map service of base data into multiple map services to split the load. 

• Are the data in the map service static data or dynamic data? 
  The organization can create map services that are static or dynamic. By doing so, they will be able to create and define zoom layers or pyramid layers for data that are static. Static layers do not change on a regular basis (i.e., digital elevation models, streams, topographic maps). Creating zoom layers will allow the map service to render more quickly with issues of inadequate internet connectivity. It will also assist the public client with their connection speed to the services. 

• Does the state or organization require a disclaimer about the proper and improper uses of the data? 
  This information should be on a splash screen that opens right away when the web map is opened. This splash screen should include any liability language, so that the user knows they are taking complete responsibility for their use of the data and services. If there are no splash screen disclaimers, or data are available for download, metadata can include proper uses or limitations of the data set. 

• Are there any state statutes that would affect the use or misuse of the data? 
  These laws should be listed, if possible, to protect the organization from lawsuits. 

Geospatial Web System Resources 

Links to sites about planning and implementing your GIS: 

• GIS Project Planning and Implementation – eolss.net 
• Kerski, Joseph J., and Jill Clark. 2012. “Putting Public Domain Spatial Data to Work.” In The GIS Guide to Public Domain Data, 235-262. Redlands: ESRI Press. 
• Open Geospatial Consortium (OGC) web page. The OGC website provides links to open-source GIS and server software and tools and tutorials to get started with an open-source GIS solution. 
• Open Geospatial Consortium Inc. (OGC)—OSGeo. 
• Peters, Dave. 2012. Building a GIS—System Architecture Design Strategies for Managers. Redlands: ESRI Press. 

Print this page/section