GIS for real life Applications and Intergating with GIS Devices

GIS Future Technologies

Introduction

Global positioning system (GPS)  technology has complimented geographic information systems (GISs) for a number of years and is now well understood and accepted by the GIS community. The primary focus of GPS within the GIS arena has traditionally been based around GPS systems that collect, store and transfer data from a field system to an office-based GIS. With current developments in field computers (especially related to lightweight and low cost devices that operate Microsoft's Windows CE operating system) there is a strong desire to take GIS directly into the field. This increased interest in field-GIS has a corresponding interest in the application of GPS within GIS.

GIS/GPS Integration Techniques

There are three basic ways that GPS technology can interact with or be integrated into GIS. The level of integration associated with these vary from a 'disparate' connection, whereby data is transferred between a GPS system and a GIS system, through to a very 'tight' level of integration, whereby GPS technology is totally embedded directly within GIS application software. GIS/GPS integration can be categorized into the following three categories:

• Data-focused integration
• Position-focused integration
• Technology-focused integration

The appropriateness of each method is dependent upon the requirements that a user has for field-based operations, the level of dependence the user has on GPS and, to a large extent, the availability of a complete system to meet the specific needs that the user has for a system.

Data-focused Integration

To date, the most common method of integrating GPS into GIS has been through a data-focused method of integration. (Although the term 'interaction' is probably a more appropriate term than 'integration'.) Data-focused integration, as depicted by Figure 1., utilizes a complete, self-contained GPS system that has data collection and storage capability for use in the field. Data that is collected in the field is later transferred to an office PC for processing and eventual export to an enterprise GIS that resides within an organization. Historically, data-focused systems have concentrated on a one-way data flow whereby data is transferred from the GPS product to the GIS database. GPS field products are now emerging, however, that allow data from the GIS to be uploaded as well, so existing data can be taken easily back to the field for data update and maintenance purposes.

Figure 1. Conceptual view of data-focused integration
Self-contained GPS systems used in this manner are complete in themselves and generally developed by large GPS manufacturing organizations. The system consists of a GPS receiver, GPS antenna and a controlling device with data storage capability. Units can be either modular (as stylized in Figure 1.), fully integrated into one housing or a combination of the two. Historically, GPS systems have been rugged, to cater for harsh outdoor environments, with self-contained software that is optimized for limited storage, keyboards and screen real estate. These GPS systems are usually designed to meet the needs of most data collection or data maintenance professionals and are purchased as an off-the-shelf, turnkey system.
The primary advantage of utilizing a data-focused approach to GIS/GPS integration is that an end-user can operate the GPS system "out of the box" with little or no need for customization. For many GPS users, an off-the-shelf system will cater for most, if not all, of their needs for data collection and maintenance. A perceived downside is that there's often more functionality in the system than required, but the cost associated with a complete system is generally less expensive than costs associated with building a customized solution that is restricted to a specific application.
An example of a data-focused solution is Trimble Navigation's GeoExplorer® 3, for data collection and update, with GPS Pathfinder® Office, for data transfer and processing, and Esri's ArcInfo or ArcView products, for spatial analysis, query and archive.

Position-focused Integration

Position-focused integration is, historically, the most common approach to GPS integration (as opposed to interaction). As depicted in Figures 2a. and 2b., position-focused integration generally consists of a complete GPS system supplying a separate field application with GPS derived data that is related solely to the computation of positions. Data from the GPS is commonly transmitted to the field device using the NMEA-0183 protocol, although this is not the only protocol used. NMEA-0183 is a strictly defined ASCII-based format that consists of several messages, which contain data that's packaged and sent to an external device. Data from the field device may be transferred to and from the enterprise GIS. This is not imperative however, as the field application may be a self contained GIS in its own right.

Figure 2a. Conceptual representation of position-focused integration using two field devices
Figure 2a. presents a good perspective on the components associated with position-focused integration. Position-focused integration essentially uses a GPS system, which could be the same as that used in data-focused integration, to provide data directly into an application running on the field device. In effect, the GPS system is treated as an external sensor by the application on the field device. The field device will usually provide data storage.

Figure 2b. Conceptual representation of position-focused integration using a single field device
With the advances in handheld field devices, it is becoming more common to find both the GPS control application and the field device application operating on the same device, as depicted in Figure 2b. It’s important to note though that the applications will be operated totally separate to one another. In general, one application is used to configure the GPS receiver and control the provision of position related data, while another application is used to store and use the data that is being sent to it. It's important to note that the data storage application has little or no control over the operation of the GPS equipment.
While systems that make use of position-focused integration can become cumbersome, from an equipment and ease of use perspective, and expensive they are very useful when GPS positioning is required on an infrequent basis. An organization, for example, may already have a complete GPS system for data collection purposes but may have another application that can make use of GPS from time to time. The ability to utilize the GPS system when GPS is useful makes good economic sense. The downside of losing a tight integration with the GPS receiver or carrying a cumbersome system may be an acceptable alternative to the expense required to fully customize a system.
An example of position-focused integration is seen through the use of Trimble Navigation's GPS Pathfinder Controller software to setup a GPS Pathfinder XRS receiver for use with Esri's ArcPad field-GIS product. While ArcPad is actually able to power on and connect to a GPS Pathfinder XRS receiver directly, it has not been designed to configure the GPS receiver directly. The Pathfinder Controller software acts as the controlling device for the GPS receiver, while ArcPad provides an interface that is designed well for image display and spatial query.

Technology-focused Integration

 Technology-focused integration is a refinement of position-focused integration. As Figure 3 illustrates, control of the GPS hardware is achieved directly from a third party application, thus eliminating the need for a separate application or device to control the GPS receiver. Communication between the application and the GPS receiver has a two-way communication flow - as compared to the one-way flow associated with the secondary application and the GPS system in the position-focused approach. As with position-focused integration, it is optional for data to be transferred between the field device and the enterprise GIS. The transfer of data is dependant on the capabilities of the application on the field device.

Figure 3. Conceptual representation of technology-focused integration
This ability for a customized application to communicate directly with the GPS receiver enables GPS and GIS technologies to truly be integrated together in a seamless manner. In fact, the GPS technology is able to be totally embedded within a GIS application system to an extent that an end-user of the system will think that technologies from two different organizations actually came from one single source. Thus making a technology-focused application very similar to a data-focused system. The advantage though is that the full power of the GIS can also be taken directly into the field. The user-interface and functionality of the application can be totally designed around the needs of the user - resulting in powerful spatial analysis systems that are familiar and easy to use for the person who is going to use it most.
The reason that GPS receivers can be so tightly integrated is not new, but the current state of software technology has made a technology-focused integration approach more readily accessible to more people. Technology-focused integration requires a developer to be able to create programs using the raw (often proprietary) language (or protocol) of the GPS receiver. Proprietary protocols are generally in a binary format and can be very complex and complicated - at least for those who are not expert programmers. This has often meant that the development of customized GPS-based applications has been a costly exercise.
Now, however, through the use of component technologies (such as ActiveX components), it's significantly easier to integrate GIS and GPS components within the same programming code - or application. Software development products are emerging from within the GPS industry that takes the complex, but powerful, proprietary protocol of the GPS receiver and makes it simple to use and understand by 'wrapping' an ActiveX application programming interface (API) around the proprietary protocol. ActiveX components follow clearly defined rules for interacting with applications. Such standardized interaction allows the same control to be used in several different contexts. The applications are typically developed within Microsoft's Visual Basic, Visual C++ or VBA development environments, but ActiveX controls also operate in additional development environments.
As with the GPS industry, components are also available from GIS vendors, such as Esri's MapObjects ActiveX product. Because GPS and GIS ActiveX components adhere to a standard and commonly used API structure, the power that was once restricted to the large companies that develop GIS and GPS products is now readily available to all, enabling unique and powerful, user-specific solutions to be easily created.
The most significant advantage of a technology-focused integration approach is the flexibility it offers for both end-users and application developers alike. Although ActiveX has made it easy to develop applications using proprietary protocols, the programmer time required to develop customized applications can still make it prohibitively expensive. For that reason, technology-focused integration is best suited to very simple applications or applications that are complex in nature and cannot be catered for by an off-the-shelf system. For the majority of GIS professionals who make use of GPS, therefore, a data-focused integration approach often provides the most economical solution.
ActiveX components also exist for position-focused integration techniques, so it’s important to look closely at the component to ensure it provides the level of functionality that you expect. When looking for an appropriate GPS-based ActiveX component it's important to consider:

• The level of control offered over the GPS receiver's settings and status messages;
• The level of flexibility associated with the computation of positions and their associated levels of accuracy; and
• The provision of adequate information that provides confidence in the quality and use of the positions that are being supplied.

An example of technology-focused integration is the use of Trimble Navigation's Pathfinder Tools™ software development kit to integrate a GPS Pathfinder XRS receiver within a customized application that uses Esri's MapObjects product to visually display a map and carry out spatial analysis directly on a pen-based field computer.

Conclusion

There are numerous ways that GIS and GPS technology can (and already do) work well together. From complete off-the-shelf data collection and data maintenance systems, to help with the management of spatial features and attribute data, through to very flexible software development kits, to assist in the creation of unique and sophisticated field applications. The use of GPS within a GIS environment has already been well accepted and proven - especially for data collection and now data maintenance. The manner in which GPS is used with GIS is now wide and varied allowing users to determine the way GIS and GPS are used together to best meet their needs

Where is that ATM?

To read the source Content

Where is that ATM?


Mike Sanderson suggests how Big Data can help us make better decisions - provided we can crack the thorny issue of ontology


About thirty years ago we had this marketing strapline for a multi-dimensional cube analyser. It went along the lines of being able to carry out work efficiently (doing the job right) and effectively (doing the right job). Twenty years ago Hammer & Champy1 set the IT consultancy world alight with the concept of business process re-engineering (BPR). This was about doing the job right and re-organising processes accordingly. 


The IT industry now has the tools to identify what the right job is, to go alongside our ability to engineer business processes. It’s known as Big Data in the industry. My proposition is simple, we now have tools to analyse structured and unstructured data to make better decisions, like where to find an ATM at the local supermarket.


Like BPR, its origins came from the consultancy world. In the Big Data phenomenon, McKinsey2 grabbed a large share of the zeitgeist at day one. Like most in our industry I suppose, I groaned inwardly as the cynic in me read the column inches on Big Data. After all, as Henderson said in September’s issue3, we have always had big data in spatial. The trouble is that McKinsey’s view of big data is built around personal location data – that coming from tablets and mobiles. What must we do so that the location industry plays a part?


About co-ordinates


Using location data is dangerous. Examine the two images at the top of the next page concerning the possible range of North Korean missiles. That on the left might equate to a big data answer without geodesy playing a part. That on the right ... well make up your own mind.


About scale


In thinking about this subject I came across the Data Science@Berkeley Blog on What is Big Data? The first contributor (John Akred, CTO of Silicon Valley Data Science) included these words in his contribution:


“Advances in sensing technologies, the digitization of commerce and communications, and the advent and growth in social media are a few of the trends which have created the opportunity to use large scale, fine grained data…”.


So I have no need to be worried about scale. It seems they get it after all, or perhaps not? As with the geodesy example, the unwary will not necessarily get the right answer. We can smile knowingly about these issues or we can help the big data users out. But before we get to how we might do this, there is one area with which the spatial industry and the big data industry both struggle.


About semantics


We can’t get to the right answer if we can’t frame a question that big data and the spatial industry jointly understand. This is not about a point-in-polygon search it’s about the ontology word that frightens everyone off. What do I mean when I say St. Pancras station? It could be the façade, the concourse, the tracks, the platforms, the hotel or all of these. But unless we know we will arrive at either the wrong answer or the wrong location. Big data will need to solve this issue if it is going to succeed.


What next?


I can think of three options where the spatial industry can play a part. There are probably others, but I do not have space for them here. Some of these ideas were also discussed last month by Millard (Frankenstein’s Data, GeoConnexion, Sep 2014) I am just trying to formalise them here. They are:


• Intermediate

• Add co-ordinates to enterprise data

• Provide a platform to assure data quality.


Intermediate: This involves taking the complexity of scale and geodesy out of spatial data for the non-spatial user. The user interface will have to solve the ontology issue described above and as Millard describes the customer will want to know what the costs and benefits are of using open data only, a mixture of open and licensed data or licensed data only. 


Add co-ordinates to enterprise data: The biggest issue is that most enterprise data does not have geo co-ordinates attached. So all those work orders in asset intensive industries raised through Enterprise Management work management applications; the financial markets buy and sell orders are two examples where geo co-ordinates are not entered typically. In these examples we may be trying to optimise work planning or detect fraud in the latter example. The 1990s solution to these challenges involved heavy lifting of data and trying to integrate GIS and work management applications. That hasn’t worked effectively.


Our industry has been good at geocoding and reverse geocoding but tended to internalise the results of these operations within the GIS. It’s time to do it the other way around and if a map is the required output, then interface.


Provide a platform to assure data quality: I would contend that it is not enough to let the market decide what represents a good quality data set. As I have described above, and others have also, spectacular failures can occur when spatial data are misused. 1Spatial has provided a cloud-based platform for nearly five years for users to test data for geometric and topological consistency as part of a triple A data approach. 


The genie is out of the bottle in terms of personal location data being available to big data decision-makers (and it has been to governmental decision-makers for even longer), so I can do no better than quote Dr. Brian T. Gray, Assistant Deputy Minister, Earth Sciences Sector, Natural Resources Canada:


“Canadian government departments are working together to launch the Federal Geospatial Platform to enable online discovery, access, integration and visualization of multiple layers of accurate, authoritative and accessible geospatial information. That way users can search once and find everything.” 


Conclusion


So will the combination of BPR and Big Data make organisations more effective and more efficient? The answer to that is yes if the GIS industry helps the enterprise handle location more easily. And we will both benefit from working together to crack the ontology problem.

Working with Group layers through Python

 This tool will be helpful in accessing the Trace Managaement Results

TOOL USED:  arcpy.mapping

Python script will be deployed in the ARC Toolbox to create the Conversion Tool

WORKING OF THE TOOL:

This tool will iterate through each layer in the group layer and perform operation on each layer for every iterations

PROCEDURE:

·         Create a New Script tool in your toolbox of your ArcCatalog

·         Set any empty python code file as source file in which you are going to write your script

·         Set Output layer as input parameter and group layers as the data Type

·         Copy the following code into your python code file

import arcpy

from arcpy import env

arcpy.env.overwriteOutput=1

outputgrouplayer=arcpy.GetParameter(0)

#Assign the output group layer to a variable, to be used later

lyrs =outputgrouplayer

print lyrs

#Create a Mapping Layer out of the Group Layer

groupLayer = arcpy.mapping.Layer(lyrs)

#Get a list of all the mappping layers, the first return will be the Group Layer itself

newLyrs = arcpy.mapping.ListLayers(groupLayer)

#Iterate through all of the Layers (mapping layers)

for lyr in newLyrs:

    #Because the first return is the group layer itself, we check for this, and move on

    if not lyr.isGroupLayer:

        print "Layer name is: {0}. Count is: {1}.".format(lyr.name, str(arcpy.GetCount_management(lyr)))

• This will print the layer name and count of feature for every layer in the Group layer inputted
•  Run the script tool and target your group layer as the input in the parameter box. Click on Ok
• Now it is Party time. Happy Coding

ESRI Addin Button to Zoom to Selected Layer in TOC

Software Required:

1. Microsoft Visual Studio 2010 +
2. ArcMap 10.2 or more
3. ArcObjects SDK for .Net Installed

Procedure:

• Open Visual Studio 2010
• Create a New Project > Visual C#> ArcGIS>Desktop Addins >ArcMap Add In
• ArcMap Addin Wizard will appear on the Screen.Give a desired name for your Addin and click Next
• In the Addin Types Enable Button checkbox and provide description for it.This will appear as a button tooltip in your ArcMap application.Click finish to end the wizard.
• Now go the Solution Explorer(View>Soln Explorer) and open the Addinname.cs file if it doesn't appear in your screen.
• Replace the content of the file with the following data on the onclick() method of the button.cs file.
• Add the References(Right click references in Solution Explorer and select Add References) based on your classes usage

C#

protected override void OnClick()

        {

IMxDocument mdoc = ArcMap.Application.Document as IMxDocument;

//the following two lines of code are the same

IActiveView activeView = mdoc.ActiveView;

//IActiveView activeView = mdoc.FocusMap as IActiveView;

//get the selected layer in the Table of Contents

ILayer lr = mdoc.SelectedLayer;

//check if there is a selected layer or not

if (lr != null)

{

activeView.Extent = lr.AreaOfInterest;

//invoking Refresh method

//results in redrawing the whole view

activeView.Refresh();

}

}

• Save your Current project .Don't run your Code.
• Go to Properties>Addinname Properties>Debug option.Set your ArcMap as the External program for debugging the code
• Run the Code.
• ArcMap Application will now open.Go to Customize>Customize mode>Command.Right now you will see your Addin name in the category list click on it, respective button will get displayed on the rightcommands window.
• Drag the Button and put it in the Menu bar.
• You get the ESRI Addin file bin>Debug folder of your project location
• Now its party time :) Share your work with other through the Addin file