Cognos Analytics Release 8 adds support for Latitude/Longitude based maps in reports allowing geocoded data to be displayed on the maps shown in reports as seen below:
In our example, businesses in Hawaii are shown as points located by latitude and longitude with revenue driving the size, and Profit driving the color of the points.
As with the Regions and Points layers, the Latitude/Longitude layer is available on the layer selector:
The Latitude/Longitude layer requires two data numeric data items for the latitude and longitude:
The label field is used to provide a meaningful tooltip for the points. That’s because, generally speaking users will know the name of the store “ABC Retail,” but not necessarily the latitude and longitude of the store. For this reason, the label, but not the latitude/longitude location is displayed in the tooltip:
Much like the Points layer, Size and Color require a measure data item to style the circular points displayed at each unique latitude/longitude location.
Of course, you can define all three layer types, or any combination thereof, at the same time. In fact, in our example, there is a region layer on “State,” which resulted in the green color used to style Hawaii.
Latitude/Longitude Encoding
While there are several ways to store latitude/longitude , Cognos Analytics requires using a WGS 84 / World Geodetic System (WGS) encoding stored as numeric data items.
WGS 84 simply means latitudes between -90 and +90 degrees, and longitudes between -180 and +180 degrees suitable for use on a Web Mercator map. An example would be the White House in Washington DC located at latitude 38.897957, and longitude -77.036560.
Other formats such as degrees, minutes, second and decimal seconds for example 38° 53' 52.6452'' N, 77° 2' 11.6160'' W are not supported, nor are other X, Y coordinates systems. In such cases, the data would need to be converted to WGS 84 for use in Cognos Analytics.
Errors and Null Island
As part of our error checking, we determine if the latitude values in the data fall between -90 and +90 and longitudes between -180 and +180. Any values outside of these ranges cannot be mapped as they fall outside of the coordinate system. Rather than not mapping that data, we replace the query values with latitude 0 and longitude 0 which allows those data points to map so you can detect the error.
For instance, the 0, 0 location is found just off the coast of Africa in the Gulf of Guinea as shown below:
As there is no actual land mass there, this location is somewhat humorously referred to as “Null Island,” and is commonly used by mapping systems to display out of bounds data. If you ever see data mapped here, it’s probably in error.
The likeliest cause of such an error is putting the latitude and longitude data items into the opposite data slots when defining the map.
Geocoding
As odd as it sounds, mapping systems, generally speaking, cannot use addresses for locations. Rather, the mapping systems need to have the address converted to an latitude/longitude which can be mapped.
The process of converting an address to a latitude/longitude location is referred to as “geocoding.” Companies provide geocoding as a paid service. For example, the address of the White House “1600 Pennsylvania Ave NW, Washington, DC 20500” would be passed to a geocode service which would return the latitude 38.897957, and longitude -77.036560. These values are then stored into the RDBMS for use with Cognos Analytics.
Although, it is important to note that Cognos Analytics does not provide geocoding; your data must be geocoded before being used within Cognos Analytics.
Conclusion
Latitude/longitude support extends the report map support nicely and give us a further foundation to build on.
#11.0.8#authoring#classicviewer#CognosAnalytics#CognosAnalytics11.0.8#CognosAnalyticswithWatson#Event#ExpertPost#GeneralInformation#geospatial#Geospatialmapping#home#LearnCognosAnalytics#mapping#R8#Release#reporting#Resources