BACKGROUND

Field

[0001] The present disclosure is directed to data analytics, and more specifically, to methods and devices for data visualization for big data analytics.

Related Art

[0002] Recently big data has gotten a lot of attention. Organizations have expectations from big data technologies because they think many insights can be derived from the data. For example, many companies have been collecting huge amounts of data from their equipment and processes. These companies would like to leverage the big data technologies so that they may derive useful knowledge from the data and eventually improve efficiency and/or productivity. Data analytics may be useful for this purpose.

[0003] Data visualization of both the result of the data analytics as well as the data itself is one of the essential parts of any data analytics system because a human is not capable of understanding a huge amount of data directly. Thus, summarizing the data in an intuitive way can have an important role. This can be especially important when focusing on the application of information technology (IT) (e.g., data management, statistics, data mining, machine learning, operations research, combinatorial optimization, etc.) to operation technology (OT) industries (e.g., mining, oil & gas, and power, etc.) where data keeps coming in from sensors and the data must be analyzed, either in real time or periodically, to produce operational insights. The data in the OT industries tends to have IDs, timestamps, values, and sometimes locations.

[0004] In the related art, an application that has visualized analytics results and visualized data is referred to as a dashboard. A dashboard may contain a number of tables, charts, or maps. A related art approach to developing a dashboard is to separately build or code every table, chart, or map for each given schema of data. However, this related art approach has such a drawback that previously built visualization components cannot be deployed for different use cases without modification or customization.

SUMMARY

[0005] The present disclosure is directed to a device and a method that relate to big data analytics. In example implementations, there is a method for visualization components to be used among different types of data.

[0006] Aspects of the present disclosure include an apparatus that may include a memory and a processor. The memory may be configured to store data corresponding to data sets. The processor may be configured to manage a plurality of data sets, a plurality of visualization functions configured to provide a type of visualization, and a data converter including a plurality of data classes configured to define visualization processes for the plurality of visualization functions, associate each of the data sets with a visualization function from the plurality of visualization functions and a data class selected from the plurality of data classes, process the data of each of the data sets through the associated data class to generate visualization data, process the visualization data through the associated visualization function to generate a visualization, and refresh the visualization according to the visualization process defined by the associated data class.

[0007] Aspects of the present disclosure also include a method, which may involve storing data corresponding to data sets, managing a plurality of data sets, a plurality of visualization functions configured to provide a type of visualization, and a data converter including a plurality of data classes configured to define visualization processes for the plurality of visualization functions, associating each of the data sets with a visualization function from the plurality of visualization functions and a data class selected from the plurality of data classes, processing each of the data sets through the associated data class to generate visualization data, processing the visualization data through the associated visualization function to generate a visualization, and refreshing the visualization according to the visualization process defined by the associated data class.

[0008] Aspects of the present disclosure further include a computer program, storing instructions for executing a process. The instructions may include storing data corresponding to data sets, managing a plurality of data sets, a plurality of visualization functions configured to provide a type of visualization, and a data converter including a plurality of data classes configured to define visualization processes for the plurality of visualization functions, associating each of the data sets with a visualization function from the plurality of visualization functions and a data class selected from the plurality of data classes, processing each of the data sets through the associated data class to generate visualization data, processing the visualization data through the associated visualization function to generate a visualization, and refreshing the visualization according to the visualization process defined by the associated data class.

[0009] Aspects of the present disclosure additionally include an apparatus. The apparatus may include means for storing data corresponding to data sets, means for managing a plurality of data sets, a plurality of visualization functions configured to provide a type of visualization, and a data converter including a plurality of data classes configured to define visualization processes for the plurality of visualization functions, means for associating each of the data sets with a visualization function from the plurality of visualization functions and a data classes selected from the plurality of data classes, means for processing each of the data sets through the associated data class to generate visualization data, means for processing the visualization data through the associated visualization function to generate a visualization, and means for refreshing the visualization according to the visualization process defined by the associated data class. BRIEF DESCRIPTION OF DRAWINGS

[0010] FIG. 1A illustrates a schematic representation of a problem associated with the related art data analytics visualization system.

[0011] FIG. IB illustrates a schematic representation of a data analytics visualization system according to an example implementation.

[0012] FIG. 2 illustrates an example of a computing device upon which example implementations may be implemented.

