(Geospatial) Data by Mihal Miu
ATHABASCA UNIVERSITY AGGREGATION OF MAP (GEOSPATIAL) DATA BY MIHAL MIU
An integration project submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in INFORMATION SYSTEMS Athabasca, Alberta April 2015 © Mihal Miu, 2015, 2016
Abstract:
Aggregation and fusion of geospatial data using a virtual globe implemented as a GIS application named PlaniSphere developed by the author. Geospatial data can be obtained from public suppliers as well as from commercial vendors. Commercial vendors and open-source suppliers focus on different details of information and use a variety of file formats that can be restrictive in their usage. To widen usage aggregation and fusion of geospatial data obtained from different sources can be used to generate a new 3D/2D map or an enhanced 3D/2D map using geospatial data from existing sources. The new or enhanced 3D/2D map has the potential to be used in land analysis, land resource management, city planning, agriculture, forestry, and orbital analysis of objects.
Table of Contents Background ...... 4 Problem/Opportunity ...... 4 Literature Review ...... 5 Goals ...... 9 Design and Implementation Challenges ...... 9 Problem ...... 13 Methodology ...... 14 Potential Solution(s) /Opportunity ...... 18 Milestones ...... 20 Compatibility of Map Data and Supporting Infrastructure ...... 20 Project Resource ...... 21 Participants ...... 21 Hardware / Software / Budget ...... 21 Deliverables...... 24 Implementation ...... 24 Functionality of PlaniSphere ...... 25 GUI Design ...... 25 Layers and Aggregation of Layers ...... 29 Layer Format ...... 35 Export Capability ...... 37 Pros with regards to the Export Capabilities ...... 39 Cons with regards to the Export Capabilities ...... 40 System Architecture ...... 41 PlanOSM a Precursor to PlaniSphere ...... 43 Expandability ...... 43 Implementing the Plug-in Infrastructure ...... 45 Creating a plug-in using the Plug-in Infrastructure ...... 51 Pros of the Plug-in Infrastructure ...... 52 Cons of the Plug-in Infrastructure ...... 52 Demo Plug-ins ...... 52
Coding a New Plug-in ...... 53 Distribution ...... 58 Potential Usage and Domain Specific Application Examples ...... 59 Education ...... 59 Exploration ...... 60 Space and Planetary Exploration ...... 60 Logistics ...... 66 Land Analysis ...... 69 Land Analysis Plug-in ...... 71 Remote Land Analysis of two Parishes/Townships in Rural Alberta ...... 80 Discussion with Regards to Using the Land Analysis Plug-In and its Methodology of Analysis ...... 93 Oceanography ...... 105 Map Data Sources ...... 109 Results ...... 111 Future Work and Improvements with regards to PlaniSphere ...... 113 Conclusions ...... 115 Acknowledgements ...... 116 Terminology ...... 117 References ...... 119
Background
Problem/Opportunity Currently there is no geographic information system (GIS) service that allows aggregating and fusion of geospatial data from different data sources. Investigation showed that existing GISs are limited in scope. If multiple map services for geographically distinct regions could be aggregated then the end result would be a map with greater coverage or a new map. If multiple map services for the same geographical region could be aggregated than the resulting map produced would be an enhanced map.
Investigation showed that current GIS commercial vendors are closed-source and will direct or encourage users to use geospatial data from their own sources or their preferred vendors. ESRI through its ArcGIS platform creates a GIS infrastructure and provides users with servers, clients, and geospatial data. ArcGIS has a plug-in infrastructure that allows users to perform their own customization, however restrictive. Another example is Google Earth. Google provides users with a desktop client that uses geospatial data hosted on Google’s servers/server farms. Google Earth does not allow for user customization and it has no plug-in infrastructure. Existing GIS vendors provide users with an integrated solution and they have little or no interest in aggregating and fusing geospatial data. Existing GIS vendors would face a loss of revenue if any of their users will use aggregation and fusion of geospatial data modules from a potential competitor.
Alternatives to commercial vendors are open-source suppliers. However existing open-source suppliers like GeoServer and MapServer provide fragmented solutions for geospatial data, services, and infrastructure. Usually these open-source projects are independent of each other. Often it is desired that these independent projects should allow for integration. The level of integration required may be high and not within the capabilities of the open-source suppliers. Both GeoServer and MapServer will allow clients to connect using the Web Map Service (WMS) protocol from Open Geospatial Consortium. These servers will generate 2D maps but not 3D.
To use strengths and alleviate weaknesses from both closed-source and open-source solutions it is desired to create software tools that will allow aggregation and fusion of geospatial data that is platform independent (any server, any operating system, any existing solution) and source independent (geospatial data, either from a remote server or a local file). The desired software tools will allow users to create 3D maps as well as 2D maps depending upon the user’s needs and resources.
2D maps are static, constructed on latitude and longitude. They do not reflect changing geospatial data but they can be shifted and have their resolution changed, however they are referred to as being static. 2D maps are instrumental in road navigation, city planning, and urban planning. 3D maps are constructed on latitude, longitude, and altitude. 3D maps are also static but they can be viewed from different viewpoints, can be rotated, shifted, and transformed hence they (3D maps) are referred to as being dynamic. 3D maps require more hardware resources (processing power, memory, storage, and high speed-high bandwidth internet connection) to render than 2D maps. On clients 3D maps also require more hardware resources (processing power, video rendering capabilities, memory and high speed-high bandwidth internet connection) to render than 2D maps.
Literature Review Topography can be conveyed to the general public using three dimensional representations. This aids individuals in the understanding of topography since they are able to visualize an area or environment in three dimensions. NASA World Wind uses LandSat 7 satellite images and combines them with Shuttle Radar Topography Mission (SRTM) elevation model to produce a three dimensional topographic image (see Figure 1). NASA World Wind is a good starting point for any three dimensional GIS application. In order to achieve wide usage the application must be easy to use and offer an intuitive graphical user interface. [1]
Figure 1: Image of Canmore, Alberta and surrounding areas rendered using NASA World Wind.
A 3D GIS platform lowers the barrier to entry for its user base since it takes advantage of recognition and visual skills such as depth of perception and three dimensional modeling. There are two 3D GIS platforms that are available on the Internet: Google Earth and NASA World Wind. A common focus of Google Earth and NASA World Wind is used to create a highly optimized tessellation environment [2]. Both Google Earth and NASA World Wind displays geospatial data in a three dimensional format. On the surface Google Earth and NASA World Wind are similar tessellation environment, they cater to different audiences. NASA World Wind delivers an SDK that allows developers to embed it into their own application. Google Earth’s is an application that is used to deliver Google’s content, whether it is GIS based, and/or advertisement accompanying the GIS content distributed.
Data services are a common mechanism for accessing information over the internet. The Open Geospatial Consortium (OGC) provides specifications of interoperability among vendors. OGC provides a standard named Web Map Service (WMS) [3]. WMS has been created to aid in transferring geospatial data over the internet. Modern map servers such as GeoServer and MapServer are designed based on SOA. WMS is used as the underlying protocol that supports SOA. Also WMS supports interoperability
between map servers and clients. The end result of WMS is to produce a map represented by an image stored in a Portable Network Graphics (PNG), Graphics Interchange Format (GIF) or Joint Photographic Experts Group (JPEG) format. [4]
WMS is an open-standard that excels at producing maps. Usage of WMS in GeoServer and MapServe produces two dimensional maps. It should be noted that there is no restriction in WMS to produce only two dimensional maps. This restriction is in the map server itself. Hu et al presents a layered architecture for integrating geospatial processing services into a 3D GIS. Four layers are used: presentation, application, service and data (see Figure 2). Unfortunately for our purposes this architecture is well defined and requires dedicated resources. It should be noted that data flows to the client via the service layer followed by the application layer. Another disadvantage is that this architecture requires sophisticated skills to use and maintain. If new data is added one needs to reconfigure the service layers. An alternative to this layered architecture is to implement all of these layers into an application that is graphical in nature. Pan et al has achieved coverage of the earth’s surface by implementing a custom GeoTIFF layer in NASA World Wind. What has been achieved in this case is ease of use, ease of administration. However there is an upfront cost when it comes to creating the custom layer. [5]
Figure 2: An Approach for Integrating Geospatial Processing Services into 3D GIS [6]
In 2007 Wulder has demonstrated the integration of LiDAR sampling data with satellite imagery used to investigate temporal canopy changes over a study area within Canada’s boreal forests. Satellite maps provide excellent coverage and level of detail for low to medium scales. However LiDAR provides excellent coverage and level of detail for high scales. The fusion of these two types of maps allowed for a remote investigation without the need to physically visit remote areas or any areas of interest. [7]
In Ontario the Ganaraska Region Conservation Authority is aggregating and fusing geospatial data in order to support sustainable water management. Different types of geospatial data is fused into a single 3D map. The newly generated 3D map contains the elevation model of the region. A consequence of the map fusion is that input data for hydrologic and hydraulic models has become a single model. A single map can be used to analyze both hydrologic and hydraulic models. Before the map fusion each model had its own map. Also overland topography can now be captured and fused with in-channel hydraulic data. This will enable for technical continuity between GIS, remote sensing surveying and engineering. [8]
Point clouds obtained from LiDAR can range from a few hundred thousand to several hundred million points. When visualizing point cloud data with OpenGL the limit of concurrently displayable points may be a maximum in the tens of millions. One of the challenges is to determine a strategy/mechanism for efficiently and effectively visualize large amounts of data. One possible solution to this challenge is to employ a level of detail (LOD). At lower scales a greater level of detail can be displayed since a smaller area is covered. Conversely at higher scales a lower level of detail can be displayed since a larger area is covered. Also for higher scales LiDAR point cloud data may be inappropriate due to the very large amount of geospatial data. [9]
LiDAR point clouds may easily represent the terrain surface. Since LiDAR data is three dimensional a terrain canopy may be generated. The level of detail for this terrain canopy can be used to predict various facts about land coverage [10]. For example analysis of LiDAR point clouds can be used to determine areas where the land is barren, covered by forests or covered by water. Such knowledge can be used in for land management and/or resource management. Another aspect is that once LiDAR point clouds are geo-tagged then they can be used to support calibration of wide area satellite based mapping. [11]
Boschetti et al used NASA World Wind .NET for visualizing the Moderate Resolution Imaging Spectroradiometer (MODIS) burned area product. Boschetti’s implementation of a virtual globe was
very specific and limited in scope. The virtual globe was used for visualization purposes rather than data distribution purposes. The conclusion of the project was that any new research would need to address the ability to consume geospatial data. [12]
A common operational picture (COP) is a single identical display of relevant operational information shared by many users. A COP requires having a shared and updated view of the operational landscape. It also assists in collaborative planning and aids decision makers. The benefits of aggregating map data is that it establishes a common map appearance, it facilitates validation and authorization of map data, simplifies the addition of new systems and it provides a cost effective mechanism for achieving map coverage. [13]
3D GIS’ may be used to support public participation in decision making with regards to land analysis, land resource management, city planning, agriculture, and forestry. A desired goal of public participation is to combine local knowledge with professional expertise in order to generate ideal decisions. The public needs to use a 3D GIS in order to understand the geographic constraints they will be faced in their decision making process. Ideally an interactive virtual globe is best suited for this situation since it make content available on demand over the Internet. [14]
Goals This project has three simple goals.
1. To create software tools that aggregate and fuse various geospatial data sources. 2. To synthesize raw geospatial data and generate new or enhanced maps users. 3. To allow customization for users and possibly unforeseen uses of the software tools.
Design and Implementation Challenges Creating software tools that aggregate and fuse various geospatial data sources need to reconcile difference in multiple data formats and service providers. The Google Earth infrastructure depicted in Figure 3 outlines a closed-source system. The software tools that this project creates will allow the usage of various geospatial data regardless of the format and location. Figure 4 provides a high level overview of the proposed solution that will be implemented in this project. Geospatial data can be provided from local storage or from remote servers through the internet using WMS.
Figure 3: Google Earth Infrastructure
Figure 4:Various file formats and protocols used by geospatial data vendors/suppliers.
If you start with a map an area represented by a LandSat photograph with buildings and landscape details as shown in Figure 5 and superimpose an OpenStreetMap road map of the same area with roads and names as shown in Figure 6, the user can generate an enhanced map of the same area containing all details from figures 5 and 6 (buildings, landscape, roads, and names) as depicted in Figure 7. The geospatial data used in figures 5 and 6 are provided by two independent and distinct sources: LandSat photographs are provided by NASA and OpenStreetMap maps are provided by a community of mappers. Figures 5 and 6 represent different geospatial data types: a LandSat satellite photograph and an OpenStreetMap 2D road map. The aggregation and fusion of a photograph and a road map is the rendered result depicted in Figure 7.
Figure 5: A LandSat photograph of Toronto with buildings and landscape captured by a LandSat 7 satellite, courtesy of NASA.
Figure 6: An OpenStreetMap roadmap of Torontowith roads and names, courtesy of OpenStreetMap.org
Figure 7: An OpenStreetMap map superimposed over a LandSat photograph of Toronto showing all details from Figure 5 and Figure 6.
Note: The rendering of an OpenStreetMap road map superimposed over a LandSat photograph was created using a sample of the software tools developed in this project.
Problem If we continue on the current path of commercial vendor dependence and lack of open-source integration there will be a constant duplication of geospatial data and resources among commercial vendors and open-source suppliers. This will result in an increase of cost to users and inability to aggregate various geospatial data sources. Figure 8 presents a generalization of Google and MapQuest’s mapping services. Google provides world coverage for the areas that have been mapped and it uses map data from TerraMetrics, DigitalGlobe and First Base Solutions. On the other hand MapQuest provides world coverage for the areas that have been mapped and it uses map data from TomTom and i-cubed. The mechanisms for managing geospatial data are not made publicly available by Google or MapQuest. The issue is that both organizations are duplicating efforts when it comes to providing
mapping coverage of the world, they uses proprietary software, and it ties endusers to a one-vendor solution.
Figure 8: Proprietary Infrastructures of Mapping Services
Methodology This project creates software tools to aggregate and fuse various file formats and existing geospatial data sources from commercial vendors and from open-source suppliers without duplication of geospatial data. WMS is a standard widely used for accessing and retrieving maps from remote servers made available over the internet. WMS can be used to retrieve maps from public and private servers via the internet. WMS versions 1.1 and 1.3 are widely supported by commercial vendors and open-source suppliers. Please note that WMS version 1.3 is not backwards compatible with WMS version 1.1 [15]. WMS can retrieve geospatial data from a remote server without knowing the originating file(s) and their type(s)/format(s) but it needs a server-side implementation. When you retrieve geospatial data from local storage you may not have a server-side implementation of WMS and therefore WMS cannot be used. Software tools that this project creates can aggregate files from local storage that conform to widely used file formats such as: GeoTIFF files, ESRI shape files and KML files.
There is a need to be able to parse different file formats, create in-memory data structures to represent geospatial data from different file formats and generate a map. This project fulfilled this need by using World Wind from NASA as a basis for the software tools that it (project) creates. NASA World Wind accesses remote map servers using WMS version 1.3 and it also parses files that reside on local storage and conform to the following formats: GeoTIFF, ESRI shape files, and KML. This was depicted in Figure 4.
Within World Wind each map is composed by one or more atomic objects that contain one or more separate items. Each atomic object represents a layer. New or enhanced maps can be generated by combining multiple layers into a single layer using geospatial data from existing sources disregard whether the sources are commercial vendors or open-source suppliers. In Figure 7 we already have seen geospatial data from OpenStreetMap superimposed onto geospatial data from LandSat. Since this process is graphical and geospatial data can have many sources its usage can be expanded to other domains.
Figure 9 shows geospatial data sources that can be aggregated and fused into a 3D/2D map with the software tools that this project creates. Access for proprietary file formats will be indirectly supported. For instance GeoServer and MapServer already support proprietary file types such as ArcGrid that can be accessed using WMS. Another proprietary file type is geospatial table data. This is considered a non- formatted file. The software tools this project creates can also indirectly aggregate non-formatted files using WMS.
Figure 9: Overview of aggregating geospatial data using various sources and services
In Figure 7 we depicted aggregated geospatial data and it was stated that a layer of OpenStreetMap was superimposed over a layer of LandSat. What happens if the superimposition order is reversed: a layer of LandSat is superimposed over a layer of OpenStreetMap? The new/enhanced map from Figure 10 looks similar to the LandSat satellite photograph from Figure 5. Conclusion: the order in which layers are superimposed is crucial. Layers are classified into two categories: base layers and overlay layers. Base layers have a solid background, they are not transparent. An example of a base layer is LandSat. Overlay layers have a transparent background. OpenStreetMap road map is an example of an overlay layer. This is why when we superimposed OpenStreetMap (overlay layer – transparent background) over LandSat (base layer – solid background) the result was an aggregated map containing details from both geospatial data sources as in Figure 7. When LandSat was superimposed over OpenStreetMap the solid background of LandSat covered the details from OpenStreetMap and the result was a map in which we lost the details from the OpenStreetMap. To review: an overlay layer is superimposed over a base layer (a base layer is always under an overlay layer).
What happens if a user would like to superimpose multiple overlay layers over a base layer? A layer manager needs to be created to allow the user flexibility in choosing the order of overlay layers superimposed on the base layer.
Figure 10: A LandSat photograph superimposed over an OpenStreetMap road map of Toronto.
How will the aggregation and fusion of geospatial data be achieved using the software tools this project creates? The strategy is not to convert from one file format (among the file formats supported: GeoTIFF, ESRI shapefiles, KML and WMS protocol) to another, but to create a layer for each file.
The software tools this project creates allows third-party and independent developers to add new capabilities and to expand user customization through plug-ins. NASA World Wind does not provide a plug-in infrastructure. This project also creates a plug-in infrastructure that manages available plug-ins. This project provides sample plug-ins to demonstrate the capabilities of the plug-in infrastructure like adding new layers, adding new attributes and associating them with a new or existing layer.
There are three methods for aggregating geospatial data: dissolve, merge and spatial joins. Dissolve, groups objects that have similar values for geospatial attributes. Dissolve can be automated based on shared predefined values for geospatial attributes. Merge allows the grouping of objects during an editing session. This is an interactive technique that is appropriate for the creation and editing of maps. Both dissolve and merge will group objects if they exist in the same layer. Unfortunately in this project there are multiple layers. Hence dissolve and merge are inappropriate for our requirements.
Spatial joins operate on related objects based on location. Spatial joins are not limited to a single layer. They may occur between multiple layers. Spatial joins resolve the problem of single layer operations created by dissolve and merge. However, spatial joins introduce an issue where the geospatial data is requireed to be granular and individual points of interest are well described. An individual point of interest may be a road, building, house, bridge, park, field and so on. This presents a problem since the geospatial data available may not conform to this requirement.
Potential Solution(s) /Opportunity Several GIS desktop applications and Application Programming Interfaces (APIs) were evaluated as a potential base for the software tools that this project creates. Table 1 shows a comparison of existing GIS desktop applications and APIs that have some of the features required for this project.
The software tools that this project creates are based on NASA’s World Wind SDK for Java. It is publicly available and downloadable from http://worldwind.arc.nasa.gov/java/ . It may be used by anyone and it may serve as a base infrastructure for any development. Using NASA World Wind has several advantages:
It is implemented in Java. It can be used on any operating system that has Java support. This includes most commonly desktop operating systems: Linux, MS Windows, and OS/X. It provides support for accessing map services on remote servers through the internet using WMS version 1.3. It provides support for accessing files (formats supported: GeoTIFF, ESRI shape files, and KML) on local storage. It implements a tessellator that is used to manage and render datasets of polygons (vertex sets) that represent a map or map layers. The tessellator is implemented in OpenGL allowing 3D/2D accelerated rendering to occur. It is optimized to perform on common desktop operating systems.
Table 1: Comparison of existing GIS Desktop applications or infrastructures
Product License Source OS Support 3D Map Services Plug-in Code Support Support Support Availability NASA World Public, Open- Yes Java Yes, WMS, GeoTIFF, No Wind for Java Source using ESRI shape [16] OpenGL files, KML Google Earth [17] Commercial No Java Yes, Google Map No using Servers OpenGL ESRI ArcGIS Commercial No MS Limited WMS, ESRI No Explorer Desktop Windows support shape files, [18] KML GeoTools [19] Public, Open- Yes Java No WMS, GeoTIFF, No source ESRI shape files QGIS [20] Public, Open- Yes Python No WMS, GeoTIFF, Yes source ESRI shape files
This project will create software tools that are platform independent. Such tools will be supplied in the form of a desktop application. Platform independence is achieved by having an application execute on multiple operating systems such as Linux and Microsoft Windows. When trying to achieve platform independence it would be ideal to have an application that is compiled once and can be executed on any operating system platform. Java can meet such a requirement. Java also has OpenGL and OpenCL binding. Another advantage of Java is that is supports just in time compilation. Python is a scripting language. It does not have OpenCL nor OpenGL bindings and it does not support just in time compilation.
A strong argument has been provided for using NASA World Wind as a base for this project. Hence the development and testing platforms will have to be a desktop/notebook and operating systems that supports Java. Linux and MS Windows are popular operating systems that are easily accessible and operate on a wide range of desktops and/or notebooks.
NASA World Wind uses OpenGL to perform graphical rendering. The desktop and/or notebook computers will require video cards that support OpenGL. Possible options are AMD Radeon HD or NVidia video cards. Both AMD Radeon HD and NVidia video cards provide drivers for accelerated 3D OpenGL drivers for Linux and MS Windows. The computers used in this project are required to support OpenGL and OpenCL using hardware acceleration. An operating system that supports hardware acceleration with respect to graphics rendering using OpenGL will provide an environment that has efficient execution of an application that requires graphic capabilities.
Milestones 1. Create a requirements document. Expected time for completion is six weeks. 2. Design architecture for the software tools. Expected time for completion is four weeks. 3. Obtain access to map data. Expected time for completion is two weeks. 4. Set up development and testing environment. Expected time for completion is one week. 5. Implement rendering of individual base layers. Expected time for completion is two weeks. 6. Implement rendering of individual overlay layers. Expected time for completion is two weeks 7. Implement rendering with regards to superimposition of an overlay layer on top of a base layer. Expected time for completion is two weeks. 8. Implement rendering with regards to superimposition of an overlay layer on top of another overlay layer. Expected time for completion is two weeks. 9. Implement a layer manager to control order of superimposition when multiple overlay layers are used. Expected time for completion is two weeks. 10. Implement a plug-in infrastructure. Expected time for completion is four weeks 11. Create sample plug-ins to demonstrate the plug-in infrastructure. Expected time for completion is four weeks. 12. Create a land analysis plug-in. Expected time for completion is four weeks.
Compatibility of Map Data and Supporting Infrastructure The software tools that this project creates will not convert from one file format supported to another file format. Instead the files will be parsed and rendered on a 3D coordinate system therefore there is no need for compatibility among different types of geospatial data and sources. The level of detail and the quality of the rendered layers depend on the level of details and quality of the individual files. [21]
Verifying if aggregation and fusion of geospatial data is performed correctly will require geospatial data of several format types. Verification will be demonstrated by software tools with a graphical user
interface that requires input from the user. This is a visual process. It would be ideal if the user is familiar with the area that is aggregated and fused. Geospatial data can be supplied from local files and/or resources that reside on the cloud or internet. Geospatial data supplied from local files will be ESRI shape files, GeoTIFF files, and metadata files such as KML. Geospatial data that resides on the cloud or internet can be accessed through the WMS protocol.
Project Resource
Participants This project represents the work of Mihal Miu. He is responsible for devising strategies and algorithms for geospatial aggregation. Such strategies and algorithms will be implemented (coded) as software tools based on NASA World Wind for Java version 2.0.
James R. Miller (http://people.eecs.ku.edu/~miller/) from the University of Kansas, Department of Electrical Engineering and Computer Science provided source code for a LiDAR viewer (named LiDAR Data Visual Analysis and Editing or LASVisEdit) based on NASA World Wind for Java version 2.0.
Hardware / Software / Budget There are three components to this project: the development environment, the hardware to host the tools and the map data. This project will use PC based systems. In this project there is a need for a desktop, a notebook computer, and a tablet. Table 2 outlines the hardware and operating system costs. The development environment is composed of Java, NetBeans, Git and GeoServer (with PostGIS). These tools are either open source and/or freely downloadable. Table 3 outlines the development tools. This project will use publicly available geospatial data outlined in Table 4. A detailed examination of Tables 2, 3 and 4 reveals that the only monetary requirement will be for the purchase of a desktop, a notebook computer, and a tablet for a total of $3100.
Table 2: Costs of Hardware and Operating Systems used in this project
Hardware and Processor Video Card Memory Storage Cost Operating System Desktop running AMD FX-8320 Radeon HD 7950 16 GB 512 GB SSD $1500 Linux Notebook running AMD A8 Radeon HD 8 GB 240 GB SSD $800 Linux Tablet running MS Intel I3 Intel Integrated 4 GB 64 GB SSD $800 Windows 8.1 Total Cost $3100
Table 3: Development tools used in this project
Development Web Site License Cost Tool Java 7/8 SE SDK http://www.oracle.com/technetwork/java/javase/d Commercial Free ownloads/index-jsp-138363.html download NetBeans 8 (IDE) https://netbeans.org/ Open- Free source download GeoServer (WMS http://geoserver.org/ Open- Free server) source download Git (revision https://git-scm.com/ Open- Free control system) source download
Table 4:Geospatial Data used in this project
Name Web Site License Cost OpenStreetMap Planet.osm, http://planet.osm.org Open- Free source download GEOFABRIK, http://download.geofabrik.de Open- Free source download World OSM WMS, http://www.osm-wms.de Open- Free source download Terrestris WMS url, Open- Free access http://ows.terrestris.de/osm/service,http://ows.terre source stris.de/osm-gray/service, http://ows.terrestris.de/osm-haltestellen Blue Marble: land http://visibleearth.nasa.gov/view.php?id=57752 Publicly Free surface, shallow available download, water and shaded Free access topography GeoGratis http://www.nrcan.gc.ca/earth- Publicly Free sciences/geography/topographic-information/free- available download, data-geogratis/11042 Free access The Atlas of Canada – Toporama general website, Publicly Free http://atlas.gc.ca/toporama/en/index.html. available download, WMS url: http://wms.ess- Free access ws.nrcan.gc.ca/wms/toporama_en?VERSION=1.3&re quest=GetCapabilities&service=wms U.S. Geological General website: http://www.usgs.gov, Publicly Free access Survey Earth Explorer website: http://earthexplorer.usgs.gov available GEBCO, General General website: http://www.gebco.net. Publicly Free Bathymetric Chart WMS url: available download, of the Oceans http://www.gebco.net/data_and_products/gebco_w Free access eb_services/web_map_service/mapserv?version=1.3 &service=wms&request=GetCapabilities
Deliverables This project demonstrates aggregation of multiple geospatial data types and sources into a single 3D/2D visual presentation. The software tools developed in this project will be in the form of a platform independent desktop application. That means that it will work on any computer that supports Java. The usage of the application is to empower any user with very limited knowledge of geography to enhance existing maps or create new maps, and infer new relation from the maps produced using aggregation, fusion and export functionality. The application created in this project is targeted to operate on mainstream desktop or notebook computers. As such there is no need for specialized hardware resources.
This application created in this project will provide the following functionality:
Ability to aggregate multiple mapping services and visualize them into a single visual presentation. The sources of geospatial data may be a combination of local files (on local storage), WMS (from servers on the internet) and/or cloud sources. A graphical representation of the geospatial data will be created in either a 3D presentation (map with topology) or a 2D presentation (map only). Ability to add new functionality through a flexible plug-in infrastructure. Plug-ins may be created by any third party. This will allow for the adoption and/or incorporation of the software tools by any organization. Ability to enhance existing maps and generate new maps from existing geospatial data.
Implementation The software tools created in this project will be represented by a single application named PlaniSphere. PlaniSphere will be built on top of NASA’s World Wind for Java version 2.0. NASA World Wind for Java provides a stable framework where existing functionality can be leveraged and new functionality can be built upon. NASA World Wind provides functionality to utilize existing map sources in the format of WMS, ESRI shape files, KML and GeoTIFF. See Table 1 for comparison of supported map formats of various GIS infrastructures.
PlaniSphere will be implemented using Java SE 1.7. Java is supported on the majority of mainstream operating systems such as Linux, MS Windows, OS/X. It should be noticed that World Wind is written in
Java. Hence to continue to use the same language for PlaniSphere will ensure a smooth transition. PlaniSphere will be a desktop application that will have a Java Swing GUI.
Functionality of PlaniSphere PlaniSphere is a 3D virtual globe desktop application that provides a rich set of features for displaying and interacting with geospatial data.
A Java SE 1.7 application that can run on any operating system that supports Java SE 1.7 or higher. PlaniSphere is an interactive application that has a low learning curve. Provides open-standard interfaces to GIS services and databases. Capable of rendering in 3D/2D local geospatial files: ESRI shapefiles, GeoTIFF, and KML. A plug-in framework that can be used to enhance PlaniSphere’s capabilities or add new capabilities. Capable of rendering in 3D/2D high-resolution imagery, terrain and geospatial information from any source using WMS 1.3. Each map source is represented by a single layer. Multiple layers can be fused into a 3D/2D presentation.
GUI Design PlaniSphere is a desktop application with graphical capabilities. PlaniSphere’s functionality will be made available to the user through a graphical user interface (GUI). In this section the major GUI features will be discussed in detail.
PlaniSphere will use similar GUI design guidelines to any MS Office 2007 or newer application. It will be an application that revolves around a main window with a ribbon toolbar. The ribbon toolbar will expose the core features to the user. Under the ribbon toolbar there will be a working area where a map or 3D virtual globe image will be displayed. Any optional capability to manipulate any layers within the map will be in a tabbed pane to the left of the working area. See Figure 11 for a general layout of the main window and Figure 16 for the actual GUI.
Figure 11: PlaniSphere GUI Layout
NASA World Wind for Java 2.0 is distributed as a system development kit (SDK). The goal of the SDK is to allow developers to embed World Wind in their own applications. A ribbon toolbar library named Flamingo has been implemented by Kirill Grouchnikov. Both Flamingo and NASA World Wind are implemented using the Java Swing toolkit. This fact demonstrates that Flamingo and World Wind can be compatible with each other when they are used within the same application. The latest version of the Flamingo is freely available from the https://github.com/kirillcool/flamingo Git repository website [22]. As of 2010 Flamingo is no longer maintained. A more up to date fork of Flamingo is Peacock and can be downloaded from https://github.com/Insubstantial/peacock Git repository website [23].
The ribbon toolbar of PlaniSphere will have the ability to show or hide layers natively supported by NASA World Wind such as NASA Blue Marble Image, i-cubed Landsat, Earth at Night, atmosphere and/or stars. These layers are loaded by default by NASA World Wind or any application that is built using NASA World Wind. In PlaniSphere the ribbon toolbar will have a NASA Map Server ribbon band that will enable the user to individual toggle the visibility of these layers. See Figure 12.
Figure 12: NASA Map Servers
NASA World Wind has built in support for Bing Imagery, MS Virtual Earth and OpenStreetMap WMS. In PlaniSphere the ribbon toolbar will have a “3rd Party Map Servers” ribbon band that will enable the user to individually toggle the visibility of these layers. See Figure 13.
Figure 13: 3rd Party Map Servers
The ribbon toolbar of PlaniSphere will have the ability to load any resources available from any map servers that support the WMS 1.3 protocol. PlaniSphere can connect to multiple servers if the server URL is known. PlaniSphere will be able to load any geospatial data resource represented by files such as ESRI shapefiles, GeoTIFF and KML. Each file will represent a single layer that will be rendered on the map. A ribbon band will be dedicated to “Custom Map Sources” support. It should be noted that each time a connection to a known map server is required there will be a need to click on the “Add WMS Server” button in the ribbon band. Each file type will be represented by a button. See Figure 14.
Figure 14: Custom Map Sources.
For resources that are loaded dynamically (such as WMS, ESRI shapefiles, KML and GeoTIFF files) there will be a mechanism to remove them or unload them from the map presentation. Such functionality will be available in the options tabs available to the left of the working area or map presentation area. See Figure 15 for the capability of removing /unloading local files. Note the red “x” button to the right of the layer name/description. The red “x” button is used to permanently unload the geospatial data file that it is associated to.
Figure 15: File Layers tabbed pane used to unload file map data.
Figure 16: The GUI of PlaniSphere
Layers and Aggregation of Layers PlaniSphere provides the users with a virtual globe or a map. Both the virtual globe or the map are made up of multiple layers. A layer represents an atomic geospatial data set. A layer cannot be further decomposed. An atomic geospatial data set may be a single file (ESRI shapefile, GeoTIFF or KML) or a data set (or WMS layer) available from a WMS server. There are two types of layer: base layers or overlay layers. The overall map is created by fusing a base layer with multiple overlay layers.
Base layer are mutually exclusive layers. This means that only one base layer can be displayed or is visible on a virtual globe or map. A base layer can be used to determine the available projection (coordinate system) and zoom levels available to the virtual globe or map. Overlay layers are an alternative to base layers. Overlay layers do not control the zoom level of the virtual globe or map. Overlay layers may be superimposed on other overlay layers and/or a base layer. Overlay layers may be superimposed only if it can be reprojected to the projection supported by the base layer.
Base layers and overlay layers are concepts that concern the end user when interacting with the virtual globe. Rendering layers using OpenGL is supported by a collection of classes and interfaces supported by NASA World Wind for Java [24]. The starting point to understanding this framework is with the basic layer capabilities defined by an interface named gov.nasa.worldwind.layers.Layer. This interface is implemented by an abstract class named gov.nasa.worldwind.layers.AbstractLayer. The class gov.nasa.worldwind.layers.RenderableLayer inherits from AbstractLayer. An alternative to a RenderableLayer is gov.nasa.worldwind.layers.TiledImageLayer. Layers that are used in PlaniSphere are either direct or indirect instances of RenderableLayer and direct and indirect instances of TiledImageLayer.
Each type of layer has its own implementation class(es) and are provided by NASA World Wind [25]. See Table 5 for a listing of layers supported by PlaniSphere. Different layer types displays different type of data. The data displayed in each layer type may or may not have commonality between with other layer types. For example a KML layer displays metadata extracted from an xml text file [26]. On the other hand a shapefile layer displays points, lines, and polygons extracted from a binary file. However an ESRI shapefile does not have any topographical information associated with any of the attributes that it represents (points, lines, and polygons) [27]. To make matters worse a WMS server may be able to support multiple geospatial data. The format of the geospatial data may be known or unknown (proprietary to the vendor itself). The fact that different formats are used to represent different types of geospatial information and that unknown geospatial formats may be exposed by WMS based servers makes any data relation model and/or software architecture model irrelevant [28]. Simply put there may or may not be any relation(s) with regard the data model. Also the software may be proprietary, distributed in a binary format or offered as a service. If this is the case any analysis with regards to data models used would be impossible.
Table 5: Layers supported by PlaniSphere
Layer Name Layer Type Provider Description Blue Marble Base Layer NASA Blue Marble is a data set that provides detailed true-color image of the Earth’s surface. Data set images were compiled over four months of observation using NASA’s Terra
satellite. [29] Blue Marble Next Generation supersedes the Blue Marble data set. It provides a whole years data collection (categorized by monthly periods). The resulting monthly composites may be used to reveal seasonal changes to land surfaces. [30] i-Cubed Landsat Base Layer NASA A publicly available archive of satellite photos, providing a maximum resolution of 15 meters per pixel and cloud free images. Images are provided from Landsat 7 satellite launched on April 15, 1999. Note that the Landsat 7 satellite is still operating. [31] Bing Imagery Base Layer 3rd party, provided A data set of aerial images provided by Microsoft by Microsoft Corporation. This data provides high resolution images of urban areas. Bing Imagery supersedes MS Virtual Earth data set. [32] MS Virtual Earth Base Layer 3rd party, provided A data set of aerial images provided by Microsoft by Microsoft Corporation. This was Microsoft’s first attempt to provide a high resolution images to be consumed by web applications/developers. As of 2013 MS Virtual Earth has been superseded by Bing Imagery. MS Virtual Earth is maintained for backwards
compatibility. [33] OpenStreetMap Overlay Layer 3rd party, provided An open source dataset of road maps by OpenStreetMap provided by a volunteer community. This data set is constantly being updated and new areas are added on a continuous basis. [34] ShapeFile Can be either 3rd party, can be Data set(s) are provided by files that base or overlay provided by anyone can be consumed by PlaniSphere. layer depending and/or any on the data organization. contained in the shapefile. KML [35] Overlay Layer 3rd party, can be Data set(s) are provided by files that provided by anyone can be consumed by PlaniSphere. and/or any organization. GeoTIFF [36] Can be either 3rd party, can be Data set(s) are provided by files that base or overlay provided by anyone can be consumed by PlaniSphere. layer depending and/or any on the data organization. contained in the shapefile. WMS Can be either 3rd party, can be Data set(s) are provided by GIS base or overlay provided by anyone servers that are available on the layer depending and/or any Internet. Note the GIS servers must on the data organization. implement the WMS 1.3 protocol in retrieved from order to be consumed by PlaniSphere. the map server.
When it comes to using dissolve and merge as methods for geospatial aggregation it is obvious that these methods are inappropriate since they operate on a single layer. From the above discussion
PlaniSphere will support multiple instances of different types of layers. When it comes to using spatial merge as a method for geospatial aggregation is becomes obvious that the layers supported by PlaniSphere may not have access to individual attribute values of the geospatial data rendered by the individual layers. In PlaniSphere each layer is a graphical rendering (a picture) of geospatial data. A different strategy for geospatial aggregation is required than dissolve, merge or spatial joins. In this project it is proposed that aggregation be based on graphical characteristics of the geospatial data. In other words the geospatial data is represented by an instance of its layer types. After all of the layers have been created then they will be ordered. The highest order of precedence will be given to the background layers and the lowest to the overlay layers. There may be a need from the user to correctly order the overlay layers. Once the ordering has been set than layers may be fused and rendered. The end result of the rendering will be a visual representation (a picture) containing all of the geospatial data.
Algorithm 1: Algorithm for Graphical Aggregation and Fusion of Geospatial Data. This algorithm refers to Java and NASA World Wind Types such as RenderableLayer, TiledImageLayer, etc…
For each geospatial data source (WMS endpoint or ESRI shapefile, GeoTIFF and KML file) create its appropriate layer. A layer is a direct or indirect instance of RenderableLayer or TiledImageLayer types. Identify the type of data source. i. If it is a known file (ESRI shapefile, GeoTIFF, or KML), parse it, and load its content into a single instance of an appropriate layer type. Geospatial data consumed from an ESRI shapefile, GeoTIFF, or KML file may be represented by an instances of RenderableLayer type. ii. If it is a WMS endpoint, download the geospatial data into an instance of an appropriate layer type. Geospatial data produced by WMS endpoints may be represented by an instance of TiledImageLayer type. Identify categories of layers (base layers, overlay layers).Layer category can be determined from the geospatial data represented. Base layers have a solid background or are a solid image without any transparent sections. Overlay layers contain transparent sections. Order layers so overlay layers are always on top of base layers. User intervention may be required in this step. Note, since base layers have a solid background (no transparencies) only one base layer will be visible after completion of this algorithm.
Render all layers on screen based on order created in previous step. Always render background layers first followed by rendering of overlay layers. A consequence of this step is that any overlapping geospatial data will be overwritten with geospatial data from the currently rendered layer. An image will be created as an end result of completing the above steps.
Algorithm 1 is useful in aggregating geospatial data of a graphical nature. The files that compose the geospatial data are maps or content that can be converted into an image. GeoTIFFs are images with geotags. ESRI shapefiles are simplified 2D maps. On the other hand KML files are XML files that contain information that can be drawn on top of a map. Algorithm 1 may be used interactively by a user in their viewing session. That is the user can select in real time the area of interest and the layers to be aggregated. Algorithm 1 has been created by Mihal Miu and implemented in PlaniSphere. The resulting image is generated almost immediately (usually after a 5 to 20 second wait). The user may interactively reorder the layers as needed. Each time layers are reordered a new image is generated. Figure 16 exhibits an example of aggregating layers in a viewing session. Out of all of the layers available only two layers are visible and used in the aggregation. Only visible layers are aggregated using Algorithm 1 by PlaniSphere. The two visible layers from Figure 16 involved in the aggregation and fusion are “Bing imagery” and “planet_osm_line”. “Bing imagery” is a base layer while “planet_osm_line” is an overlay layer.
The major advantage of Algorithm 1 is that there is no need to convert geospatial data from one format or type to another format or type. In other words there is no need for a common format or data type. Once the geospatial data can be understood it is simply rendered using OpenGL. A secondary advantage of Algorithm 1 is that it may support multiple sources of geospatial data obtained from public suppliers as well as from commercial vendors. Figure 16 shows PlaniSphere used interactively to aggregate geospatial data from Bing and OpenStreetMap. It can be seen an aerial image from Bing (commercial vendor) with a road map from OpenStreetMap (a non-profit foundation that supplies freely-reusable geospatial data).
The first disadvantage of Algorithm 1 is that it will only display a single base layer. Since a base layer has a solid background (no transparencies or no transparent sections) the top most base layer will be displayed after aggregating and fusing all of the geospatial data. In other words, if multiple base layers are aggregated and fused, only the top most base layer will be visible. The geospatial information from the other base layers will be lost. The second disadvantage of Algorithm 1 is that overlay layers will
replace overlapping geospatial information of layers that under them. This may be a base layer or other overlay layers. In order to overcome this disadvantage it is important for all geospatial information represented by layers to be up to date otherwise the resulting aggregated data will be inaccurate.
Layer Format PlaniSphere uses the same layer format as World Wind for Java. PlaniSphere and World Wind for Java use a Pyramid Tile Structure supported by a file format (see figure 17a). The Pyramid Tile Structure uses the Plate Caree projection for its imagery. This projection allows a rectangular image of 2x1 ratio to be mapped to a sphere (see figure 17b). Tiles closest to the apex of the pyramid have the lowest resolution (or highest scale) while tiles closest to the base of the pyramid have the highest scale. This fact will affect aggregation. If aggregation operates on geospatial data of high resolution than areas of interest will be visible. If aggregation operates on geospatial data of low resolution than areas of interest that are of a smaller scale may not be visible.
Figure 17a: A Pyramid Tile Structure, courtesy of OSGeo (http://wiki.osgeo.org).
Figure 17b: Plate Caree Projection, courtesy of World Wind Central (http://www.worldwindcentral.com)
The coordinate system of PlaniSphere and World Wind for Java starts at the lower left corner (see figure 17c). For performance reasons multiple copies of the same maps are stored in successively higher resolutions based on levels. The first level starts at 0 (level 0). At level 0 the world is divided into 36x36 degree pieces. This division results in 50 tiles. For the next level, level 1 the world is divided into 16x16 degree pieces. This division results in 200 tiles, in other words it quadruples the number or tiles compared to the previous layer. Figure 17d show the tile division and degree pieces for levels 0, 1, and 2. At any level a tile is a 512x512 pixel square image of a PNG, JPEG or DDS format or file type.
Figure 17c: Coordinate System, courtesy of World Wind Central (http://www.worldwindcentral.com)
Figure 17d: Tile division and degree pieces, courtesy of World Wind Central (http://www.worldwindcentral.com)
Tiles are downloaded using WMS or created from file (ESRI shapefile and GeoTIFF) and stored in a cache folder based on detail level. The folder structure for the cache is the following “\cache\WorldWindData\ServerName\DataSetName\LayerName\LevelNumber\Row\Row_Column.Ima geFormat”. A “ServerName” may be an internet domain name or an internet protocol address. A “DataSetName” is optional and is dependent on the configuration of the WMS server supplying geospatial data. A “LayerName” may be any of the names seen in the layers panel from figure 16. An “ImageFormat” may be a PNG, JPEG or DDS file type.
Export Capability PlaniSphere can support the following file formats: ESRI shapefiles, GeoTIFF, and KML. When it comes to export support which file formats are best to use? ESRI shapefiles are not appropriate for export since they do not have any topographical information associated with any of the attributes represented (points, lines and polygons). This was discussed in the “Layers and Aggregation of Layers” section. Exporting geospatial data into an ESRI shapefile would result in a loss of information. At best a 2D map/image would be produced instead of a 3D map/image. KML files are not appropriate for export since they are used to display metadata. KML files are well suited for overlay layers but not base layers.
This was also discussed in the “Layers and Aggregation of Layers” section. Exporting to a KML file would result in a loss of information.
PlaniSphere supports two methods for exporting maps. The first and the simplest method is to aggregate all of the layers and fuse them into one Portable Network Graphics (PNG) image. Unfortunately all of the geospatial information or geospatial properties are lost. The end result results in an image of a PNG format with no geospatial information associated with it [37]. Such an image is hard to interpret unless you can visually recognize the area. Another restriction is that the image cannot be used for future processing.
The second method is to aggregate layers and fuse them into a single GeoTIFF image. Not all layers types can be export. Only layers that support geotags are used in the export. These are layers that are derived from TiledImageLayer and/or SurfaceImageLayer types. The resulting GeoTIFF contains all of the geographic/geospatial information. On average the time taken to generate export a GeoTIFF is anywhere from 20 seconds to 3 minutes. The GeoTIFF has a file size anywhere from 10 to 25 megabytes. See Algorithm 2 listing for the details of the GeoTIFF export. Algorithm 2 has been created by Mihal Miu and implemented in PlaniSphere. It should be noted that Algorithm 2 only produces a single GeoTIFF as a final result.
Algorithm 2: Algorithm to export multiple layers into a single GeoTIFF. This algorithm refers to Java and NASA World Wind Types such as BufferedImage, TiledImageLayer, SurfaceImageLayer, etc…
Create a list named imageLayerList of TiledImageLayer types Create a list named surfaceImageLayerList of SurfaceImageLayer types Create a list named imageArrayList of BufferedImage types. Extract the visible sector of the 3D virtual globe from Planisphere For each item in imageLayerList perform the following o Create an instance of BufferedImage (with transparent background) and dimensions based on the visible sector extracted earlier. o Copy the visible sector from item in question from imageLayerList into the instance of the BufferedImage created in above step. o Add the instance of the BufferedImage to imageArrayList For each item in surfaceImageLayerList perform the following o Create an instance of BufferedImage (with transparent background) and dimensions based on the visible sector extracted earlier.
o Copy the visible sector from item in question from surfaceImageLayerList into the instance of the BufferedImage created in above step. o Add the instance of the BufferedImage to imageArrayList For each item in imageArrayList use ImageUtil.mergeImage() to merge the current layer with the neighboring layer immediately besides the item in question. This operation needs to be performed in a single direction with regards to the imageArrayList. This is necessary in order to fuse each layer only once. When all of the items in the imageArrayList have been merged into each other resulting in the production of a single image of type BufferedImage. Write the single image of type BufferedImage produced by the previous step into a file using a GeotiffWriter. The visible sector extracted earlier can be used to tag the image with geospatial information (latitude and longitude of the four corners belonging to the image produced). Now a GeoTIFF has been produced.
GeoTIFF export capabilities are widely supported by geospatial data editing software such as QGIS and ArcGIS for Desktop. Geospatial viewing software such as Google Earth and ArcGIS Explorer Desktop do not support GeoTIFF export capabilities. It is extremely difficult or nearly impossible to compare Algorithm 2 to other GeoTIFF export implementations. For example ArcGIS for Desktop is a commercial product with a closed-source. QGIS is an open-source product. A comparison of algorithm 2 to QGIS’s export capabilities would not be appropriate since QGIS exports from raw files while Algorithm 2 is optimized for exporting geospatial data from Pyramid Tile Structures. A problem that arises when exporting from raw files is that the files themselves may have different projections. If such a case occurs than the export algorithm will have to convert from one projection to another. The situation becomes worse when the raw files are incomplete by not having a projection specified. If this is the case it will be up to the user to choose a default projection. If the wrong default projection is chosen then there end resulting GeoTIFF from an export will be distorted (not accurate representation or not an accurate map).
Pros with regards to the Export Capabilities The PNG export capabilities produce an image that may contain any desired level of detail and include all layers. The desired level of detail is managed by the zoom level of the 3D virtual globe. The PNG image produced is a small file that can be emailed as attachments. File sizes are generally less than 2 megabytes in size.
The GeoTIFF export capabilities produce an image that may contain any desired level of detail. The desired level of detail is managed by the zoom level of the 3D virtual globe. The GeoTIFF image
produced can be used for further import/export/analysis by PlaniSphere or other products or services. The GeoTIFF export capability represents a common format that may be used to share geospatial information between systems regardless of the manufacturers.
Cons with regards to the Export Capabilities The PNG export feature produces an image that contains no geospatial information or geospatial attributed associated with the map. This image is extremely difficult to use for import/export/analysis unless it is aided by a user or an agent with knowledge of the area represented by the image.
The GeoTIFF export capability takes time ( ) to produce an image. On average the time taken to export a GeoTIFF is anywhere from 20 seconds to 3 minutes. The GeoTIFF has a file size anywhere from 10 to 25 megabytes. Due to their large size it may be impossible to email GeoTIFFs as attachments.
The GeoTIFF export feature has the capability to be maliciously used in creating images or maps that represent copyright violations. Suppose you use Bing Aerial image as a base layer you superimpose an OpenStreetMap overlay layer. You have created an aerial images that has its roads labeled. If a GeoTIFF export is performed and the resulting GeoTIFF image is used by any party the potential for a copyright and/or user license violation has occurred. First, NASA has licensed Bing Aerial images to be used by NASA World Wind but not by any third party servers/utilities unless such third parties have a license from Microsoft. Second no copyrights have been stated for either Bing Aerial and OpenStreetMap images. Such a situation is demonstrated in Figure 18.
Figure 18: An export of a Bing base layer with an OpenStreetMap layer.
System Architecture PlaniSphere is built using the NASA World Wind API. It offers a tessellator that may display geospatial information in 3D. The component responsible for rendering is WorldWindowGLCanvas (it is part of the gov.nasa.worldwindow.awt package). It is responsible for rendering using JOGL, the Java binding for the OpenGL 3D graphics API [38]. WorldWindowGLCanvas will rendering geospatial information that is represented by an instance of BasicModel (it is part of the gov.nasa.worldwind package). An instance of BasicModel may not be accessed directly but through an interface named Model (it is part of the gov.nasa.worldwind package). The Model/BasicModel represents the data that makes up the virtual globe. A simplification would be to say single instance of Model/Basic model represents a single layer.
NASA World Wind provides file import utilities that have the ability to import ESRI shapefiles, GeoTIFF and KML files. NASA World Wind provides WMS consumption utilities that have the ability to connect to
WMS endpoints that are on a local network or on the internet. PlaniSphere will directly use the file import utilities and WMS consumption utilities.
The NASA World Wind API lacks export capabilities and a plug-in infrastructure. This project will develop export capabilities (see Export Capability section) and a generic plug-in infrastructure named Spatial Plug-in Infrastructure (see Expandability section below). Figure 19 shows a general architecture of components and utilities that are re-used and newly created.
Figure 19: System Architecture of Components and Utilities used by PlaniSphere
PlanOSM a Precursor to PlaniSphere PlanOSM is a simple application that is geospatial data specific. PlanOSM was created by Mihal Miu and was presented at the OpenStreetMap, State of the Map, 2011. PlanOSM is a desktop application that displays geospatial data created by the OpenStreetMap project. It has the ability to aggregate geospatial data exposed by web services that are offered by OpenStreetMap’s API. As an application PlanOSM is limited in its functionality. Put simply, it lacks many of the features that PlaniSphere offers. However many features that PlanOSM offers or failed to offer have influence the development of PlaniSphere. Observing figures 19 and 20 it can be seen that both PlaniSphere and PlanOSM appear very similar in nature. However they differ in their implementation.
PlaniSphere is geospatial data generic, while PlanOSM is geospatial data specific (only support OpenStreetMap geospatial data). PlanOSM can aggregate geospatial data but it cannot fuse it. On the other hand PlaniSphere can aggregate and fuse geospatial data. Another difference is that PlaniSphere can export aggregated and fused data that is georeferenced.
A major failure of PlanOSM is that it lacked the ability to support plug-ins. The spatial plug-in infrastructure developed in this project is generic in its nature. Therefore it may be incorporated into PlaniSphere and also PlanOSM. Achieving this will demonstrate the generic and application independent capabilities of the spatial plug-in infrastructure. This is further discussed in the next section, titled “expandability”.
Expandability PlaniSphere is built on top of NASA World Wind for Java. Developing applications using World Wind requires highly specialized knowledge of OpenGL (through JOGL), GeoSpatial concepts, open-standard interfaces to GIS services and databases, knowledge of high-resolution imagery and terrain from NASA and third party servers and extensive programming experience with Java. All of these requirements may be beyond the capabilities of many developers. A plug-in infrastructure would need to be created that may be used by a developer with basic knowledge of Java and a limited understanding of geography. This can be achieved by creating a plug-in infrastructure that abstracts the NASA World Wind or PlaniSphere implementation details (such as OpenGL/JOGL, open-standard interfaces to GIS services, etc…) from the plug-in developer.
There are two major goals in creating a plug-in infrastructure in this project. The first major goal is to create a plug-in infrastructure that may be used by multiple GIS applications. The consequence of this
goal is that a plug-in would be developed only once and it could run on multiple applications. The second major goal is to avoid the “second-system syndrome” when it comes to updating any GIS application [39]. The desire is to reduce the need for application upgrades through rewrites and increase the ability to add new capabilities through the creation of plug-ins.
The plug-in infrastructure will be lightweight and its design will be based on some of the principles outlined by Mayer et al in the “Lightweight Plug-in-Based Application Development” paper *40]. Mayer describes that every lightweight plug-in infrastructure is composed of three components: the plugin loader, the plugin interface and an implementation of the plugin. The plugin loader is implemented by the PluginManager class (see Table 6). The plugin interfaces is supported by two interfaces named: SpatialPlugin and SpatialPluginFrame (see Table 6). The plugin implementation is an actually working plug-in. An example would be the Wikipedia Plug-in demonstrated in section “Coding a new Plug-in”. Figure 20 presents our implementation of Mayer’s plug-in pattern. The methods implemented by the interfaces are presented in Figure 23a.
Figure 20: The plug-in pattern implementation created in this project
The functionality of the plug-in infrastructure will allow plug-in developers to add layer(s) to the virtual globe, add markers and metadata to any layer, navigate a map by moving to a different location, and changing the zoom level and select areas that may be exported. This functionality is limited in scope however it does provide for the ability to create useful and innovative plug-ins. This is demonstrated by the Wikipeida plug-in, logistics demo plug-in and the Land Analysis plug-in.
Although there are many plug-in frameworks available we are facing the unfortunate situation where there is a lack of lightweight generic plug-in framework that is used by multiple application (geospatial or otherwise). The Mozilla Foundation has created Cross platform component Object model (XPCOM).
XPCOM is a cross-platform component model [41]. It has many similarities to Microsoft’s Component Object Model (COM) [42]. XPCOM has been implemented in Mozilla Web Browser (obsolete application), Netscape Web Browser version 7.2 and higher (obsolete application), Firefox and thunderbird. This is a good example unfortunately it is a heavy weight infrastructure. One of the drawbacks comes from the language that it is implemented in, that is C++. This drawback is compounded since the infrastructure has to be supported by multiple languages and multiple operating systems. PlaniSphere is implemented in Java. Java is platform independent and from an applications development architecture point of view all platforms are treated the same.
The lightweight plug-in infrastructure developed in this project will provide a unique opportunity to be evaluated on two applications, which are PlaniSphere and PlanOSM. All plug-ins developed in this project will be tested on both applications (PlaniSphere and PlanOSM).
Implementing the Plug-in Infrastructure PlaniSphere will be supported by a plug-in infrastructure that may enable any developer to enhance its capabilities. The plug-in infrastructure is a generic plug-in infrastructure and it is developed independently of PlaniSphere. This infrastructure can be used by any Java application. In fact this plug- in infrastructure is used by PlaniSphere (see Figure 21) and also by PlanOSM (see Figure 22). One consequence of such a plug-in infrastructure is that any plug-in will work in PlaniSphere and also PlanOSM. That means that the same plug-in can be developed once, compiled once and deployed within all of the applications that support this plug-in infrastructure. The main question is how can this be achieved? The plug-in infrastructure is based on a Service Provider Interface (SPI). The SPI is an interface that is part of the plug-in infrastructure. It needs to be implemented by the application that support the plug-in framework. That means that PlaniSphere has its own implementation of the SPI and PlanOSM has its own implementation. Whatever application will support this plug-in infrastructure, they must also provide an implementation of the SPI as well.
At the heart of the plug-in infrastructure is the plug-in manager. The plug-in manager is implemented by a class named PluginManager. This class is responsible for creating instances of plug-ins and loading jar files that support the functionality of the plug-in. Only one instance of the PluginManager class needs to exist per application. To ensure this requirement the constructors for the PluginManager class are private. An instance of the PluginManager may be retrieved by using the getPluginManagerInstance()
method. This is a static method belonging to the PluginManager class. Any developer that implements a plug-in infrastructure for an application does not need to use the plug-in manager directly. A helper class named AdministrationGUI has been created. AdministartionGUI provides a graphical user interface to allow a user to manage plug-ins (load and unload plug-ins). The AdministrationGUI class has a method named createPluginInstance() that supports the capabilities of loading plug-ins and their supporting jar files. It is recommended that anyone that uses this plug-in infrastructure always manipulate directly an instance of AdministrationGUI class. In turn the instance of AdministrationGUI class will call the appropriate methods supported by the PluginManager class. There is no need to directly use an instance of the PluginManager class. See Figure 23a for a listing of methods supported by the classes that compose the plug-in infrastructure.
Both PlaniSphere and PlanOSM directly use an instance of AdministrationGUI class. This can be visually observed in figures 19 and 20. An instance of the AdministrationGUI class can be seen as a dialog that is displays information about the plug-ins. Both applications (PlaniSphere and PlanOSM) are configured by an xml file named config.xml. In this xml file the plug-in configuration information can be specified. The listing below shows a configuration file that can load a single plug-in. In Listing 1 a plug-in named “Wikipedia Extractor” can be seen. This is a logical entity, it can be any string or text. The same applies for the comment. It is desired that the comment accurately describe the plug-in loaded. The jar file where the plug-in resides will be configured using the jar-file tag. The libs tag will be used to configure the loading of any dependent libraries that the plug-in requires. If more than one jar file is required then they will be listed inside the libs tags where “:” is used as a separator between the dependent jar files. Parsing the xml configuration file is the responsibility of the application (PlaniSphere, PlanOSM) and not the plug-in infrastructure. This reason for this decision is to allow an application to support any configuration mechanism appropriate for the environment supported. See Listing 1 for configuring a plug-infor4 PlaniSphere.
Listing 1: A configuration file for PlaniSphere exhibiting the automatic loading of a plug-in on application start
Figure 21: PlaniSphere with the Plug-in Manager and Sample Plug-ins (JRE SysInfo and NMEA Parser)
Figure 22: PlanOSM with the Plug-in Manager and Sample Plug-ins (JRE SysInfo and NMEA Parser)
The plug-in developer may use the plug-in infrastructure to set magnification level, center the map (using latitude and longitude), add a new layer, add map markers to any layer and clear any layer of metadata such as map markers. The methods available to the plug-in developer are exposed by the SpatialPluginServiceImplementation (see Table 6 for a detailed description of the interfaces and methods of the plug-in infrastructure).
Table 6: Description of Plug-in Interfaces and Methods
Interface Name Used By Description SpatialPlugin Interface is implemented An interface that is used to by the plug-in developer. implement the simplest plug- in. SpatialPluginFrame Interface is implemented An interface that is used in by the plug-in developer. conjunction with SpatialPlugin. SpatialPluginFrame is used to declare a plug-in that has its own window. SpatialPluginVersion An instance of this class is A class that is used to represent created by the plug-in the version information of an developer instance of a plug-in. SpatialPluginServiceImplementation This interface is An interface that is used to implemented by the SPI represent the API to be used by developer and used by the the plug-in developer and Plug-in developer. implemented by the SPI developer. GenericMapViewer This interface is An interface that represents a implemented by the SPI graphical representation of a developer and used by the map. Plug-in developer. GenericMapMarker This interface is An interface that represents a implemented by the SPI POI based on latitude, developer and used by the longitude and altitude. Plug-in developer. AdministrationGUI, PluinManager Used by PlaniSphere. An instance of these classes are used to dynamically load and instantiate instances of plug- ins.
Figure 23a: Spatial Plug-in Infrastructure API and system boundaries. Please see Table 6 for description and usage of classes and interfaces.
Creating a plug-in using the Plug-in Infrastructure Creating a plug-in requires a developer to implement SpatialPlugin and SpatialPluginFrame interfaces (see Figure 23b). The SpatialPlugin interface defines methods that are required by the plug-in infrastructure to manage the plug-in. If this plug-in needs to have its own window than the SpatialPluginFrame interface must be implemented. The SpatialPluginFrame interface defines methods for managing the plug-in window. If the plug-in that you are developing needs a window than you must implement both interfaces, that is SpatialPlugin and SpatialPluginFrame (see MyPluginWithFrame in figure 23b). If the plug-in that you are developing does not need a window than you must implement one interface, that is SpatialPlugin (see MyPlugin in figure 23b). For a complete implementation of a plug-in please see the WikipediaPlugin in the “Coding a New Plugin” section.
Figure 23b: Implementing a PlaniSphere plug-in using the infrastructure defined in Figure 23a.
Pros of the Plug-in Infrastructure The plug-in infrastructure is entirely separate from PlaniSphere. That means that its source code is independent of PlaniSphere and it is also packaged independently of PlaniSphere. The same plug-in infrastructure is used by PlaniSphere and also PlanOSM. The plug-ins that are created using this infrastructure can be used by any application that uses this plug-in infrastructure. This project will demonstrate that PlaniSphere and PlanOSM may use the same plug-ins if both applications equivalently implement their own SPIs. The end result of equivalent implementations of SPI by applications will mean that a plug-in will work in PlaniSphere and also PlanOSM. The same plug-in can be used in both applications.
Cons of the Plug-in Infrastructure The main advantage of the plug-in infrastructure is its generic nature. This is also its weakness. Its generic nature results in limited plug-in development due to the abstraction provided by the SPI. The demo plug-ins (NMEAPlugin and WikipediaPlugin) add metadata to existing maps. This is extremely useful for labeling maps. However there are no capabilities to render any structures such as polygons on the map. Capabilities to render structure such as polygons can be added to a future version of the plug-in infrastructure.
Demo Plug-ins There are three demo plug-ins developed: NMEAPlugin, SysInfoPlugin and WikipediaPlugin. SysInfoPlugin is the simplest plug-in. It provides information with regards to the Java virtual machine that the application (PlaniSphere) executes within. This plug-in is used to test the functionality provided by the SpatialPlugin and SpatialPluginFrame. This plug-in does not interact with the map. The NMEAPlugin is used to test the SpatialPlugin interface, SpatialPluginFrame intrface and also the SPI provided by the SpatialPluginServiceImplementation interface.
NMEAPluginplug-in can load any NMEA text file produced by any GPS/Glonass/Galileo receiver. The path from the NMEA text file may be displayed on the virtual globe. This plug-in tests the interaction of the plug-in with a newly created layer that displays location information in the virtual globe.
The WikipediaPlugin is a plug-in that has functionality that is beyond the scope of testing for the plug-in infrastructure. The WikipediaPlugin can extract spatial data from Wikipedia using the Wikipedia GeoData extension [43]. Documentation using Wikipedia’s GeoData extension is available at http://www.mediawiki.org/wiki/Extension:GeoData . The WikipediaPlugin will extract spatial information and will plot it on the map. It will plot points of interest and label them. This is a unique
demonstration of aggregation of map data of different map formats. Take a standard map from NASA Blue Marble or Bing Maps or OpenStreetMap. Information from Wikipedia can be used to enhance a map by labeling points of interest (POI). In Figure 24 the POI are extracted from Wikipedia. The POI are the red markers and the light blue labels. Wikipedia, a social networking site may be used as a source for geospatial metadata [44]. Wikipedia contributors contribute articles. One of the components of an article may be geospatial data.
Figure 24: A Bing Aerial base layer with an OpenStreetMap overlay layer.
Coding a New Plug-in Creating a new plug-in is extremely easy. The plug-in developer needs to implement the SpatialPlugin interface and the optional SpatialPluginFrame interface. The code that represents the plug-in needs to be packaged as a Jar file. The code for the Wikipedia plug-in is available in Listing 2. The plug-in Jar file can be loaded by the plug-in infrastructure by modifying PlaniSphere’s config.xml. Listing 3 exhibits the configuration requirements for PlaniSphere’s config.xml used to load the Wikipedia plug-in.
Listing 2: The Java code representing the Wikipedia Plug-in implementation package com.zerotrak.plugin.examples; import com.zerotrak.plugin.GenericMapMarker; import com.zerotrak.plugin.PluginData; import com.zerotrak.plugin.SpatialPlugin; import com.zerotrak.plugin.SpatialPluginFrame; import com.zerotrak.plugin.SpatialPluginServiceImplementation; import com.zerotrak.plugin.SpatialPluginVersion; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.io.IOException; import java.io.InputStream; import java.net.MalformedURLException; import java.net.URL; import javax.json.Json; import javax.json.JsonArray; import javax.json.JsonNumber; import javax.json.JsonObject; import javax.json.JsonReader; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.SpringLayout;
/** * * @author mihal */ public class WikipediaPlugin implements SpatialPlugin, SpatialPluginFrame, ActionListener { private final String layerName = "Wikipedia";
SpatialPluginServiceImplementation spsi; boolean pluginStatus;
JFrame frame; private String vendor = "ZeroTrak"; private String description = "A plugin for displaying points of interest from Wikipedia."; private SpatialPluginVersion version = new SpatialPluginVersion(0, 1, 0);
JButton extractPOIButton; JButton clearPOIButton; public WikipediaPlugin() { pluginStatus = false; frame = new JFrame("Wikipedia POI Extractor");
JLabel titleLabel = new JLabel("Wikipedia Extractor"); JPanel titlePanel = new JPanel();
titlePanel.add(titleLabel); extractPOIButton = new JButton("Extract POI"); extractPOIButton.addActionListener(this); clearPOIButton = new JButton("Clear POI"); clearPOIButton.addActionListener(this);
SpringLayout layout = new SpringLayout(); frame.setLayout(layout); frame.add(titlePanel); frame.add(extractPOIButton); frame.add(clearPOIButton); layout.putConstraint(SpringLayout.WEST, titlePanel, 10, SpringLayout.WEST, frame.getContentPane()); layout.putConstraint(SpringLayout.NORTH, titlePanel, 10, SpringLayout.NORTH, frame.getContentPane()); layout.putConstraint(SpringLayout.EAST, titlePanel, 10, SpringLayout.EAST, frame.getContentPane()); layout.putConstraint(SpringLayout.WEST, extractPOIButton, 10, SpringLayout.WEST, frame.getContentPane()); layout.putConstraint(SpringLayout.NORTH, extractPOIButton, 10, SpringLayout.SOUTH, titlePanel); layout.putConstraint(SpringLayout.WEST, clearPOIButton, 10, SpringLayout.EAST, extractPOIButton); layout.putConstraint(SpringLayout.NORTH, clearPOIButton, 10, SpringLayout.SOUTH, titlePanel); //layout.putConstraint(SpringLayout.EAST, clearPOIButton, 10, SpringLayout.EAST, frame.getContentPane()); frame.setSize(300, 300); }
@Override public void actionPerformed(ActionEvent ae) { if (ae.getSource()== extractPOIButton) { double [] center = spsi.getCenter();
System.out.println("Center: " + center[0] + ", " + center[1]); processLocation(center[0], center[1], 1000);
} else if (ae.getSource() == clearPOIButton) { spsi.clearLayer(layerName); } } public void addMarker(double latitude, double longitude, String description) {
GenericMapMarker currentPosition = spsi.createMapMarker(description); currentPosition.setLat(latitude); currentPosition.setLon(longitude);
spsi.addMarkerToLayer(layerName, currentPosition); } public void processLocation(double latitude, double longitude, int radius) {
String urlStr = "http://en.wikipedia.org/w/api.php?action=query&format=json&list=geosearch&gsradius=" + radius + "&gscoord=" + latitude + "|" + longitude; try { URL url = new URL(urlStr); InputStream is = url.openStream();
JsonReader rdr = Json.createReader(is);
JsonObject obj = rdr.readObject(); JsonObject queryObj = obj.getJsonObject("query"); //System.out.println(queryObj.toString());
JsonArray geosearchArray = queryObj.getJsonArray("geosearch"); //System.out.println(geosearchArray.toString());
/* for (Object o:geosearchArray) { System.out.println(o.toString()); } */ for (int i = 0; i String title = poi.getString("title"); System.out.print(title + ", "); JsonNumber latNum = poi.getJsonNumber("lat"); System.out.print(latNum + " by "); JsonNumber lonNum = poi.getJsonNumber("lon"); System.out.println(lonNum); addMarker(latNum.doubleValue() , lonNum.doubleValue(), title); } } catch (MalformedURLException murle) { } catch (IOException ioe) { } } @Override public PluginData getPluginData() { PluginData pd = new PluginData(this.getClass().getCanonicalName(), description, "created"); pd.setSpatialPluginInstance(this); return pd; } @Override public String getVendor() { return vendor; } @Override public SpatialPluginVersion getVersion() { return version; } @Override public void active(boolean status) { pluginStatus = status; } @Override public boolean isActive() { return pluginStatus; } public void setVisible(boolean status) { frame.setVisible(status); } public boolean isVisible() { return frame.isVisible(); } public void setSize(int width, int height) { frame.setSize(width, height); } public int getWidth() { return frame.getWidth(); } public int getHeight() { return frame.getHeight(); } @Override public void setSpatialPluginServiceImplementation(SpatialPluginServiceImplementation spsi) { this.spsi = spsi; // create gps marker and layer to display it on the map //currentPosition = spsi.createMapMarker("Current Position"); spsi.addLayer(layerName); } } Listing 3: config.xml exhibits the configuration requirements to load the Wikipedia plug-in. It should be noted that the Wikipeida plug-in is dependent on java.json-1.0.3.jar library. tags --> Distribution This project created three algorithms and a software tool in the form of a virtual globe named PlaniSpherePlaniSphere is where the three algorithms were tested. The three algorithms are: algorithm 1 (an algorithm for graphical aggregation and fusion of geospatial data), algorithm 2 (algorithm to export multiple layers into a single GeoTIFF) and algorithm 3. Algorithms 1 and 2 are generic in nature, however they do depend on data structures (RenderableLayer, TiledImageLayer, BufferedImage, TiledImageLayer, SurfaceImageLayer) that are supported by NASA World Wind for Java. Algorithm 1 and algorithm 2 may be implemented by any interesting party. A requirement of using algorithm 1 and algorithm 2 successfully is that the virtual globe used provides equivalent data structures to the ones used in this project. That is equivalent data structures to RenderableLayer, TiledImageLayer, BufferedImage, TiledImageLayer and SurfaceImageLayerwill need to be provided. PlaniSphere is a powerful tool that facilitates aggregation and fusion of geospatial data. The major consequence of such power is that it has the potential to be used for geospatial data theft and/or copyright infringements. This is evident when using the export features provided by PlaniSphere. It can be argued that is an issue of user responsibility. At the same time it can be argued that responsibility also lie with the creators of such tools. Unfortunately this is a legal argument and jurisdiction comes into place. What can be deemed legal in one jurisdiction may be deemed illegal in another jurisdiction. Also this argument deals with legality which is a subject that is beyond the scope of this project. [45] In the previous paragraph it has been made evident that PlaniSphere can be misused with or without knowing it. PlaniSphere is required for demonstrating concepts developed in this project. Without knowing the distribution of users and their intent, distributing PlaniSphere may not be a wise course of action. In this project there has not been a study with respect to the distribution of users and their intent. It should be noted that such a study in not part of the requirements, hence it is viewed as beyond the scope of this project. NASA World Wind Java SDK is distributed under the NASA Open Source Agreement Version 1.3. This agreement states the responsibilities of the contributors, users and recipients. The NASA Open Source Agreement (NOSA) Version 1.3 may be downloaded from. In NOSA Version 1.3 under section “Obligations of Recipient”, paragraph “J” it is stated that “any export of any goods or technical data from the United States may require some form of export license from the U.S. Government”. For this project no such export license was obtained. To fully comprehend NOSA Version 1.3 document, knowledge of United States Distribution, License and Export Law is required. It should be noted that such a requirement in not part of the project requirements, hence it is viewed as beyond the scope of this project. The last two paragraphs demonstrated legal responsibilities with regards to distribution of the software tools created in this project, that is PlaniSphere. To avoid any such issues there are no current plans for distribution. After this integration project has been successfully defended by Mihal Miu, the issue of distribution may or may not be reconsidered. Potential Usage and Domain Specific Application Examples Education PlaniSphere as a desktop application that is easy to use, it supports multiple operating systems, presents geographic content in a 3D graphical format and it has the ability to use geospatial content supported by known and accepted standards. PlaniSphere will enable students to visualize and understand areas of interest. With PlaniSphere the barrier to physically visiting a locale will not be a barrier to understanding that locale. Geospatial information may be aggregated and fused into one 3D presentation. PlaniSphere may be used to for simple purposes (identifying camp sites and bicycle paths) to more complicated purposes (as identifying potential flood areas). PlaniSphere will present information from traditional map sources to non-traditional map sources (see Wikipedia plug-in) and will enable students to have a better understanding of the landscape and environments that they are studying and/or researching. Exploration Oil, gas and mineral exploration geoscientists are required to use diverse geospatial datasets. These geospatial datasets range from satellite imagery, to geological maps, to relief and topography sets. PlaniSphere can be used to aggregate and fuse all of these geospatial data sets. This can result in determining if an exploration project is viable either due to costs, environmental factors and/or legislation. Space and Planetary Exploration PlaniSphere may display geospatial datasets from other bodies in our Solar System. These datasets may be for the moon (Clementine and Hypsometric maps), Mars (Mars Global Surveyor, Mars Odyssey – Thermal Emission Imaging System), Venus (Magellan Imaging Radar and Hypsometric maps), and Jupiter (including satellites: Callisto, Europa, Ganymede and Io). [46] PlaniSphere may be easily extended to display orbiting crafts/satellites around the Earth. This is a very useful feature that can be used to manage crafts/satellites that are currently operational and ones that have to be retired. Non-operational orbiting satellites are a hazard to new and existing orbiting traffic. There are large data sets of orbiting structures provided by NASA, China National Space Administration (CNSA), European Space Agency (ESA) and Japan Aerospace Exploration Agency (JAXA). Each organization uses a preferred geospatial referencing for their datasets. The tools to translate from one geospatial reference to another may not exist. This prevents these datasets to be aggregated and fused. [47]. Figure 25a: Lunar Orbital Mosaic, Colorized and Shaded Elevation available from Jet Propulsion Laboratory WMS server. Figure 25b:Lunar Orbital Mosaic, Shaded Relief Elevation available from Jet Propulsion Laboratory WMS server. Figures 25a, 25b and 25c are images retrieved from the Jet Propulsion Laboratory public WMS server. The URL for the WMS server from the Jet Propulsion Laboratory is http://onmoon.jpl.nasa.gov/wms.cgi . This URL can directly be consumed by PlaniSphere and the end result is exhibited in Figures 25a, 25b and 25c. Unfortunately, the Lunar Orbital Mosaic web site (http://onmoon.jpl.nasa.gov/) provides little documentation and the majority of links with regards to the data sets are broken. Putting this issue aside we can compare figure 25b with 25c. What is obvious from the pixelization in Figure 25c is that there is no high resolution data available. Figures 25a and 25b show a general overview of the moon representing low to medium resolution images. [48] Figure 25c: Lunar Orbital Mosaic, Shaded Relief Elevation available from Jet Propulsion Laboratory WMS server. This image is at a higher resolution (lower scale) than the image in Figure 25b. “The Lunar Reconnaissance Orbiter Camera, or LROC, is a system of three cameras mounted on the Lunar Reconnaissance Orbiter (LRO). LROC captures high resolution black and white images and moderate resolution multi-spectral images of the lunar surface.” *49] The Arizona State University is responsible for hosting a public WMS server that displays a detailed Lunar Orbital Mosaic data set. Figures 26a and 26b show high resolution images of the lunar surface. It should be noticed that points of interest are labeled. This dataset has a higher resolution than the dataset made publicly available by the Jet Propulsion Laboratory. Note the images in Figure 26a and 26b are a great improvement (in terms of resolution and level of detail displayed) over the images from figures 25a, 25b, 25c. Also note that several points of interest are labeled. The URL for the LROC public WMS server hosted by the Arizona State University is http://webmap.lroc.asu.edu/. This URL can be directly consumed by PlaniSphere. Figure 26a: Lunar Orbital Mosaic from LROC WMS server (http://webmap.lroc.asu.edu/). Figure 26b: Clementine Elevation Map from LROC WMS server (http://webmap.lroc.asu.edu/). Figures 26a and 26b provide two examples of aggregating and fusing geospatial datasets of the moon. Figure 26a has a background layer “Lunar Orbiter Global Mosaic” and a foreground layer “Lunar Nomenclature”. Figure 26b has a background layer “Clementine Elevation Map” and a foreground “Lunar Nomenclature”. What is important about these two examples is that the geospatial datasets have been created at different times. Both of the background layers have been created by LROC. It is the overlay layer, Lunar Nomenclature that is interesting for this discussion. This layer has been created by multiple astronomers. The web-site Moon Views (http://www.moonviews.com/nomenclature-and- naming) explains naming conventions and who provided the data for the Lunar Nomenclature dataset. The Lunar Nomenclature has been created by observing different types of images from LROC where points of interests have been labeled manually. A tool like PlaniSphere may be used to view imagery from LROC. Furthermore a tool like PlaniSphere may be used in aiding the completion of the Lunar Nomenclature dataset. After the Lunar Nomenclature dataset has new entries it can be aggregated and fused with LROC imagery using PlaniSphere. This will produce an updated map of the moon. The Lunar Orbital Mosaic and Clementine Elevation Map display images of different aspects of the moon. Interactive viewing session may be facilitated by PlaniSphere where the user can alternate between Lunar Orbital Mosaic and Clementine Elevation Map with the aid of an implementation of Algorithm 1. Algorithm 2 may be used to export areas of interest as GeoTIFFs. As demonstrated in the previous paragraph PlaniSphere has the potential to aid astronomers in mapping planets and bodies in space that may not be visible with telescopes. In 2015, NASA’s New Horizons spacecraft provides imagery of Pluto [50]. This is the first time where the Pluto may be studied using high resolution imagery. An obvious step is to create a nomenclature dataset by labeling points of interest. Once this is complete both the imagery and nomenclature dataset may be aggregated and fused to produce a high resolution map of a planet that we know very little of. Such a map would give a better understanding with respect to planetary evolution and geology. Most important these steps have a similar methodology as outlined in the previous paragraph with respect to the LROC imagery and Lunar Nomenclature. All of this may be achieved with the aid of PlaniSphere. Logistics Plug-ins can enhance PlaniSphere to aid logistics managers in efficient planning and coordination of their assets. Such a plug-in has been created for connecting to ZeroTrak, an asset monitoring service (available at www.zerotrak.com). This plug-in enables you to view assets in real-time. It has the ability to connect and consume a rest web service exposed by ZeroTrak’s API. A layer in PlaniSphere will be represent assets using red markers. See figures 27a and 27b showing a display of asset information (vehicles) on PlaniSphere. Figure 27a: Tracking multiple assets (vehicles). Notice the plug-in that connects to the ZeroTrak service is located on the top left of the image and “ZeroTrak Asset Monitoring” can be seen in the title bar of the window. Figure 27b: Tracking a single asset (vehicle) The ZeroTrak asset monitoring plug-in demonstrates aggregation and fusion of geospatial map data (Bing imagery, LandSat imagery and OpenStreetMap road maps) and metadata. Aggregation of Bing imagery, LandSat imagery and OpenStreetMap road maps has already been demonstrated in Figures 7 and 16. The ZeroTrak asset monitoring plug-in has the capability to consume a rest web service and retrieve metadata (including location information such as latitude and longitude). This information can be graphically aggregated on top of the existing geospatial information (Bing imagery, LandSat imagery and OpenStreetMap road maps). Figure 27c shows a brief overview of the ZeroTrak asset monitoring plug-in. It should be noted that the rest web service uses a proprietary API made available by one of the servers at www.zerotrak.com. The rest web service abstracts the implementation that is used to store and retrieve asset information (vehicle information) or metadata. Furthermore from the point of the plug-in developer the metadata is in a stored in an unknown format. In fact this format is proprietary to ZeroTrak. Location information (latitude and longitude) is a very small component of the state of the vehicle. The ZeroTrak asset monitoring plug-in uses three features from the plug-in infrastructure. First a layer is created that will house all information with regards to the assets displayed. Second markers are created. A single marker will represent a single asset. Third is where all markers are associated with a layer. In other words add the created markers (second feature) are displayed by the map layer (first feature). The ZeroTrak asset monitoring plug-in provides functionality that was is not supported by PlaniSphere. It provides the ability to consume a proprietary API exposed by a rest web service. It also provides the ability to retrieve metadata and manipulate it in such a form that it may be displayed by PlaniSphere. In other works the data is managed into markers that are stored in a layer. Note the marker(s) and layer(s) are supported by PlaniSphere via the plug-in infrastructure. Figure 28: ZeroTrak Asset Monitoring plug-in (This figure is an enhancement of figure 9 by adding a plug- in infrastructure including the example plug-in, “ZeroTrak Asset Monitoring plug-in”). Land Analysis Land analysis can provide detailed information with regards to the ecological system, biological diversity, land usage, agricultural usage, developed areas and urbanization. If land analysis could be performed from geospatial data than there would be no need for having physical access to the area in question. This will enable us to gain massive amounts of information without any travel requirements. One of the simplest and easiest land analyses to perform is the level of urbanization for an area of interest. This can be achieved from observing the green colours from the non-green colours [51]. The green colours represent vegetation while the non-green colours represent developed areas. Unfortunately when it comes to urban planning there is a need to understand the type of vegetation encountered and to distinguish among the infrastructure available from roads, buildings, houses, rail and so on. This requirement gives rise to a higher level of land analysis than simple analysis with regards to urbanization [52]. From any visual inspection of any aerial imagery one can see that there are many colour visible. The most obvious observation is that roads have very dark colours (dark greys or blacks). This is true in an urban environment since roads have a top layer of asphalt. On the other hand in non- urban environment roads may be of compressed dirt in which case they will be visible as a brown band on an aerial imagery. When it comes to analyzing vegetation one encounters many shades of green. It would be desirable to have a methodology to identify if the different shades of green represent different vegetation. Such methodology will enable remote land analysis. How can vegetation types be identified from an aerial image? The solution proposed is that colour matching be performed. It is assumed that each vegetation type will have its distinct colour. A carefully analysis of distinct areas (from Figure 29) represented by different colours reveals that each area does not have a single distinct colour. The correct statement would be to say that an area has a distinct colour range. This will allow for a colour range to be mapped to a particular vegetation type/subtype. Once the colour range matching is performed, areas occupied by each vegetation type can be calculated. This can be compared with existing census data. If the resulting numbers are a match than the colour range matching works. If not than the colour ranges used will need to be redefined. All of this is demonstrated in the land analysis plug-in that has been created for PlaniSphere. In Figure 29 it can be seen that there is a difference in colour from the center of the image to the right of the image. The obvious explanation is that images were taken at different times, hence the difference in visible colors. Such occurrences would need to be taken into account when colour range matching is performed. In other words there needs to be some flexibility to handle images taken at different times. Note, different times can be different seasons, or different times in the same day (morning, afternoon or evening). In the methodology section it was stated that “for the purpose of aggregating and fusing geospatial information there is no need to contemplate issues such as data incompatibility and data conversion. ”This remains a true statement but when it comes to land analysis our overall purpose changes. This time geospatial data is needed that is meaningful and/or usable for analysis purposes. In our case there is a need for user intervention to select an appropriate map (aerial image such as Bing or satellite image such as LandSat and not a road map such as OpenStreetMap) for analysis. In this case the geospatial data that is aggregated and fused matters. Figure 29: An area of interest within the Athabasca River Basin. Notice the non-uniformity in the colouring scheme. Bright colours are encountered on the right side of the image while the left and center has faded colours. Land Analysis Plug-in A colour matching process based on colour ranges has been implemented as a PlaniSphere plug-in. First question to ask is how is a single colour represented and second is how are colour ranged defined? The answer to the first question is to represent a single colour using the RGB (Red, Green Blue) color model. The RGB color model is used by television screens, computer screens, digital cameras, video cameras, image scanners and so on. [53] Figures 30a and 30b exhibits colours and their appropriate RGB values (written using hexadecimal values). Figures30a and 30b can be further used to identify colour ranges. Now that it is known how to represent single colours how will a colour range be defined. A visual inspection from figure 29, it becomes apparent that there is a need to work with multiple colour ranges in order to effectively analyze an area of interest. How will a colour range be defined? The simplest representation of a range can start with a fixed colour and a maximum defined distance where a comparing colour may be determined to be within or without the defined distance. In other words colour difference is performed between the fixed colour and the colour in question. If the distance is less than or equal to the maximum defined distance than the colour is in range otherwise it is not. [54] Colour may be plotted on a three dimensional Euclidian space where each dimension may be represented by red values, green values and blue values. Note the valid range of values is from 0 to FF in hexadecimal notation or from 0 to 255 in decimal notation. Distance between colours may be determined using the Euclidean distance formula. [55] Colour analysis requires the GeoTIFF export function provided by PlaniSphere and the plug-in infrastructure. The GeoTIFF export function generates a 32-bit colour depth GeoTIFF, where 8-bits are used to represent red colours, 8-bits are used to represent green colours, 8-bits are used to represent blue colours and 8-bits used for the alpha channel used for transparency. It should be noted that 32-bit colour is the highest depth of colour that may be represented without requiring sophisticated video hardware. [56] Each colour range needs to have a used defined name, a range of values (this is the colour range) and an optional user defined comment. It is proposed that all of this be represented by an XML file. It should be noted that XML files can be easily created using a simple text editor. Listing 4a represents an XML file that has defined five colour ranges. More accurately Listing 4a has defined five shades of green. Listing 4a: A definition of colour ranges. Figure 30a: RGB Primary/Basic ColourValues. [57] Figure 30b: RGB Secondary/Mixed Colour Values. Note this table is a subset of all possible colour values. [58] Figure 29 does not have a uniform colouring scheme. This issue can be resolved from creating multiple colour ranges. For example you can have a colour range for images taken at mid-day. At mid-day light is at its brightest, there is an absence of shadows and it is expected for colours to be at their brightest. The opposite will occur in the morning and evenings. Light is not as bright as it is for mid-day and there will be a presence of shadows. Hence it is up to the user to appropriately define colour ranges to adjust for handling situations with non-uniform colouring schemes. Note Listing 4b has an additional four bands when compared to Listing 4a. The additional four bands represent different shades of brown. The colour map defined in Listing 4a may partially analyze the image from Figure 29. That is it will only take into account shades of green. While Listing 4b has the green shaded and an additional four brown shades. Listing 4b may be used to analyze both the green areas and non-green areas or barren fields. Listing 4b: An enhanced definition of colour ranges. Figure 29 shows a large area. This area is larger than what we may want to analyze. The user will be able to select an area or a subset of the area displayed. A selector will have to be used. A selector is simply defined as a rectangular area defined by the user. Colour range matching will be performed within the area encompassed by the selector. Once colour ranges exists and an area of interest has been selected than analysis can be performed. The plug-in will count all the pixels that are matched by the colour ranges. Once all of the matched pixels have been tabulated than the areas that they represent may be calculated. Hence the outcome of this will be the area represented by each colour range. The resulting area analysis will be saved in a text file (see Listing 5 for an example). Once the colour range file has been created and it is acceptable for analysis an area will have to be selected. Selecting an area requires input from the user. The first criteria the user needs to take into account that an area selected should have a uniform colouring scheme. The second criteria is resolution or scale. The higher the resolution (or lower scale) the better the selected area is for analysis. These two criteria are exhibited by figures 31a and 31b. The selected area in Figure 31a has uses a non-uniform colouring scheme. Note the greens in the left to middle of the selected area and the faded darker colours in the top and right areas of the selected area. This would not be an appropriate selected area for analysis. On the other hand Figure 31b is a picture of a higher resolution and it has a uniform colouring scheme when compared to Figure 31a. These two criteria make the selected area in Figure 31b a good candidate for analysis. Figure 31a: Analysis of a selected area using PlaniSphere and the Land Analysis Plug-in. Note the area selected is a section of the Don Valley (Toronto, Ontario) with encompassing residential/urban areas. The change in coloration signifies that aerial images were taken at different times. Figure 31b: Analysis of a selected area using PlaniSphere and the Land Analysis Plug-in. Area selected represents a section of the Don Valley in Toronto. Note the area selected includes residential areas. Listing 5: Output of a colour range matching. A file can be around two to five megabytes in size. The majority of content has been omitted. Note the first two lines describing the size of the GeoTIFF and area occupied by a single pixel. Also notice the last three lines describing the area occupied by each colour range that was matched. GeoTiff image dimensions: width = 2048, height = 1722 GeoTiff scale: 1 pixel represents 1.0350654114450714E-6 km^2 GeoTiff area: 3.6503196436652297 km^2 ... Band 1 has a count of 1863 with an area of 0.001928326861522168 km^2 Band 2 has a count of 44892 with an area of 0.04646615645059214 km^2 Band 3 has a count of 92516 with an area of 0.09576011160525222 km^2 Band 4 has a count of 88440 with an area of 0.09154118498820212 km^2 Band 5 has a count of 81926 with an area of 0.08479876889804892 km^2 Listing 4a contains the colour map definition used to generate the analysis output from Listing 5. This colour map is extremely simple. All the colours in Listing 4a represent different shades of green. These may be used to map different types of vegetation such as forest, shrubbery and grass. Band 1 is the band that is closest to green. As you move to subsequent bands you progress closer to a band that closest to brown. From this it may be assumed that Band 1 will represent forest areas. At the extreme end Band 5 will represent a grassland. While the bands in between (Band 2, 3, and 4) will represent the progression between a forest and grasslands. In other words areas with growth that are between a forest and grasslands. The land analysis plug-in implements the pixel matching algorithm described by Algorithm 3. Algorithm 3 has been created by Mihal Miu and implemented in the Land Analysis plug-in for PlaniSphere. The land analysis plug-in produced three files: the GeoTIFF that represents an area of interest (see Figure 34a), a text file that contains detailed information with regards to pixel matched area (see Listing 7), and a PNG image or a map representing the matched colour bands (see Figure 34b). Algorithm 3: Land analysis pixel matching algorithm Extract an area of interest and export it as a GeoTIFF file. This will be referred to as the “GeoTIFF to be analyzed” from now on. Create an image that has the same dimensions as the “GeoTIFF to be analyzed”. This image will have a transparent background. This image will be referred to as the “band analysis image”. Define a colour structure that is composed of a colour defined by a red, green, and blue component and a tolerance integer value or distance integer value. A user is responsible for defining distinct colours where each colour is accompanied by a tolerance/distance integer value. Each distinct colour and its tolerance/distance integer value will be represented by an instance of the colour structure. Place all instances of the colour structures in an array. This array will be referred to as the “user colour array”. Create an array that has the same dimensions as the above array (“user colour array”). This array will hold pixel matching count for the specified colours in the “user colour array”. Initialize each array element to zero. This array will be referred to as the “pixel matched count array”. For each pixel in the “GeoTIFF to be analyzed” o Extract the pixel colour, where the colour is represented by a red, green, and blue component. o The extracted pixel colour from the above step will need to be matched to a colour from the “user colour array”. The criteria for a match is that the extracted pixel colour is within the tolerance/distance value of the element of the “user colour array”. The tolerance/distance is calculated by using the Euclidean distance formula on the red, green, and blue components of the extracted pixel colour and on the element from the “user colour array”. If the distance/tolerance is less than or equal to the value defined in the element of the “user colour array” than there is a match. Otherwise there is no match. . If there is a match than increment by one the appropriate cell in the “pixel matched count array”. . If there is a match than place the matched colour in the “band analysis image”. The pixel location is the same as the pixel location for the “GeoTIFF to be analyzed”. Calculate the area for all of the pixels matched based on the elements in the “user colour array”. Remote Land Analysis of two Parishes/Townships in Rural Alberta Land analysis will be performed using a three step process. The first step is to aggregate geospatial data. This step will produce a map (graphical image) where pixel analysis may be performed. The second step is to aggregate census data based on the same geographic boundaries used to aggregate geospatial data in the first step. The third step is to compare the data generated from the first step with the data from the second step. The first two steps demonstrate the capacity of data aggregation. The third step demonstrates the ability to compare data and with user intervention the ability to improve or complement the data. For example in Table 8 the pixel analysis technique was able to detect bodies of water (lakes, reservoirs, etc.). However the census data does not describe bodies of water. Hence this result due to pixel analysis may be used to enhance or even generate new census data based on remote analysis. Land analysis will be performed on two parishes/townships (TO39R20W4 and TO38R21W4) in rural Alberta. The parish/township named TO39R20W4, may be found north west of the Town of Stettler, south of Highway 601 and east of Highway 835. The parish/township named TO38R21W4 may be found south of highway 12, north of Township Rd 382, East of Range Rd 220 and west of Range Rd 210. A colour map has been created (see Listing 6) and it will be used for analysis of the two parishes/townships (TO39R20W4 and TO38R21W4). Listing 6 represents an xml file detailing the colour map to be used by the land analysis plug-in. The colour bands from Listing 6 may be seen in Figure33. Note the colours may not be reproduced properly in Figure33. High resolution media is required to view true colours represented in this image. In figure 32 it a Bing image map may be observed. On top of the Bing image the content from an ESRI shapefile. The shapefile contains the parish/township boundaries delimited by red lines. The boundary information will aid in selecting an area used for land analysis. Since analysis is performed by parish/township the entire parish/township will need to be selected. A graticule represents the top most layer in order to display parallels and meridians used for navigation purposes. The two layers required for analysis are the Bing image layer and the shapefile layer containing the parish/township boundaries. The graticule is optional. It is not necessary for analysis but the graticule helps out by identifying areas (based on latitude and longitude) and navigating from one area to another. Figure 32: Parishes/Townships used in land analysis Listing 6: Color map used for analysis of TO39R20W4 and TO38R21W4. See Figure 33 for actual colours. Figure 33: Colours represented by the colour map (xml file) from Listing 6. As it can be seen bands 1, 2, 5, 9, 14 are shades of green. Any space that is matched by these bands represent areas with plant growth. Bands 2, 3, 6, 7, 8, 10, 13 are shades of brown. This represents areas without any vegetation cover where the bare ground may be seen. This may be due to any of the facts: the land has been plowed, the land is bare, the land is resting (no planting for the season), and so on. This oversimplification does not take into account that as some plants mature they change colour from a green to a brown shade. This will occur with wheat and canola. Band 11 is used to match water reservoirs and lakes. Band 12 is a grey that can be used to match paved roads. Listing 7: Analysis of TO39R20W4 GeoTiff image dimensions: width = 2048, height = 2020 GeoTiff scale: 1 pixel represents 2.2546424831913203E-5 km^2 GeoTiff area: 93.27365767263164 km^2 … Band 1 - Wheat has a count of 370011 with an area of 8.342425198481036 km^2 Band 2 - Canola has a count of 316367 with an area of 7.132944784797885 km^2 Band 3 – Misc Crop has a count of 19557 with an area of 0.4409404304377265 km^2 Band 4 - Pasture has a count of 652560 with an area of 14.71289498831328 km^2 Band 5 - Canola has a count of 279269 with an area of 6.2965175163835685 km^2 Band 6 – Wheat has a count of 162296 with an area of 3.659194564520185 km^2 Band 7 – Pulses has a count of 81847 with an area of 1.8453572332175998 km^2 Band 8 – Wheat has a count of 132101 with an area of 2.978405266720566 km^2 Band 9 – Canola has a count of 337978 with an area of 7.620195571840361 km^2 Band 10 – Misc Crop has a count of 385964 with an area of 8.702108313824548 km^2 Band 11 – Water has a count of 82920 with an area of 1.8695495470622427 km^2 Band 12 – Road has a count of 1732 with an area of 0.039050407808873665 km^2 Band 13 – Pulses has a count of 2678 with an area of 0.06037932569986356 km^2 Band 14 – Wheat has a count of 404758 with an area of 9.125845822115524 km^2 Census Data Base Township: T039R20W4 km^2 Area: 95.43946342 km^2 Pasture: 12.57838907 km^2 Wheat: 25.69524796 km^2 Canola: 23.23719375 km^2 Pulses: 2.13112579 km^2 Road length: 112220.72 m Road density: 11.758314 m/ha 4.999963 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 32.500076 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 90.000262 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 136.000036 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period Figure 34a: Export of TO39R20W4 Figure 34b: Map generated from pixel analysis of TO39R20W4 export In theory a type of crop should be represented by a colour band. From the Bing aerial images used in this analysis it is difficult to determine the type of crop based on coloration. Bing aerial images are images that represent landscapes. Bing makes no claims as to the accuracy of the imagery. The coloration in the imagery may have been modified or altered during the processing stage. See section “Discussion with Regards to Using the Land Analysis Plug-In and its Methodology of Analysis” where a strategy is discussed to actually identify actual crop types with a high probability of certainty by using infrared imagery. In this discussion user defined colouration will be analyzed. In other words shades of greens will represent plant growth, shades of brown will represent pasture land, barren land, and/or land that is not planted. Also water areas (rivers, lakes, reservoirs) may be identified. All of this is performed in the next paragraph. It should be understood that obtaining colour infrared maps is not part of the requirements of this project and are outside the scope of this project. Listing 7 represents the land analysis of Figure 34a based on the colour map defined in Listing 6. As it can be seen the area analyzed is approximately 93.27 km2. The area covered by all 14 bands is approximately 72.82 km2. This represents that 78% of the area represented in by Figure 34a was matched by the color map from Listing 7. The green areas analyzed represented by bands 1, 4, 5, 9, 14 have an approximate area of 46.1 km2. The brown areas analyzed represented by bands 2, 3, 6, 7, 8, 10, 13 have an approximate area of 24.81 km2. Water represented by band 11 has an approximate area of 1.87 km2. Figure 34b represents a map generated using the colour ranges from Listing 6. Figure 33 may be used as a legend for understand how the land in Figure 34b is used. It should be noted that the map from Figure 34b represents the same information that is described in Listing 7. In other words the bands (Band 1, Band 2, and so on) from Listing 7 may be matched to Figure 34b using Figure 33 as a legend for the colour bands. Figure 34b is the end product of an implementing and execution of Algorithm 3 on the area referred to as TO39R20W4. Listing 8: Analysis of TO38R21W4 GeoTiff image dimensions: width = 2045, height = 2048 GeoTiff scale: 1 pixel represents 2.2276407768057945E-5 km^2 GeoTiff area: 93.29715995786957 km^2 … Band 1 – Wheat has a count of 121810 with an area of 2.7134892302271383 km^2 Band 2 – Canola has a count of 113434 with an area of 2.526902038761885 km^2 Band 3 – Misc Crop has a count of 2087 with an area of 0.04649086301193693 km^2 Band 4 – Pasture has a count of 956435 with an area of 21.305936063642502 km^2 Band 5 – Canola has a count of 163992 with an area of 3.6531526626993585 km^2 Band 6 – Wheat has a count of 56346 with an area of 1.255186472098993 km^2 Band 7 – Pulses has a count of 21259 with an area of 0.47357415274114384 km^2 Band 8 – Wheat has a count of 23802 with an area of 0.5302230576953152 km^2 Band 9 – Canola has a count of 628508 with an area of 14.000900493486563 km^2 Band 10 – Misc Crop has a count of 206136 with an area of 4.591969591676392 km^2 Band 11 – Water has a count of 19306 with an area of 0.4300683283701267 km^2 Band 12 – Road has a count of 48 with an area of 0.0010692675728667814 km^2 Band 13 – Pulses has a count of 157 with an area of 0.0034973960195850973 km^2 Band 14 – Wheat has a count of 499382 with an area of 11.124437064028312 km^2 Census Data Base Township: T038R21W4 km^2 Area: 94.78844473000001 km^2 Pasture: 31.95473127 km^2 Wheat: 21.102660710000002 km^2 Canola: 15.34267846 km^2 Pulses: 0.5994462765 km^2 Road length: 84168.2 m Road density: 8.879584 m/ha 3.749932 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 30.500412 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 86.002026 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period 133.75057 days of with max temperature over 30 degrees Celsius for 2009 to 2012 period Figure 35a: Export of TO38R21W4 Figure 35b: Map generated from pixel analysis of TO38R21W4 export Listing 8 represents the land analysis of Figure 35a based on the colour map defined in listing 6. As it can be seen the area analyzed is approximately 93.3 km2. The area covered by all 14 bands is approximately 62.64 km2. This represents that 67% of the area represented in by Figure 35a was matched by the color map from listing 7. The green areas analyzed represented by bands 1, 4, 5, 9, 14 have an approximate area of 52.78 km2. The brown areas analyzed represented by bands 2, 3, 6, 7, 8, 10, 13 have an approximate area of 9.41 km2. Water represented by band 11 has an approximate area of 0.43 km2. Figure 35b represents a map generated using the colour ranges from Listing 6. Figure 33 may be used as a legend for understand how the land in Figure 35b is used. It should be noted that the map from Figure 35b represents the same information that is described in Listing 7. In other words the bands (Band 1, Band 2, and so on) from Listing 7 may be matched to Figure 35b using Figure 33 as a legend for the colour bands. Figure 35b is the end product of an implementing and execution of Algorithm 3 on the area referred to as TO38R21W4. Figure 36: Land Analysis Plug-in Data Aggregation In Figure 32 it can be seen that there are two townships/parishes of interest: T039R20W4 and T038R21W4. The boundaries of the two townships/parishes can be seen by red outline. This geospatial data comes from an ESRI shapefile. PlaniSphere can directly consume geospatial data from any ESRI shapefile. However the shapefile has non-geospatial tabular data. This tabular data may be extracted from the ESRI shapefile and imported into a relational database. Once the data is in the database it may be queried. The Land Analysis Plugin directly connects to a local database and extracts census information about the township/parish being analyzed. This is exhibited in Figure 36. The data supplied by the database may be used to compare the effectiveness of the pixel analysis. Also new type of data may be introduces. At the end of Listing 7 and 8 (last four lines) it can be seen that there is climate related census information. This is new data that did not exist in any of the geospatial data. Discussion with Regards to Using the Land Analysis Plug-In and its Methodology of Analysis The land analysis plug-in is for demonstration purposes. It needs to be understood that the capabilities demonstrated by the land analysis plug-in are beyond the scope and requirements of this project. The land analysis plug-in aggregates geospatial data (WMS, ESRI shapefiles, KML, and GeoTIFFs) and also census data made available by a relational database. In this project there were no resources, nor skills available to evaluate the accuracy and effectiveness of the land analysis plug-in. The land analysis plug-in uses a three step process for performing land analysis. In the first step geospatial data is aggregated. In the second step census data is aggregated based on the same geographic boundaries used to aggregate geospatial data in the first step. In the third step demonstrates the ability to compare data generated from the aggregation of the first two steps. A summary of results between pixel analysis data and statistical data is exhibited in Table 8. User intervention was required to determine some of the crop type analysis (see Table 7) produced by pixel analysis. This presents the first issue. Identifying crop types is a non-generic process. The second issue has to do with the scale of image that pixel analysis is performed. That is pixel analysis may not produce similar results for different resolution imagery. The first obvious issue with the land analysis plug-in is that it is not a generic process. User intervention is required to be effective. Also the geospatial data may not be ideal or suited for analysis. Bing aerial imagery was used for analysis. When it comes to analyzing vegetation, colour infrared imagery is preferred. Vegetation reflects infrared light and it is highly visible on colour infrared imagery. Atmospheric effects such as cloud coverage affected the quality of Bing aerial imagery. Such an issue does not exist with colour infrared imagery. [59] The second obvious issue is that pixel analysis may not produce similar results for different resolution imagery. Image classification techniques for vegetation habitats are non-trivial. Different resolution imagery may reveal different vegetation groups. To correct such occurrences it is preferred to use texture analysis with the aid of Gabor filters and Gabor descriptors. [60] Listing 6 matched pixel colours of Figure 34a with a success rate of 78% and Figure 35a with a success rate of 67%. If we visually observe Figure 34a it can be seen that the fields are well defined and distinct colours may be observed between different fields. However when Figure 35a is visually observed it can be seen that the image is not as clear as in Figure 34a. The fields are noticeable however it is harder to determine distinct boundaries for certain areas. This is another argument for implementing Gabor filters and Gabor descriptors in the hope that it will increase the matching success rate beyond what is currently achieved by the land analysis plug-in. PlaniSphere implements Algorithm 1 for aggregation and fusion of geospatial data. Algorithm 1 is ideally suited for high resolution geospatial data. Figures 34a and 35a represent two distinct areas. The same areas are represented in Figure 32. It becomes noticeable that Figure 32 is of a lower resolution (higher scale) when compared to Figures 34a and 35a. The land analysis plug-in should operate on data of higher resolutions. This is desirable since higher resolution images will reveal a higher level of detail and also a more accurate representation of the physical surroundings observed. Table 7: Association between colour bands and crop types Crop Type Band Name Wheat Band 1 A green shade, representing planted wheat Band 6 A brown shade, representing mature or unplanted wheat Band 8 A brown shade, representing mature or unplanted wheat Band 14 A green shade, representing planted wheat Canola Band 2 A brown shade, representing mature or unplanted canola Band 5 A green shade, representing planted canola Band 9 A green shade, representing planted canola Pulses Band 7 A brown shade, representing mature or unplanted pulses Band 13 A brown shade, representing mature or unplanted pulses Misc Crops Band 3, A brown shade, representing unaccounted crops Band 10 A brown shade, representing unaccounted crops Pasture Band 4 A green shade, representing grassland Table 7 represents an association between colour bands and crop types. The association between the crop types and colour bands represent an educated guess based on a comparison of census data (from table 8) and the fact that a colour may represent a type of plant or a type of field. It should be understood that the association in Table 7 is an educated guess and may not be 100% accurate. Take for example wheat. A wheat field when it is planted it may be brown since the seeds are inserted into the bare ground. As the wheat starts to grow, a green field may be seen from an aerial photograph. When the wheat matures it changes its green colour to a golden or brown colour. Hence planted fields will not only be represented by green shades but also by brown shades visible in the aerial images. This is another argument for using colour infrared imagery to accurately determine crop types. Table 8: A comparison between pixel analysis data and statistical data. Parish/Township TO39R20W4 TO39R20W4 TO38R21W4 Census TO38R21W4 Census Data Analysis using Data Analysis using Bing Aerial Image Bing Aerial Image Wheat 25.69 km2 24.03 km2 21.10 km2 15.26 km2 Canola 23.24 km2 21.05 km2 15.34 km2 20.18 km2 Pulses 2.13 km2 1.85 km2 0.60 km2 0.47 km2 Crop 72.36 km2 56.19 km2 51.03 km2 40.86 km2 Pasture 12.58 km2 14.71 km2 31.95 km2 21.35 km2 Agricultural Land 84.94 km2 70.90 km2 82.98 km2 62.21 km2 Water NA 1.87 km2 NA 0.43 km2 Total Area 95.44 km2 93.27 km2 94.79 km2 93.30 km2 Table 8 provides statistical data stating mean (average) values for the 2009 to 2012 periods. If the results from the land analysis plug-in are compared to table 8 it becomes obvious that it is difficult to establish a relation. A comparison would not be appropriate since Table 8 provides mean values for the years between 2009 to 2012. The land analysis plug-in analyzed an image for a very specific time, that is a certain day of a certain year. Unfortunately it is unknown which day of which year the Bing images represent. The Bing images may or may not be for taken within the 2009 to 2012 time period. It may be before this period, it may be after this period. A fair comparison would be to obtain statistical data based on median values for a period of time. For the same period aerial images should be obtained for different time. Analysis should be performed on all of the images and a median comparison should be performed between the values obtained from analyzing the aerial images and the statistical data. It should be noted that using mean for analysis has a main disadvantage. Mean analysis is susceptible to the influence of outliers (values that are unusual compared to the rest of the data set). The pixel analysis presented in Table 8 can be improved in order to provide results that are closer to the census data. If the pixel count from Listing 7 and Listing 8 is analyzed it can be observed that the results are promising. From this it can be assumed that the colour bands are correctly defined. If we assume that the colour bands are correct than all is needed is to modify the tolerance property for colour bands in order to produce improved results. If analyzing the same area with the same colour bands but new tolerances and improved results can be seen, than our assumption that the colour bands are correct is true. Area TO39R20W4 was analyzed with a colour map with improved tolerances. The colour map is exhibited in Listing 9. In Table 9a the results of the analysis of TO39R20W4 with the colour maps from Listing 6 and Listing 9 can be seen. The new tolerance values (from Listing 9) produce results that are closer to the census data. The colour map from Listing 9 is an improvement from the colour map from Listing 6 and produces results that are closer to the census data. The same strategy can be used for area TO38R21W4. A colour map with improved tolerance values is exhibited in Listing 10. In Table 9b the results of the analysis of TO38R21W4 with the colour maps from Listing 6 and Listing 10 can be seen. The colour map from Listing 10 is an improvement from the colour map from Listing 6 and produces results that are closer to the census data. Table 9a: A comparison between pixel analysis data using multiple colour maps and statistical data. Parish/Township TO39R20W4 TO39R20W4 TO39R20W4 Census Data Analysis using Bing Analysis using Aerial Image using Bing Aerial colour map from Image using Listing 6 colour map from Listing 9 Note: Analysis using this colour map is closest to the census data Wheat 25.69 km2 24.03 km2 24.77 km2 Canola 23.24 km2 21.05 km2 24.12 km2 Pulses 2.13 km2 1.85 km2 1.85 km2 Crop 72.36 km2 56.19 km2 61.82 km2 Pasture 12.58 km2 14.71 km2 12.02 km2 Agricultural Land 84.94 km2 70.90 km2 73.84 km2 Water NA 1.87 km2 1.84 km2 Total Area 95.44 km2 93.27 km2 93.27 km2 Table 9b: A comparison between pixel analysis data using multiple colour maps and statistical data. Parish/Township TO38R21W4 Census TO38R21W4 TO38R21W4 Data Analysis using Analysis using Bing Aerial Bing Aerial Image using Image using colour map from colour map from Listing 6 Listing 10 Note: Analysis using this colour map is closest to the census data Wheat 21.10 km2 15.26 km2 21.14 km2 Canola 15.34 km2 20.18 km2 16.41 km2 Pulses 0.60 km2 0.47 km2 0.47 km2 Crop 51.03 km2 40.86 km2 43.62 km2 Pasture 31.95 km2 21.35 km2 28.78 km2 Agricultural Land 82.98 km2 62.21 km2 72.40 km2 Water NA 0.43 km2 0.41 km2 Total Area 94.79 km2 93.30 km2 93.30 km2 Listing 9: Modified colour map used for analysis of TO39R20W4. Colours are the same as in Listing 6 however the tolerances have been modified. Listing 10: Modified colour map used for analysis of TO38R21W4. Colours are the same as in Listing 6 however the tolerances have been modified. Figure 37: Maps generated by Land Analysis Plug-in by implementing Algorithm 3. Map generated from TO39R20W4 with colour map Map generated from TO39R20W4 with colour map from Listing 6 from Listing 6 and new colour bands from Listing 11 Figure 37 shows two maps of the area named TO39R20W4. The image on the left side was generated using the colour range exhibited in Listing 6. The image on the right hand side was generated using the colour range exhibited in Listing 6 plus six new colour ranges exhibited in Listing 11. Overall, the image on the right hand has a better definition of fields when compared to the image on the left hand side. The additional six colour ranges (defined in Listing 11) demonstrate an improvement in identifying and accounting for field usage. Listing 11: Six additional colour bands to be added to colour range file exhibited in Listing 6. Usage of statistical data forces us to ask two questions. The first question to ask is the statistical data good? The second question to ask is once the data is good, is the data appropriate for our uses or for comparing it to data generated by pixel analysis? If the data for TO39R20W4 in table 8 is analyzed it can be observed that 84.94 km2 out of a total of 95.44 km2 is used for agricultural purposes. Assume that this is good data, a different conclusion may be observed from Figure 34. In Figure 34 it can be seen that approximately half of the fields are green (they are planted) and the other half are brown (the bare earth may be observed). The conclusion is that there is something wrong with Figure 34. Figure 34 is an image from Bing Maps, a service that was launched on December 5, 2010. This indicated that the image is relatively recent. Hence why the green and brown areas on the image do not match the statistical data from Table 7? The obvious answer may be that the statistical information compiled in Table 7 is incorrect. Another answer may be that farming practices dictate that crops be planted at different times of the year. Another answer was explained in the previous paragraph, why median should be used instead of mean when it comes to comparisons. If we accept that Table 7 is good data and Figure 34 is an accurate image representing TO39R20W4 than it is desired to have statistical data that may be georeferenced to a specific area or hopefully a field. The data in Table 7 representing TO39R20W4 is georeferenced to an area of 95.44 km2. If statistical data would be accompanied by georeferences of 1 km2 than comparisons could be performed to higher resolution images as the one in Figure 34. The land analysis plug-in is ideally suited for analyzing land usage over time. What is crucial is that geospatial data be available for different time intervals. A user can define colour bands suitable for their needs. For example analyzing plant properties, there will be a need to define multiple green colour bands. This system may be employed for watershed scale of spatio-temporal aggregation of various plant properties. Oceanography Oceanography is the study of oceans and seas. One aspect of oceanography is Bathymetry. This is the study of underwater depth of ocean floors. PlaniSphere may be used to display bathymetric maps. GEBCO (General Bathymetric Chart of the Oceans) provides a range of bathymetric data sets that are available for download or consumed over the internet from their public WMS server (see Table 4 for WMS URLs). Figures 38, 39a and 39b show PlaniSphere displaying bathymetric maps. In laymen terms the bottom of the ocean floor can be seen with PlaniSphere. We can take advantage of PlaniSphere’s capabilities to observe these maps in a three dimensional format. The most obvious advantage is that we can visualize the ocean floor, we can get a better understanding of the depth of the ocean floor and we can also see many trenches of various depths. From Figure 38 we can observe that the ocean floor is not uniform. Also our curiosity forces us to ask is why there are such deep trenches to the east of Japan? Any geologist will respond to this by saying that this is where two tectonic plates separate. Figure 38: A bathymetric map from GEBCO showing trenches and fault lines on the east coast of Japan Figure 39a: A bathymetric map from GEBCO showing the ocean floor to the south of the Falkland Islands Figures 39a and 39b display bathymetric maps from the GEBCO public WMS server. Both figures 39a and 39b show the same area, that is the ocean floor to the south of the Falkland Islands. Figure 39b has a graticule superimposed on the map to give us a sense of distance between points of interest. It can be observed that ocean floor in non-uniform. We can see that there are areas of various depths, there are ridges and trenches. Figure 39b: Same bathymetric map as in figure 38a with a graticule labeling meridians and parallels. Map Data Sources PlaniSphere has the ability to use map data from multiple sources. The table below describes some of the geospatial data and sources used in this project. Table 9: Map data used for testing and research Name Web Site Description OpenStreetMap Planet.osm, All OpenStreetMap data is available in its native http://planet.osm.org format represented by an XML file. The XML data is fairly large, currently over 43 gigabytes. GEOFABRIK, OpenStreetMap data is available in native format http://download.geofabrik.d either by continent, country and province or region. e The native XML format along with ESRI shape files are available for download. World OSM WMS url: A map server that supports the WMS protocol for http://www.osm-wms.de OpenStreetMap data. It is hosted by the University of Heidelberg GIScience Research Group. Terrestris general website: An European Union commercial entity located in http://ows.terrestris.de/osm Bonn, Germany. One of the open services that they -haltestellen , provide are OpenStreetMap WMS services. Terrestris WMS url, http://ows.terrestris.de/osm /service,http://ows.terrestris .de/osm-gray/service Blue Marble: http://visibleearth.nasa.gov/ “Blue Marble” images that represent the most land surface, view.php?id=57752 detailed true-color images of the entire Earth. Most shallow water of the images are from a single remote-sensing and shaded device-NASA’ Moderate Resolution Imaging topography Spectroradiometer or MODIS. Images are produced from observations from June through September of 2001. Topographic shading is based on GTOPO 30 elevation dataset from the US Geological Survey. GeoGratis http://www.nrcan.gc.ca/eart GeoGratis is a website where you can find free map h- data of Canada. This map data may be used without sciences/geography/topogra restriction. Multiple formats are supported: WMS, phic-information/free-data- GeoTIFF and ESRI shape files. geogratis/11042 The Atlas of Canada – Toporama (The Atlas of Canada) is part of the Earth Toporama general website, Sciences Sector at Natural Resources Canada. http://atlas.gc.ca/toporama/ Toporama is a service that is compatible with WMS en/index.html. versions 1.1.1 and 1.3. Toporama can be accessed at WMS url: http://wms.ess- no cost and without restrictions according to its ws.nrcan.gc.ca/wms/topora license available at ma_en?VERSION=1.3&reque http://www.geogratis.ca/geogratis/en/license/jsp. st=GetCapabilities&service= Toporama provides map data for topography, built- wms up area, populated places, designated areas, construction, contours, hypsography, hydrography, landforms, power network, railway, road network, water saturated soils, vegetation, limits, structures and feature names. U.S. Geological General website: Earth Explorer is a website that may be used for Survey http://www.usgs.gov, downloading map data from the U.S. Geological Earth Explorer website: Survey. Map data is composed of multiple types of http://earthexplorer.usgs.go data sets (aerial imagery, digital elevation, digital v maps, global land surveys, LiDAR, land cover, LandSat, radar, vegetation monitoring and others). Map-A-Planet general Imagery of the planets and satellites from a variety website: of missions. Map-A-Planet is expected to be http://www.mapaplanet.org decommissioned around June 30, 2015. / USGS Astrogeology Science A replacement for Map-A-Planet. Available image Center general web site: mosaics are available for download for the following http://astrogeology.usgs.gov bodies: Mercury, Venus, Mars, Jupiter (Europa, /tools/map, Ganymede, Io), Saturn (Dione, Enceladus, Iapetus, Planetary Nomenclature web Rhea, Tethys, Tital) and small bodies (Ceres, Vesta). site: http://planetarynames.wr.us gs.gov/GIS_Downloads GEBCO, General General website: GEBCO has a range of bathymetric data sets Bathymetric http://www.gebco.net. (including gridded bathymetric data sets) the GEBCO Chart of the WMS url: Digital Atlas, the GEBCO world map and the GEBCO Oceans http://www.gebco.net/data_ Gazetteer of Undersea Feature Names. The data set and_products/gebco_web_s may be downloaded and used locally or accessed ervices/web_map_service/m remotely using WMS. [61] apserv?version=1.3&service= wms&request=GetCapabiliti es Results New or enhanced maps can be generated by aggregating and fusing geospatial data from existing sources disregard whether the sources are commercial vendors or open-source suppliers. Three examples of graphical aggregation of geospatial data have been demonstrated in the sections: Space & Planetary Exploration, Logistics and Land Analysis. PlaniSphere supports consumption of well-known file types and data sources such as: ESRI shapefiles, GeoTIFF, KML and WMS. Geospatial data is process by its file type or protocol rather than by its content. This ability has unexpected consequences in terms of the maps that may be generated. What is expected is that maps for our planet can be generated if geospatial data exists. What is unexpected is that maps for other planets can be generated if geospatial data exists. In this project geospatial data of a graphical nature has been aggregated and fused. Aggregation was implemented by retrieving geospatial data sets into layers where a layer represents an atomic geospatial data set. Fusion was implemented by combining graphical representations of each layer. Aggregation and fusion was accomplished by reusing existing data structures supplied by NASA World Wind for Java SDK. Algorithm 1 was has been created to achieve aggregation and fusion of geospatial data in interactive user viewing sessions through the manipulating of NASA World Wind’s layer implementation. PlaniSphere is a desktop application that displays a virtual globe. It can operate on multiple operating systems. PlaniSphere can generate 3D and 2D maps from existing geospatial data. It efficiently renders 3D/2D maps using hardware accelerated graphics supported by OpenGL. This will occur only if a video card is used that natively support OpenGL. PlaniSphere has a low learning curve. Its modern GUI may be used by anyone with basic computer skills and knowledge of geography. PlaniSphere is geospatial data independent. It can connect to any server supporting the WMS 1.3 protocol. It can directly render any local geospatial file such as GeoTIFF, ESRI shapefile and KML. Note: GeoTIFF must be less than 4096x4096 pixels otherwise it can be consumed indirectly through a WMS service. A consequence of implementing a data independent virtual globe is that a flexible GIS has been created. PlaniSphere can be used in presenting diverse geospatial information: aerial imagery, road maps, maps of other planets including naturally occurring satellites, bathymetric maps and other types of maps. As a virtual globe, PlaniSphere introduces functionality such as layer management and GeoTIFF export that has been the sole domain of GIS editors such as QGIS and ArcGIS for Desktop. The advantage that PlaniSphere’s layer management features allows user to aggregate, re-aggregate, fuse and re-fuse geospatial data at will during a viewing session. The results are computed almost immediately, on average of 5 to 20 seconds waiting period for a response. The fused imagery resulting from graphical aggregation of geospatial data produced by PlaniSphere retains its geospatial attributes. In turn the fused imagery can be exported and consumed by other GIS’ or further analyzed. This has been demonstrated by the land analysis plug-in. The land analysis plug-in has the capability of calculating area occupied by different vegetation types. The success of any product can be determined by predicting potential usage. At the beginning of the project it was envisioned to aggregate commonly available geospatial data such as OpenStreetMap road maps and LandSat satellite imagery. This created an ability to expose remote and unknown areas by being able to visualize them on 3D/2D maps. More important than predicting potential usage is the unintended usage. An unpredicted use of PlaniSphere was to visualize the bottom of ocean floors by displaying bathymetric maps. This capability allowed us to explore under the ocean and look at the bottom of ocean floors in a 3D format. This is one of the unique features of PlaniSphere as a virtual globe. We can explore land surfaces and also surfaces of ocean floors assuming appropriate geospatial data is aggregated and fused. PlaniSphere has the ability to produce maps using geospatial data of our planet and other planets including naturally orbiting satellites (moons). To create maps of other planets is not an envisioned requirement of this project. It should be recognized that this is a result of aggregating data based on geospatial data types and not content. The same rules that apply to aggregating geospatial data for our planet can also apply for other planets. The plug-in framework allows for new capabilities/functionality to be added to PlaniSphere by users. Plug-ins have been developed to present information from GPS logs, social networking sites (Wikipedia), vehicle tracking and perform land analysis. The land analysis plug-in demonstrates how PlaniSphere could be enhanced by adding capabilities that could analyze landscape based on characteristics such as vegetation and urbanization. The analysis capabilities are not part of PlaniSphere, they are part of the plug-in itself. This demonstrates that PlaniSphere can serve as a base for future development. There is no need to start from scratch. There is no need to duplicate existing functionality. The functionality that the PlaniSphere provides can be used and only new functionality will need to be added. PlaniSphere can present geospatial information that allows us to learn about our environment. Environment has a broad definition. PlaniSphere can be used to learn about area close to us, for example the neighborhoods and cities that we live in. PlaniSphere can also be used to explore areas further away from us, for example the Moon. Future Work and Improvements with regards to PlaniSphere PlaniSphere is a user friendly application that operates on multiple operating systems. New functionality can be added by creating a plug-in. This is a true statement only if the new functionality can be supported by the plug-in infrastructure. If a developer has a chance of facing limitations of the plug-in infrastructure when adding new functionality the following question will need to be addressed: will there be a need to modify the PlaniSphere’s code base? New requirement for functionality support gives rise to discussions with regards to design. This has been entertained by James Miller when he implemented Lidar Data Visual Analysis and Editing tool (LASVisEdit – http://people.eecs.ku.edu/~miller/worldwindprojects/lidar/ ). James Miller LiDAR tool was built on top of NASA World Wind for Java. However, there was a need to modify World Wind for Java directly in order to support LASVisEdit [62]. A general recommendation that can be reached from this is that new functionality for PlaniSphere should be added through the plug-in infrastructure if it is possible. If it not possible that an update or improve the plug-in infrastructure should be considered. The last option to consider is to update the PlaniSphere’s and/or NASA World Wind’s code base. A consequence of modifying the PlaniSphere’s codebase directly is that unwanted consequences and/or side-effects may be introduced. PlaniSphere would benefit from the contribution of plug-ins that provide new functionality. As the architect of the tools created in this project, it can be said that there is envisioned usage. However some plug-ins may contain functionality that has not been envisioned by the infrastructure. This would result in new discussion as to what are the boundaries of the infrastructure. Did we understand or misunderstand the boundaries and its capabilities? Were the capabilities present and did not recognize them? Are there new applications for PlaniSphere? Such contributions would produce a better tool or tools. PlaniSphere has the ability to use different types of geospatial data sets. A new addition would be to support LiDAR (.las) files. The simplest way to achieve this would be to combine James Miller’s LASVisEdit codebase with PlaniSphere. This is possible since both PlaniSphere and LASVisEdit are built on top of NASA World Wind for Java. Another argument for integrating LASVisEdit into PlaniSphere is that it would allow for analysis in a 3D space. The LandAnalysis plug-in demonstrated analysis in a 2D space. LiDAR data provides geoinformation in a 3D space. Using this information would allow to analyze areas of interests by volume (3D spaces) instead of area (2D spaces). [63] PlaniSphere is a user friendly application. It may be used by anyone that understands basic geography and possesses a notebook/desktop computer. Currently the selection of geospatial data sets (layers available in PlaniSphere) is performed by the user. In other worlds there is interaction between the user and Planisphere’s GUI. It is the user’s responsibility to be aware of layers used and the supply of geospatial information. A useful feature would be to have the layers selected automatically based on layer metadata describing purpose for the geospatial data. For example if the purpose is ecology than layers such as topography, land coverage and hydrology would be selected while layers such as the road network would not be selected. Such a feature would require for all of the layers to have associated metadata. [64] User interaction with the 3D virtual globe provided by PlaniSphere is performed with the mouse. The mouse is an ideal instrument for navigating in 2D environments. Navigation in 3D environment using a mouse can become a frustrating experience since key combinations may not be supported by the environment (operating system, computing device, etc…) hosting PlaniSphere. This is especially true with tablets. A solution to this issue is to use 3D controllers such as the Leap Motion [65]. Such 3D controllers support multiple degrees of freedom and would enable any user to easily navigate the 3D virtual globe provided by PlaniSphere. Adding support for 3D controllers will dramatically enhance the user experience. Conclusions Aggregation of geospatial data is not a trivial task. In this project geospatial data of a graphical nature has been aggregated and fused. PlaniSphere has demonstrated aggregation and fusion of geospatial data from files (ESRI shapefiles, GeoTIFFs, and KML) and services such as WMS. With PlaniSphere geospatial data may be aggregated from multiple sources (commercial vendors, private sources such as individuals and NGO such as OpenStreetMap). PlaniSphere is an implementation of a 3D GIS that excels in the ability to aggregate and fuse geospatial information of various format types and different sources or providers. PlaniSphere has three strengths: aggregation of geospatial data, fusion of geospatial data, and ability to export fused geospatial data. This has been demonstrated in the Space & Planetary Expiration, Logistics and Land Analysis sections of this document. First, aggregation of geospatial data is achieved by consuming geospatial information of various format types (WMS, GeoTIFF, ESRI shapefiles and KML). The location and provider of geospatial information is irrelevant. That is the geospatial data can be accessed from the Internet using WMS and/or locally available on storage media by consuming files (GeoTIFF, ESRI shapefiles and KML). Second, fusion of geospatial data is achieved by merging multiple layers into a single layer. The end result is that re resulting single layer will contain all of the geospatial attributes of all layers used in the fusion. Third, exporting fused geospatial data, is achieved by creating new files. Two possible formats are supported: GeoTIFF and PNG. GeoTIFFs have geospatial information associated within themselves. This means that they may be further consumed for future uses by PlaniSphere and/or map servers (GeoServer, MapServer). PNGs have no geospatial information associated within themselves. This will limit their ability to be consumed for any analysis. PlaniSphere will allow any third party to add new capabilities through its plug-in framework. In its current implementation the plug-in framework is at an early stage in its evolution. Nevertheless the WikipediaPlugin has demonstrated the ability to utilize geospatial data of a non-standard format anda non-traditional provider. Wikipedia is a provider of educational content and not of geospatial content. The WikipediaPlugin consumed Wikipedia’s web services in order to access geospatial content and present it in PlaniSphere. PlaniSphere introduces functionality such as interactive layer management and GeoTIFF export that has been the sole domain of GIS editors. Interactive layer management allows the aggregation of geospatial data on demand during a user viewing session. It should be noticed that at this moment the world’s commonly accepted virtual globe, Google Earth, does not possess the interactive layer management and GeoTIFF export features. This makes PlaniSphere stand in a class of its own not only as a virtual globe but also as a GIS tool. PlaniSphere has been implemented as a desktop application that can run on any operating system that supports Java. This allows PlaniSphere to be used by a very large and diverse audience with very little knowledge of geography. There will be intended usage and also unintended and/or unforeseen usage. All of this will facilitate feature discussions of new capabilities and/or restrictions to be incorporated into PlaniSphere. Acknowledgements The author, Mihal Miu, would like to thank James Miller (Department of Electrical Engineering and Computer Science, The University of Kansas) for providing access to the source code of LASVisEdit (Lidar Data Visual Analysis and Editing). Terminology A communication protocol is a system of rules that allow that two or more entities of a communication system to communicate between them to transmit information via any kind of variation of a physical quantity. Rules or standards that define syntax, semantics and synchronization of communication and error recovery methods exist and are obeyed by all users of the system. Protocols may be implemented by hardware, software, or a combination of both. [66] A geotag is geospatial metadata (latitude, longitude, altitude) that can be associated with media.Geotagging is the process of adding geospatial metadata (latitude, longitude, altitude) to any media. Media may be represented by photographs, video, maps (including aerial images, satellite photographs), and other document forms.[67] To georeference is to associate points of interests with locations in physical space (usually latitude, longitude and altitude). [68] A great circle of a sphere is the intersection of the sphere and a plane which passes through the center point of the sphere. Any diameter of any great circle coincides with a diameter of the sphere, and therefore all great circles have the same circumference as each other, and have the same center as the sphere. [69] Latitude is a geographic coordinate that specifies the north-south position of a point on the Earth’s surface. Latitude is an angle which ranges from 0° at the Equator to 90° (North or South) at the poles). [70] Layers are objects on the map that consist of one or more separate items, but are manipulated as a single unit. Layers generally reflect collections of objects that you add on top of the map to designate a common association [71] Longitude is a geographic coordinate that specifies the east-west position of a point on the Earth’s surface. The longitude is to be measured as the angles east or west from the Prime Meridian, ranging from 0° at the Prime Meridian to +180° eastward and -180° westward. [72] A map projection is a systematic transformation of the latitudes and longitudes of locations on the surface of a sphere or an ellipsoid into locations on a plane. Map projections are necessary of creating maps from globes. [73] A meridian is a line of longitude. It is the half of an imaginary great circle on the Earth’s surface terminated by the North Pole and the South Pole, connecting points of equal longitude. [74] A prime meridian is a meridian (a line of longitude) in a geographical coordinate system at which longitude is defined to be 0°. A prime meridian and its opposite in a 360°-system, the 180th meridian (at 180° longitude) form a great circle. A prime meridian is arbitrary and various conventions have been used to determine its placement. Currently the meridian through Greenwich (inside Greenwich Park), England is the Prime Meridian. [75] The scale of a map is the ratio of a distance on the map to the corresponding distance on the ground. [76] A Web Map Service (WMS) is a standard protocol for serving georeferenced map images over the Internet that are generated by a map server using data from a GIS database. [77] References 1. Webber, A. Heinimann, A. Messerli, P. Use of NASA World Wind Java SDK for Three-Dimensional Accessibility Visualization of Remote Areas in Lao P.D.R., 6th ICA Mountain Cartography Workshop Mountain Mapping and Visualisation 2. Hu, Y. Wu, J. Zhong, H. Lv, Z. Yu, B. An approach for Integrating Geospatial processing Services into Three-Dimensional GIS, WISM 2010, LNCS 6318, Pg 154-161 3. Miller, M. Odobasic, D. Medak, D. An Efficient Web-GIS Solution based on Open Source Technologies: A Case-Study of Urban Planning and Management of the City of Zagreb, Croatia, FIG Congress 2010, Facing the Challenges – Building the Capacity, April 2010, http://www.fig.net/pub/fig2010/papers/ts05b%5Cts05b_miler_odobasic_et_al_4291.pdf 4. Pourabdollah, A. OSM-GB: Using Open Source Geospatial Tools to Create OSM Web Services for Great Britain, FOSS4G, Nottingham 2013, http://www.academia.edu/4591884/OSM- GB_Using_Open_Source_Geospatial_Tools_to_Create_OSM_Web_Services_for_Great_Britain 5. Pan, W. Zheng, F. Qiao, B. Xu, H. Liu, D. Solutions for GeoTIFF display base on NASA World Wind, Journal of Computer Applications, Vol. 29, No. 6, June 2009 6. Hu, Y. Wu, J. Zhong, H. Lv, Z. Yu, B. An approach for Integrating Geospatial processing Services into Three-Dimensional GIS, WISM 2010, LNCS 6318, Pg 154-161 7. Hpokinson, C. Wulder, M. A. Coops, N. C. Milne, T. Fox, A. Bater, C. W. Airborne lidar sampling of the Canadian boreal forest, Planning, execution & initial processing, SilviLaser 2011, Oct 16-20, Hobart, Tasmania 8. Ganaraska Regional Conservation Authority, Supporting Sustainable Water Management in Ontario Through Innovation, Ganaraska Conservation, March 2014 9. Unknown 10. Miller, J. R. Turner, M. G. Smithwich E. A. H. Dent, C. L. Stanley, E. H. Spatial Extrapolation: The Science of Predicting Ecological Patterns and Processes, BioScience, Vol. 54, No. 4 (April 2004), pp. 310-320, Published by University of California Press on behalf of the American Institute of Biological Science, http://limnology.wisc.edu/personnel/ehstanley/files/miller_et_al_bioscience_2004.pdf 11. Hudak, A. T. Evans, J. S. Smith, A. M. S. LiDAR Utility for Natural Resource Managers, Remote Sensing, 2009, ISSN 2072-4292, http://www.mdpi.com/2072-4922/1/4/934 12. Boschetti, L. Roy, D.P. Justice, C.O. Using NASA’s World Wind virtual globe for interactive internet visualization of the global MODIS burned area product, International Journal of Remote Sensing, Vol. 29, No. 11, June 10, 2008, pages 3067-3072 13. Sayar, A. Fine-grained federation of geographic information services through metadata aggregation, Academic Journals, Vol. 8(46), pp. 2242-2256, December 2013 http://www.academicjournals.org/article/article1386930914_Sayar.pdf 14. Hu, Y. Lv, Z. Wu, J. Janowicz, K. Zhao, X. Yu, B. A Multi-stage Collaborative 3D GIS to Support Public Participation, International Journal of Digital Earth (Impact Factor: 3.29), December 2013, http://www.researchgate.net/publication/259105823_A_Multi- Stage_Collaborative_3D_GIS_to_Support_Public_Participation 15. Web Map Service (WMS), Open Geospatial Consortium, http://www.opengeospatial.org/standards/wms 16. World Wind Java SDK, National Aeronautics and Space Administration, http://worldwind.arc.nasa.gov/java 17. Google Earth, Google, http://earth.google.com 18. ArcGIS Explorer, ESRI, http://www.esri.com/software/arcgis/explorer 19. GeoTools, The Open Source Java GIS Toolkit, http://geotools.org/ 20. QGIS – A Free and Open Source Geographic Information System, http://www.qgis.org/ 21. Pegg, D. Design Issues with 3D Maps and the Need for 3D Cartographic Design Principles, Eotvos University, department of Cartography and Geoinformatics, http://lazarus.elte.hu/cet/academic/pegg.pdf 22. Grouchnikov, K. Flamingo Swing Component Suite, https://github.com/kirillcool/flamingo 23. Flamingo/Peacock Ribbon GUI for Java Swing, https://github.com/Insubstantial/peacock, Insubstantial 24. NASA World Wind API Documentation, http://builds.worldwind.arc.nasa.gov/worldwind- releases/2.0/docs/api/index.html 25. NASA World Wind API Documentation for package gov.nasa.worldwind.layers,http://builds.worldwind.arc.nasa.gov/worldwind- releases/2.0/docs/api/gov/nasa/worldwind/layers/package-summary.html 26. NASA World Wind API Documentation for package gov.nasa.worldwindx.examples.kml, http://builds.worldwind.arc.nasa.gov/worldwind- releases/2.0/docs/api/gov/nasa/worldwindx/examples/kml/package-summary.html 27. ESRI Shapefile Technical Description, ESRI, 1998, http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf 28. Dietz, C. Implementing Geospatial Web Services: A Resource Webliography, Science and Technology Resources on the Internet, Issues in Science and Technology Librarianship, Springer 2010, http://www.istl.org/10-spring/internet2.html 29. The Blue Marble, Wikipedia, https://en.wikipedia.org/wiki/The_Blue_Marble 30. Stockli, R. Blue Marble Next Generation, October 2005, http://Earthobservatory.nasa.gov/Features/BlueMarble/, NASA 31. Irons, J.R. Taylor, M.P. Rocchio, L. Landsat Science, http://landsat.gsfc.nasa.gov/, NASA 32. Bing Imagery, http://www.microsoft.com/maps, Microsoft Corporation 33. Bing Maps Platform, Wikipedia, https://en.wikipedia.org/wiki/Bing_Maps_Platform, Microsoft Corporation 34. OpenStreetMap Wiki, Open Source Map Data and a Public GIS, http://wiki.openstreetmap.org 35. Keyhole Markup Language (KML), Google, https://developers.google.com/kml/ 36. Ritter, N. GeoTIFF Format Specification, GeoTIFF Revision 1.0, http://www.remotesensing.org/geotiff/spec/geotiffhome.html 37. Portable Network Graphics (PNG) Specification (Second Edition), http://www.w3.org/TR/PNG/, W3C 38. NASA World Wind Documentation – WorldWindowGLCanvas Class Documentation,http://builds.worldwind.arc.nasa.gov/worldwind- releases/2.0/docs/api/gov/nasa/worldwind/awt/WorldWindowGLCanvas.html 39. Fred Brooks, The Mythical man-Month: Essays on Software Engineering, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/The_Mythical_Man-Month 40. Mayer, J. Melzer, I. Schweiggert, F. Lightweight Plug-in-Based Application Development, Department of Applied Information Processing, University of Ulm, 2002, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.5602 41. XPCOM, Mozilla Developer Network,https://developer.mozilla.org/en- US/docs/Mozilla/Tech/XPCOM 42. COM, Microsoft Developer Network, https://www.microsoft.com/com/default.mspx 43. Extension:GeoData, MediaWiki, A WIKIMEDIA Project, https://www.mediawiki.org/wiki/Extension:GeoData 44. Wikipedia: Wikipedia is a social networking site, Wikipedia The Free Encyclopedia, https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_is_a_social_networking_site 45. Crampton, J. The Ethics of GIS, Cartography and Geographic Information Systems, Vol 22, No 1, 1995, pp 84-89, http://dusk.geo.orst.edu/ethics/papers/Crampton_CAGIS.pdf 46. Wagner, R.V. Speyerer, J. Robinson, M.S. New Mosaicked Data products from the LROC Team, School of Earth and Space Exploration, Arizona State university, 46th Lunar and Planetary Science conference 2015, http://www.hou.usra.edu/meetings/lpsc2015/pdf/1473.pdf 47. Archinal, B.A. Kirk, R.L. Gaddis, L.R. Titus, T.N. Herkenhoff, K.E. Keszthelyi, L.P. Lawrence S.J. Beyer, R. Nefian, A. The Need For Planning The Future of Planetary Cartography, 45th Lunar and Planetary Science Conference, 2014 48. Jet Propulsion Laboratory, California Institute of Technology, http://onmoon.jpl.nasa.gov/ 49. Lunar Reconnaissance Orbiter Camera, Arizona State University, School of Earth & Space Exploration,http://lroc.sese.asu.edu/ 50. New Horizons, https://www.nasa.gov/featue/new-pluto-images-from-nasa-s-new-horizons-it-s- complicated 51. Delegido, J. Verrelst, J. Rivera, J.P. Ruiz-Verdu, A. Moreno, J. Brown and green LAI mapping through spectral indices, International Journal of Applied Earth Observation and Geoinformation 35, 2015 52. Jacobs-Crisioni, C. Rietveld, P. Koomen, E. The Impact of Spatial Aggregation on Urban Development Analysis, Applied Geography 47, 2014 53. RGB Colour Model, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/RGB_color_model 54. Colour Difference, Wikipedia, The Free Encyclopedia,https://en.wikipedia.org/wiki/Color_difference 55. Euclidean Distance Formula, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Euclidean_distance 56. Colour Depth,Wikipedia, The Free Encyclopedia, https://wn.wikipedia.org/wiki/Color_depth 57. Coutsoukis, P. Primary/Main/Basic Colours,http://www.theodora.com/gif4/html_colors.gif, 2013 58. Coutsoukis, P. Secondary/Mixed/Pastel Colours, http://www.theodora.com/gif4/html_colors_pastels.gif, 2013 59. Xie, Y. Sha, Z. Yu, M. Remote sensing imagery in vegetation mapping: a review, Journal of Plant Ecology, Vol. 1, No. 1, Pg. 9-23, http://jpe.oxfordjournals.org/content/1/1/9.full 60. Kollar, S. Vekerdy, Z. Markus, B. Aerial Image Classification for the Mapping of Riparian Vegetation Habitats, Acta Silv. Ling. Hung., Vol 9, 2013, pg 119-133 61. General Bathymetric Chart of the Oceans, http://www.gebco.net/, GEBCO 62. Miller, J.R. LASVisEdit – LiDAR Data Visual Analysis and Editing, http://people.eecs.ku.edu/~miller/worldwindprojects/lidar/ 63. Hu, Q. Wang, K. Liu, J. Yu, F. A vector map extraction approach in a direct 3D visualization environment with LiDAR data, International Symposium on Lidar and Radar Mapping, 2011 64. Risojevic, V. Momic, S. Babic, Z. Gabor Descriptors for Aerial Image Classification, Faculty of Electrical Engineering, University of Banja Luka, Bosnia and Herzegovina, http://dsp.etfbl.net/aerial/icannga11.pdf 65. Leap Motion, http://www.leapmotion.com 66. Communications protocol, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Communications_protocol 67. Geotagging, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Geotagging 68. Georeference, Wikipedia, The Free Encyclopedia, https://en.wikipeida.org/wiki/Georeference 69. Great Circle, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Great_circle 70. Latitude, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Latitude 71. Geographc Information System, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Geographic_information_system 72. Longitude, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Longitude 73. Map Projection, Wikipeida, The Free Encyclopedia, https://en.wikipedia.org/wiki/Map_projection 74. Meridian (geography), Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Meridian_%28geography%29 75. Prime meridian, Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Prime_meridian 76. Scale (map), Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Scale_%28map%29 77. Web Map Service, Wikipeida, The Free Encyclopedia, https://en.wikipedia.org/wiki/Web_Map_Service