Blog

What's happening? What's new? What can I do? Find answers to these questions in the blog.

Archive Results

Blog

Mapbox hosted custom polygons in reports and dashboards

With Cognos Analytics 11.0.11 users will be able to visualize custom polygons hosted on Mapbox within reports and dashboards! Here’s how you can start visualizing your custom geospatial polygons in Cognos! You can refer to the instructions below or watch the video that shows you how to add custom polygons. If you don’t have a MapBox studio account already the first step would be to create one (each organization/department can host all their polygons on one account). For many of our users the free account with 5GB of storage space should be more than sufficient to host all their polygons. Then upload your geoJSON custom polygon file to Mapbox as a tileset. Custom polygons in different formats such as .shp and .KML can be easily converted to geoJSON using several open-source software (QGIS is recommended). A tile-set is essentially a compiled set of geoJSON optimized to render fast on a browser. If your geoJSON is under 5MB, you will also be able to edit the geoJSON directly in Mapbox-datasets through an intuitive UI. Once edited it can be exported into a tileset. Each polygon will need to have at least one uniquely identifying property (we recommend that this be an abstract identifier) Ensure the tileset is made Public (Tilesets are public by default) Once you have you tileset created in Mapbox you will need 3 keys from the tileset page. 1 – MapID, 2 – Layername, 3 – Property Name (unique identifier)   Mapbox tileset In the Cognos Map visualization expand the properties pane and enter the 3 keys from the step above. This workflow is identical in both Cognos reporting and dashboards. Then simply drag your Property name (unique identifier) into the locations slot and a measure (s) under the location colour/Point colour/point size slot. That’s it!     Note – if your custom polygons are points then enter the 3 keys in the points layer instead. Best practices Do not add any confidential or sensitive information as a polygon property. Although, not common, if your existing geoJSON has sensitive information in its properties, we recommend that you remove them before uploading your polygons to Mapbox. Best practice would be to make the geoJSON property an abstract identifier. Share the 3 keys to your Mapbox tiles on a need-to-know basis. For better performance and to guarantee polygons appearing at zoom level 0 (world view) it is recommended to compress larger geoJSON files to less than 10MB. http://mapshaper.org/ is a fantastic free tool to do this. a. geoJSON larger than 10MB will be set default zoom extents that may not begin at worldview – level 0 (this is a mapbox optimization technique). However, if you want to manually change the zoom extents there are few ways to do so. i. Tippecanoe APIs (Linux, MacOS) ii. Download Mapbox studio classic on your desktop (windows) and change min/max zoom levels iii. Mapbox documentation here: https://www.mapbox.com/help/adjust-tileset-zoom-extent/ To ensure that autozoom works in Cognos reporting we recommend setting the unique polygon identifier as a string value. For those working with custom polygons in small areas (postcode level) we recommend turning off auto zoom after the initial map render. This will result in a better experience when filtering as the map will not have to reset zoom and pan in multiple times. Related posts: New Base Samples for IBM Cognos Analytics 11.0.11 IBM Knowledge Center: Setting up Mapbox to work with IBM Cognos Analytics IBM Knowledge Center: Using custom point or region information from Mapbox in a map vizualization in a dashboard IBM Knowledge Center: Using custom point or region information from Mapbox in a map visualization in a report Please visit our IBM Business Analytics Support channel on YouTube.

Blog

#Cognos Analytics 11.0.8: Adding Latitude/Longitude Maps in Reports

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.