[0013] FIG. 3 illustrates a flow diagram for a data visualization process in accordance with an example implementation.

[0014] FIGS. 4A-4C illustrate tables of metadata in accordance with an example implementation.

[0015] FIGS. 5A and 5B illustrate tables of two received batches or sets of the data to be used in the processing by the system according to an example implementation.

[0016] FIGS. 6-8 schematically illustrate different data classes that may be included within the data converter for visualization according to example implementations of the present application.

[0017] FIG. 9 illustrates a process for updating a data visualization for a class in accordance with an example implementation.

[0018] FIG. 10 illustrates a process for updating a data visualization for a class in accordance with an example implementation.

[0019] FIG. 11 illustrates a process for updating a data visualization for a class in accordance with an example implementation.

[0020] FIG. 12 illustrates an example output for a class in accordance with an example implementation. [0021] FIG. 13 illustrates an example output for a class in accordance with an example implementation.

[0022] FIG. 14 illustrates an example output for a class in accordance with an example implementation.

[0023] FIG. 15 illustrates an output of the schema correspondence unit according to an example implementation.

DETAILED DESCRIPTION

[0024] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application.

[0025] The present disclosure facilitates an abstraction layer that converts the incoming data for visualization. In example implementations, the device and the method for building big data analytics applications utilizes a data handling unit that converts input data into data for visualization, a schema correspondence unit that maps the schema of the data for visualization into the schema that a specified widget requires, a visualization unit that visualizes the data with the accurate schema for the widget, and a storage unit storing metadata that defines what data to use, what schema the data has, how to convert the data for visualization, and what widget to use.

[0026] In a related art situation, when a data analytics visualization system is created, a data visualization component must be created or programmed individually for each given dataset. This can be a problem if the number of different data sets is huge. A developer has to develop different visualization components for each data set even if the desired visualizations are exactly the same type (e.g., line chart). FIG. 1A illustrates a schematic representation of the problem associated with the related art approach for data analytics visualization system in this situation. If there are M different types of data 105a-105m and N different types of visualization components or widgets HOa-l lOn (e.g., charts, maps, tables), there can be up to M x N implementations. As used here, the "type" °f data may vary based on the regularity with which the data is received (e.g., one-off or one-time data, periodically occurring data, or streaming data, which will be explained later) as the data is a given number of rows with a fixed schema. However, in larger implementations over a cloud or those that involve big data analytics, the values of M and N may be quite large, which thereby consumes memory and processing power of the supporting infrastructure in an exponential manner to store and process M x N different implementations.

[0027] FIG. IB illustrates a schematic representation of a data analytics visualization system according to an example implementation. Again, there are M different types of data 105a- 105m and N different types of visualization components or widgets 110a- 11 On (e.g., charts, maps, tables). Additionally, there is an abstraction layer that provides a data converter 115 that includes O different data classes 120a-120o. Each data class 120a-120o of the data converter 115 may be configured to define a visualization process that can be used to convert received data into a common format that can be used by previously implemented generalized visualization widgets HOa-l lOn. If the previously implemented widgets can be re-utilized, development costs and time may be reduced. By utilizing an abstraction layer that provides a data converter 115 that includes multiple data classes 120a-120o and that converts the incoming data to data for visualization, the number of implementations that must be developed may decrease to a value M + N, thereby making memory and processing power consumption of the supporting infrastructure to be linear instead of exponential as in the related art implementations.

[0028] Thus, in a related art method, the developer must prepare M*N different implementations during the implementation phase as illustrated with respect to FIG. 1A. On the other hand, in an example implementation of the present application, the computer only needs to prepare M+O+N implementations because the data converter 115 can handle multiple data classes 120a-120o. Thus, example implementations of the present application have an advantage of dramatically reduced implementation costs.

[0029] A configuration example of a device that implements a technology of a first embodiment will be described with reference to FIG.2. FIG.2 illustrates an example computer device 200 upon which example implementations may be implemented. The computer device 200 is an information processing device such as a personal computer (PC), a server, or a workstation. The computer device 200 includes a central processing unit 205 (CPU), a memory 215, a storage 220, an input device 210, an output device 225, and a communication device 230, which are connected to each other via an internal communication line such as a bus 235.

