Monday, October 11, 2010

I did a webcast last week on spatial data visualizations in Oracle BI EE 11g. This entire session was focused on mapping in the suite, and while I tried to split the time evenly between the front end and the back end parts of mapping, I realize that talking about and explaining how the magic actually happens requires more than 20 minutes or so.
The plan was to do a very quick introduction to maps in 11g, and then dive straight into demonstrations. I have followed this path frequently in the last - start off at the top, show the capabilities of the product in the Dashboards interface, as end-users would see it. In most deployments, your dashboarding product is seen by more than 90% of the users. Then move to Answers, the report creation and analysis interface. Often also known as the "power user interface", this is where analysts will often go to to perform deep analysis using the tools at their disposal. Answers is also the product that is used to create the analyses - tables, pivots, graphs, maps, gauges, etc... - that are published to a Dashboard page.
The point of starting out with a Dashboards demo is to show how easy to use the interface in maps is for end-users, and the great number of options available to them, from sliders on color ramps, to drilling, to invoking Actions, to sending master events to listening views, to checking on or off different formats displayed on a map, and more.
After this little bit of magic is shown to the user, the focus then shifts to Answers. Here the point is a little different, and yet much the same too. To show how easy it is to create reports with maps. That maps are really just another view in the product suite. A point-and-click interface is what drives the creation of maps. That it is possible to create maps in as little as 15 seconds. Or less.

As we move further down the rabbit hole, we come to the little piece of magic that actually creates the maps. But before that, I explain that placing analytics data on a map is really no different than fetching a column of data from another table. Which is what you do when you write SQL statements that use foreign key joins. Maps are no different. You need to fetch the spatial attributes of a geographical column. The spatial attributes often reside in a table in a column of data type sdo_geometry, while the rest of the information is coming from your analytics warehouse. What makes it possible to have MapViewer display non-spatial information along with spatial information is the Non-Spatial-Data-Provider plug-in mechanism. Read MapViewer Concepts fro the Oracle® Fusion Middleware User's Guide for Oracle MapViewer 11g Release 1 (11.1.1) Part Number E10145-04

Towards the end of the session, I had this neat little slide that I borrowed from one of David Lapp's excellent presentations, that I think captures very neatly the four main scenarios of mapping in an analytics environment.