This is a short post. I hope. I do not know how long this will be, so this is more of an apriori statement. In any case, I have decided to make this a series of posts. This one will be, to make my initial statement true, a short post. I will lay out what I intend to describe in this series, why I intend to describe these points, and finally, how I intend to do the same. If that sounds very academic, do not worry. I shall endeavor to keep it light, frothy, bubbly, and fun. In any case, before I inject fun into this post, let me start by first stating that whatever I state in this post is my personal opinion, and that nothing I write should be taken as a statement of Oracle's product direction, nor a commitment to deliver features, in any release, etc... You know - the standard disclaimers. In any event, I will not, repeat, rinse, repeat - NOT - be talking about future functionality. Because, in the words of the Doc, "the future's not written".
It turns out, after speaking with customers, partners, and even people inside Oracle, and even books, that there is lingering confusion as to what map views are, how they work, what they can do, what they cannot do, what they should do, and so on. Part of this confusion arises from the fact that maps are not textual data visualizations. They aren't even graphical visualizations, in the strictest of senses, but more cartographic data visualizations.
They are close, in a lot of ways, to graphical visualizations, however, for the following reasons:
1. The representation of a metric on a map requires two separate components. One is, obviously, the data. Like "Yearly Revenue by State", or "Billed Quantity by Product Brand by Country", and so on. The second component that is required to complete a map visualization is the format. Yes, there is a third component here, but it is not essential in some cases, as I will demonstrate, but later. The second component is the choice of the data format. Map Views today support three types of geometries - polygonal, point, and linear.
2. For each geometry, different data formats are supported. Therefore, for polygons, you have at least six formats supported: a color fill, which in turn supports three different types of algorithms for determining the colors of the shapes; a bubble format, a variable shape, a bar graph, a pie chart, and even image formats. Sometime during development, we had yet another format that we wanted to support, but because of reasons that I will not get into, I, as the product manager, had requested that we remove it. And so it got removed. Anyway, the point is that data requires a format, which in turns is determined by the an attribute of the data we want to create a format on.
3. A tile. Wallpaper. Say what? Say this - if I were to format a metric by states of the US, you may or may not be able to make out the states quite so well. If, however, I were to plant a map of the United States below the formats, you would not have so much trouble now, would you? Precisely! The background map, the basemap, the tile layers - and we will eventually get into what these animals are - help provide context.
So what about the chart? A chart, like a pie, a bar, a scatter plot, etc... all are graphical representations of data, aren't they? You have numbers, and then you, as the data analyst, the report author, make a decision as to how those numbers should be visualized. The choice can be sometimes and somewhat arbitrary, and the less aware of best practices in data visualization the user, the more arbitrary these choices are likely to be. However, there is an element of choice involved in how data is visualized, and this choice in turn determines how the data is perceived and understood by the user.
Don't we have textual data visualizations that afford the same choices? Well, yes and no. You have table views, pivot views, and some other views that Oracle BI offers that are textual in nature, but that's about it. You can also determine the font, the color, the size of the numbers and text in the view, and you can also determine the order in which the data should be presented, but that's about it - it is, at the end of the day, or the night, still textual in appearance.
Next steps: I will add screenshots to this post to illustrate my points. But later.
Thank you. Take care.
Abhinav.
Bangalore, Oct 08, 2012
As part of the Oracle Author Podcasts, Paul Rodwick, VP of Oracle BI Product Management, spoke with Mark Rittman, author of the recently released Oracle Business Intelligence 11g Developers Guide. It is a massive tome, coming in at just under 1100 pages. I have been reading it, and hope to have a review up in a week or two, but in the meantime, peruse this informative podcast.