[0030] The storage 220 is, for example, a storage media such as a compact disc recordable (CD-R), a digital versatile disk random access memory (DVD-RAM), or a silicon disk, a driving device of the storage media, or a hard disk drive (HDD). The storage 220 stores metadata 240 and programs 245. The metadata 240 may consist of multiple kinds of metadata. For example, metadata for widgets and metadata for correspondence between what columns have data and what columns for which a widget for visualization are needed may be stored. The programs 245 may implement the functions which will be described below with respect to FIGS. 3 and 6-8 below. The functions may be loaded into the memory 215 when the programs 245 are executed. [0031] The input device 210 is device for input including, for example, a keyboard, a mouse, a scanner, or a microphone. The output device 225 can include, for example, a display, a printer, or a speaker. The communications device 230 can include, for example, a local area network (LAN) board and is connected to a communication network (not illustrated).

[0032] The CPU 205 may load the programs 245 into the memory 215 and executes the programs 245 to implement a data handling unit 250, a schema correspondence unit 255, and a visualization unit 260.

[0033] The data handling unit 250 determines what kind of data is being received by referring to the metadata 240 and converts the data into a common shape that is not dependent on the data types. The data handling unit 250 then sends the result to the schema correspondence unit 255. Examples of the types of input data the data handling unit 250 may handle, and how the data handling unit 250 converts the received data to the data that is sent to the schema correspondence unit 255, will be described below.

[0034] The schema correspondence unit 255 receives the data from the data handling unit 250 and converts the schema of the data into a schema that is suitable for a widget (e.g., a visualization component) that is specified in the metadata 240. The method of converting the schema is also defined in the metadata 240. The converted data will be sent to the visualization unit 260. Examples of the schema conversion will be described in greater detail below.

[0035] The visualization unit 260 obtains the data from the schema correspondence unit 255 and visualizes the data. Based on the data to be shown on a dashboard, any implementation that enables the visualization (e.g., line chart, table, map, bar chart) may be used. Thus, visualization schema may be shared and used for different data types. [0036] An example implementation has been described herein with an order of the process explained in the order of the data handling unit 250 and the schema correspondence unit 255, but example implementations of the present application are not limited to this configuration. A configuration of having the schema correspondence unit first and having the data handling unit 250 following the schema correspondence unit 255 could alternatively be used. For the simplicity of explanation in this document, continued explanation will go on with the order of the data handling unit 250 first and the schema correspondence unit 255 second.

[0037] In FIG.2, it is assumed that all the needed units are loaded in the memory in the same computing device, but it is also applicable to implement the units in multiple different computing devices and the units communicate one another through the communicating device. For example, a client-server communication model may be used. In this model, for example, the data handling unit 250 can be on the server and visualization unit 260 can be on the client. A configuration of having both of the units on the client side is also possible.

[0038] FIG. 3 illustrates a flow diagram for a data visualization process 300 in accordance with an example implementation. In the data visualization process 300, the processing of the data handling unit 250 occurs at 305. In the processing of the data handling unit 250, a new set of data comes into the data handling unit 250. When the data handling unit 250 receives the new set of data, the data handling unit 250 reads the metadata 240 to see what kind of schema and what kind of visualization class should be used for the received new set of data. Examples of the visualization classes will be described below. The new set of data may come in one of a number of ways. For example, new data can come as: [0039] Static data or one-off data that will not change and comes in or is received only once,

[0040] Periodic data that comes in batch periodically or is received on a periodic schedule, for example once every five seconds, or

[0041] Streaming data that is received on an irregular schedule such that developers may not be able to predict when a new data set for the data comes.

[0042] With respect to streaming data, the processing of the data handling unit 250 at 305 should be triggered by data arrival at the data handling unit 250. With respect to static data or periodic data, the processing of the class handling 250 at 305 may be triggered by data arrival or may also be triggered by the data fetching process after actively retrieving the data. At 305, the data handling unit 250 may also convert the received input data to fit into a common data structure that is independent of the classes.

[0043] After the processing of the data handling unit 250 at 305, the processing of schema correspondence unit 255 is performed at 310. During the processing of schema correspondence unit 255, the schema correspondence unit 255 converts the data from the data handling unit 250 into a data schema to satisfy the visualization unit (e.g., widget) about the schema.

[0044] At 315, the processing of the visualization unit 260 occurs after the processing of the schema correspondence unit 255 at 310. During 315, the visualization unit 260 visualizes the data that the schema correspondence unit 255 output. As discussed above, the processing of the data handling unit 250 at 305 and the processing of the schema correspondence unit 255 could be swapped.

[0045] FIGS. 4A-4C illustrate tables of metadata 240 in accordance with the example implementations. FIG. 4A illustrates a table 400 of metadata associated with what data is visualized and how the data is visualized. Each row in table 400 corresponds to an individual association between data to be visualized and widget (e.g., visualization unit) to visualize, as well as what class should be used for the visualization. The classes for visualization will be explained in greater detail below. In this example implementation, all the metadata associated with data is illustrated in a single table. However, other example implementations can also have multiple tables to serve the same purpose.

[0046] In table 400, column 405 corresponds with a visualization ID number ("VizID") associated with each row. Column 410 corresponds with a Data Name associated with each row. The Data Name indicates which data to visualize and, for simplicity, only one data source is illustrated as an example. However, multiple data sources could be used.

[0047] Column 415 corresponds with a "Schema" associated with each row. The "Schema" indicates what schema or arrangement that data has. In this example, the Data associated with Data Name "Sample Data" is assumed to have four columns: Location, Timestamp, Temperature, and Precipitation. FIGS. 5A and 5B discussed below show examples of two received batches or sets of this data.

[0048] Column 420 corresponds to an "ID" that specifies which column of the table 400 corresponds to data ID that is used for updating data sets according to received data. The contents of Column 420 may be used by the system to understand which rows come from the same place/person/equipment and so on. In Table 400, only one column 420 (e.g., "Location") is specified as ID, but in other example implementations, this can be a combination of columns because data may often have a hierarchical location structure.

[0049] Column 425 corresponds to the "Class" associated with each row. The "Class" specifies how to define what data is to be visualized for each row. Examples of classes will be described below. Column 430 corresponds with a visualization function (e.g., "Widget") for the system to understand which widget it should use for each row. Column 435 illustrates the data "Correspondence," which tells the system what the correspondence is between columns that have data to be visualized and what fields are required from the specified visualization function (e.g., Widget). Examples of visualization functions may include the table visualization function, the ticker visualization function, the clock visualization function, the pie chart visualization function, the line chart visualization function, the gauge chart visualization function, the map popup visualization function, the html visualization function, and the image visualization function. The requirements from the widgets will be described below.

[0050] FIG. 4B illustrates a metadata table 440 having one column 445 defining a parameter that is used for the classes that will be explained later.

[0051] FIG. 4C illustrates a metadata table 450 that defines what data fields are required from each visualization function (e.g., Widget). The table 450 includes a column 455 identifying each potential visualization function (e.g., Widget) and a column 460 identifying the data fields required for each visualization function. Each of the required data field has a logical meaning to the visualization function. For example, in the case of "line chart", "x" and "y" values are definitely required to identify where to plot a point, and "line name" is required to understand which line a point belongs to when the number of lines is more than one. If "line name" is not provided, the default line name will make all the points belong to the same line.

[0052] FIGS. 5A and 5B illustrate tables 500 and 525 of two received batches or sets of the data to be used in the processing by the system. Both table 500 and 525 include a column 505 corresponding to a location the data was captured and a column 510 corresponding to a timestamp when the data was captured. Further, both table 500 and 525 include a column 515 containing temperature data and a column 520 containing precipitation data. For purposes of this discussion, the data in table 500 was captured or received first and table 525 was captured or received second. For simplicity, two batches are shown in this example implementation. However, more or less batches of data may be captured or received in other example implementations.

[0053] Referring to FIGS.6-14, the processing of the data handling unit will be described. First, the concept of data classes that may be included within the data converter 115 for visualization illustrated in FIGS. IB will be described. FIGS. 6-8 schematically illustrate different data classes that may be included within the data converter 115 for visualization according to example implementations of the present application. The present application contemplates at least three data classes that may be included within the data converter 115 for visualization from the abstraction perspective:

[0054] Class 1 is illustrated in FIG. 6 and involves visualizing the most recently received data for each of the IDs. As illustrated in FIG. 6, the first visualization 605 includes four IDs (e.g., IDl, ID2, ID3, ID4) having respective values of 3, 1, 4, and 5. As illustrated, new data is received for ID2 (new value 6), but no new data is received for the other IDs (IDl, ID3, ID4). In the second, updated visualization 610, the new value of ID2 (6) is shown with the earlier values for the other IDs (IDl, ID3, ID4). Class 1 visualization is useful for cases of asynchronous and irregular updates and all the latest values are of interest to the application.

[0055] Class 2 is illustrated in FIG. 7 and involves visualizing only the most recent data. As illustrated in FIG. 7, the first visualization 705 includes four IDs (e.g., IDl, ID2, ID3, ID4) having respective values of 3, 1, 4, and 5. As illustrated, new data is received for 3 IDs (IDl, ID2, and ID4) with new values of 1, 3, and 5 being received respectively. No new data is received for the ID3. In the second, updated visualization 710, only the new data received is displayed (e.g., IDl, ID2, and ID4). As no new data was received for ID3, no data is display for ID3 in the second visualization. Class 2 visualization is mainly useful for synchronous updates. [0056] Class 1 and 2 provide snapshot kind of visualization. Class 3 is illustrated in FIG. 8 and involves visualizing how historical data changes over time. As illustrated in FIG. 8, the first visualization 805 line plots of different data points for two different IDs (ID1 and ID2) over a 15-second window from 10:00:00 to 10:00: 15. As illustrated, the data value associated with each ID has changed over this time window. For each ID, new data points are received with a timestamp of 10:00:20. In the second, updated visualization 810, the new data points received with the timestamp of 10:00:20 have been added to the plots and the 15-second window has been updated to extend from 10:00:05 to 10:00:20. Class 3 visualization is useful for both synchronous and asynchronous updates.

[0057] These classes were developed based on the observation that when the new data arrives, visualization components need to be updated. The visualization component can have two possible states: 1) it can be showing data only for a previous timestamp, or 2) it can have some historical data (e.g., Class 3). For state 1), there can be two options: a) replacing all the data that was shown previously with all the data that the visualization components received (e.g., Class 2), or b) replacing each row in the data that was shown previously with the row with the same ID that is in the data that the visualization components received if the row exists, and if it doesn't exist keep the previous data for the row (e.g., Class 1).

[0058] Although all previous use cases faced by the inventors are covered by one of these classes, an aspect of the present application is that having the data handling unit 250 allows new class implementations to be added when a new use case is faced. Other than adding a new class implementation, no other changes are required, for example, for widget implementations.

[0059] In example implementations, the data handling unit 250 looks at the metadata associated with received data to determine what class should be used for visualization and based on the identified class, the data handling unit 250 determines a process for updating a data visualization. FIGS. 9-11 show example processes corresponding to Classes 1-3, respectively, and FIGS. 12-14 discussed below illustrate example outputs of these processes for Class 1, Class 2, and Class 3, respectively. With respect to class 3, there is a parameter (e.g., Column 445 of Table 440 of FIG. 4B) in metadata so that the system can understand what the amount of the data that the system has to keep in memory. In some example implementations, the parameter is defined in terms of time duration. However, other ways of defining the parameter may also be used (e.g., number of rows of data).

[0060] FIG. 9 illustrates process 900 for updating a data visualization for Class 1 in accordance with an example implementation. In the process 900, most recently displayed data (e.g., the data of table 500 of FIG. 5A) is fetched at 905 and substituted to storage S. After the recently displayed data is fetched, each row R of incoming data (e.g., the data of table 525 of FIG. 5B) is compared to the fetched data to determine if the ID of the row R is in the keys stored in storage S at 910. If the ID of Row R is present in the keys stored in storage S (YES AT 910), the value associated with the ID of R in the storage S is replaced with the row R of the incoming data at 915. Conversely, if the ID of Row R is not present in the keys stored in storage S (NO AT 910), the row R is added to the storage S with the ID of R as the key at 920. After 915 or 920, the values of all data stored in S are output as new visualization data at 925. After the values of data stored in S are output as new visualization data, the process 900 ends. The storage S here serves as the generalized visualization data buffer for all widgets.

[0061] FIG. 10 illustrates process 1000 for updating a data visualization for class 2 in accordance with an example implementation. In the process 1000, each row R of incoming data (e.g., the data of table 525 of FIG. 5B) is output as visualization data at 1005. After each row R of incoming data is output as visualization data, the process 900 ends.

[0062] FIG. 11 illustrates process 1100 for updating a data visualization for class 3 in accordance with an example implementation. In the process 1100, most recently displayed data (e.g., the data of table 500 of FIG. 5A) is fetched at 1105 and substituted to storage S. After the recently displayed data is fetched, each row R of incoming data (e.g., the data of table 525 of FIG. 5B) is compared to the fetched data to determine if the ID of the row R is in the keys stored in storage S at 1110. If the ID of Row R is present in the keys stored in storage S (YES AT 1110), the row R is appended to a list of data points associated with the ID of row R in the storage S at 1115. Conversely, if the ID of row R is not present in the keys stored in storage S (NO AT 1110), an empty list L associated with the ID of row R as the key is added to the storage S at 1120. After 1120, the process 1100 continues to 1115, and the row R is appended to the empty list associated with the ID of row R added in 1120. After 1120, the elements of list L are parsed from the beginning and any element having a time stamp before the time stamp of row R~the duration specified in the metadata parameter (e.g., Col. 445 of Table 440 of FIG. 4B)~is removed at 1125. After the list L is parsed, the values of all data stored in storage S are output as new visualization data at 1130. After the values of data stored in storage S are output as new visualization data, the process 1100 ends.

[0063] FIG. 12 illustrates an example output 1200 for class 1 in accordance with an example implementation. As illustrated, the example output includes 5 rows of data (1205-1225). Rows 1210-1220 correspond with data in table 500 of FIG. 5A and represent data that had been previously visualized. Further, rows 1205 and 1225 correspond with data in table 525 of FIG. 5B and represent data that has been recently received (e.g., incoming data). As illustrated, data that changed in the incoming data has been updated, and data that was unchanged has not been updated.

[0064] FIG. 13 illustrates an example output 1300 for class 2 in accordance with an example implementation. As illustrated, the example output includes 3 rows of data (1305-1315). Rows 1305-1315 correspond with data in table 525 of FIG. 5B and represent data that has been recently received (e.g., incoming data). No data illustrated in output 1300 corresponds with data previously visualized. As illustrated, only data in the incoming data has been displayed.

[0065] FIG. 14 illustrates an example output 1400 for class 3 in accordance with an example implementation. As illustrated, the example output 1400 includes 7 rows of data (1405-1435). Rows 1405, 1415, 1420, and 1430 correspond with data in table 500 of FIG. 5A and represent data that had been previously visualized. Further, rows 1410, 1425, and 1435 correspond with data in table 525 of FIG. 5B and represent data that has been recently received (e.g., incoming data). As illustrated, data from both table 500 of FIG. 5A and table 525 of FIG. 5B has been combined to show the change in the data over time.

[0066] After the visualization data has been generated based on each class designation, the schema correspondence unit 255 may look at the metadata and the correspondence information (e.g., Column 435 of Table 400 of FIG. 4) stored in the metadata. Based on the correspondence information, the schema correspondence unit may convert the visualization data as indicated by the metadata.

[0067] FIG. 15 illustrates an output 1500 of the schema correspondence unit 255 according to an example implementation. The output 1500 is based on the data tables 500, 525 of FIGS. 5 A and 5B, and the metadata tables 400, 440, 450 of FIGS. 4A-4C. The output 1500 includes four tables 1505-1520 corresponding to rows of the metadata table 400 of FIG. 4 A. Table 1505 corresponds to VizID 1, which involves a class 1 transformation as discussed above to FIG. 12. Table 1510 corresponds to VizID 2, which involves a class 2 transformation as discussed above to FIG. 13. Tables 1515 and 1520 correspond to VizID 3 and VizID 4, which both involve class 3 transformations as discussed above to FIG. 14. Tables 1515 and 1520 corresponding to VizID 3 and VizID 4 illustrate that x-axis of line charts are not necessary to be 'Timestamped' in the case of Class 3. Based on the data shown in FIG. 15 as an example, the visualization unit 260 generates visualization.

[0068] Finally, some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0069] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

[0070] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to, optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0071] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0072] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0073] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.