CN106463055B

CN106463055B - Fast visual rendering

Info

Publication number: CN106463055B
Application number: CN201580018520.8A
Authority: CN
Inventors: 迪帕克·梅鲁谷
Original assignee: Urban Engines Inc
Current assignee: Urban Engines Inc
Priority date: 2014-04-04
Filing date: 2015-04-03
Publication date: 2023-05-30
Anticipated expiration: 2035-04-03
Also published as: EP3127101A1; CN106463055A; EP3127101A4; WO2015154041A1; CA2944396A1; WO2015154041A9

Abstract

A system for rapid visual rendering includes a server computer and a client device. The client device determines a data set required for rendering the visualization on the client device based on the user input and sends a request for the data set to the server computer. The client device receives one or more terse tables corresponding to the data set, generates the data set by combining the received one or more terse tables, and renders a visualization on the client device based on the data set.

Description

Fast visual rendering

Cross Reference to Related Applications

The present application claims priority from U.S. C. ≡119 (e), "U.S. provisional patent application serial No. 61/975,664"Fast Rendering of Visualization filed on 4/2014, "and U.S. non-provisional patent application serial No. 14/578,267"Fast Rendering of Visualization filed on 12/19/2014, the entire contents of which are incorporated herein by reference.

Background

1. Technical field

The present disclosure relates generally to the field of server-client data communications, and in particular, to fast visualization rendering under a server-client architecture.

2. Related art

Industry now follows a conventional server-client architecture for sending data and enabling visualization on clients. This traditional architecture and the division of work between server and client may have significant drawbacks. For example, in a conventional server-client architecture, a significant amount of data processing work needs to be done on the server, resulting in server overload.

In addition, to enable rendering of visualizations on a client, the server and client may need to communicate a large number of processing results with each other. Thus, communication of a large number of processing results may lead to intolerable delays in visual rendering.

Drawings

FIG. 1 is a high-level block diagram of an example computing environment for implementing fast visual rendering, according to one embodiment.

FIG. 2 is a block diagram illustrating components of an example machine capable of reading instructions from a machine-readable medium and executing the instructions in a processor (or controller) to act as a client device and/or server, according to one embodiment.

FIG. 3 is a flowchart illustrating an example method for providing a terse table, according to one embodiment.

FIG. 4 is a flowchart illustrating an example method for implementing an application, such as rendering a visualization on a client device, in accordance with one embodiment.

Fig. 5-11 are example graphical representations of user interfaces displaying different visualizations.

Detailed Description

The disclosed embodiments have advantages and features that will be more apparent from the detailed description and drawings (or figures).

The figures and the following description relate to preferred embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.

Reference will now be made in detail to various embodiments, examples of which are illustrated in the accompanying drawings. Note that wherever possible, similar or identical reference numbers may be used in the drawings and may indicate similar or identical functions. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. Those skilled in the art will readily recognize from the detailed description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

Configuration overview

To overcome the shortcomings of conventional server-client data communication architectures, systems (and computer-implemented methods) are configured to implement applications on client devices. In one example configuration, the system determines a set of data required to implement an application on a client device based on user input. The system sends a request for a data set to a server and receives one or more terse tables corresponding to the data set. The system combines one or more terse tables to generate a dataset. The system then implements the application on the client device based on the data set.

This system provides a number of advantages over conventional models. First, the system enables a tremendous reduction in the size of data sent by a server, for example, in applications where the processed data is highly dependent on specific generic data. Second, the system allows faster communication between the server and the client, and thus reduces communication latency. This is particularly helpful for interactive and real-time visualization. Third, the system reduces the load on the server side and results in a simpler and compact Application Programming Interface (API) on the server side. Fourth, the system enables fast and real-time interaction with large data sets by using simple data chunk logic and handling all processing on the client side. Fifth, local caching and processing makes the system suitable for offline use as well. Sixth, the system uses local processing logic and allows for faster development.

Example computing Environment

FIG. 1 illustrates a computing environment 100 for implementing fast visual rendering, according to one embodiment. The computing environment 100 includes a server 110, a plurality of client devices 170, and a database 130 connected by a network 150. Only one server 110, two client devices 170, and database 130 are shown in fig. 1 to simplify and clarify the description. Alternative or additional embodiments of computing environment 100 may have multiple servers 110, client devices 170, and databases 130 connected to network 150. Similarly, the functions performed by the various entities of fig. 1 may vary in different embodiments.

The server 110 includes a record processing module 115. Database 130 includes one or more terse tables 135. Client device 170 includes a browser 190, with a table processing module 175 and a visualization module 177 within browser 190.

The server 110 generates and stores a terse table for rendering visualizations for the user on the client device 170. In one embodiment, the server 110 retrieves raw data from various resources and processes the raw data to generate a compact table. In addition, the server 110 provides the terse tables to the client device 170 via the network 150 in response to receiving the request from the client device 170. In one embodiment, the server 110 includes a record processing module 115, but other embodiments of the map server 110 include different and/or additional components. In addition, functionality may be distributed among components in a different manner than described herein.

The record processing module 115 processes the raw data and generates a compact table based on the processed raw data. In one embodiment, the record processing module 115 collects raw data related to public transportation from various sources. The raw data may include records collected from transportation systems including bus lines, trains, subway lines, and the like. For example, each transportation station, such as a subway station, may be equipped with sensor units that allow commuters to brush in and out (e.g., at the entrance and exit of the subway). In another example, each conveyance, such as a subway, bus, or train, may be equipped with similar sensor units to detect entry and exit of commuters. In either case, records of the commuter's brushing in and brushing out of the vehicle may be collected from the sensor unit.

In another embodiment, the raw data may also include metadata of public transportation of a transmission line such as a bus, train, subway line, or the like. In another embodiment, the record processing module 115 collects transportation system center data, such as speed measurements and Global Positioning System (GPS) location for the transportation vehicle, site information, site occupancy information, traffic delay information, and the like. In yet another embodiment, the record processing module 115 also collects raw data from mobile applications (apps) used by the commuter. For example, the record processing module 115 collects an independent GPS log of the communicants.

In one embodiment, the record processing module 115 analyzes the collected raw data to generate processed data. For example, the processed data may describe movement of an independent conveyance (e.g., bus, train, subway). In another example, the processed data may also describe an estimated wait time for each traffic line at each station or site. In particular, the record processing module 115 analyzes the collected records and calculates a wait time for each line at each station or site based on transportation system center data and/or sensor data such as swipe in and swipe out data. For example, the record processing module 115 may use speed measurements and geolocation of the bus to estimate the wait time at a stop on the bus line. The record processing module 115 may also use traffic delay information to dynamically adjust the latency. In addition, the record processing module 115 can use the swipe in and swipe out data to calculate how many people are currently on the bus, use the station occupancy information to determine how many people are waiting at the next stop of the bus, and then estimate whether all waiting people can get on at that next stop. The record processing module 115 then adjusts the latency based on the estimate. In further examples, the processed data may also describe occupancy of each transport, such as how many people are on each bus, train, or subway. Additional details regarding the operation of the record processing module 115 may be found in the copending application entitled "Transportation System Reconstruction" filed on even date herewith by Morteza Ibrahimi, damon Jude Wischik, christopher David Pluntke, balaji Satyanarayana Prabhakat, and deep Merugu. The entire contents of this copending application are incorporated herein by reference.

In one embodiment, the record processing module 115 extracts information from the processed data and stores the extracted information in a compact table. A terse table is a table that may include data describing elements or properties that are used to generate a Graphical User Interface (GUI) used to render a visualization to a user. For example, a terse table stores data blocks defining the location of elements in the GUI and element patterns such as color, size, shape, etc. In one embodiment, the terse table includes a plurality of entries, each entry corresponding to such a block of data. In one embodiment, the terse table stores data generated based on records within a predetermined length of time, such as three months. The record processing module 115 stores the terse tables in the database 130. In one embodiment, the terse table is a table with a standardized data scheme to minimize redundant data and improve storage efficiency.

In one embodiment, the record processing module 115 provides a compact table to the client device 170. For example, the record processing module 115 receives a request for a terse table from the client device 170 and, based on the request, retrieves the requested terse table from the database 130 to provide the requested terse table to the client device 170 without any processing of the requested terse table. According to some embodiments, only a portion of the terse table (such as a portion including one or more entries) is requested, and the record processing module 115 retrieves the requested entry and sends to the client device 170. For example, the client device 170 has received a compact table for rendering a GUI that displays dynamic operation of the bus system. The terse table includes data defining bus paths, locations of buses at each time stamp, station information (e.g., station locations, station names), and occupancy information for each bus. Thus, when the client device 170 requests the terse table to update the GUI after a specific interval such as five minutes, the client device 170 may request only data related to updated location defining the bus and updated occupancy information of the bus without requesting the terse table including data defining the route and stop information of the bus.

Client device 170 is an electronic device used by a user to perform functions such as querying transportation information, consuming digital content, executing software applications, browsing websites hosted by web servers on network 150, downloading files, and interacting with server 110. In one embodiment, the client device 170 may also have templates defined for applications rendering visualizations to users and stored locally. Alternatively, the client device 170 may select data from the server 110 and pull templates. Still further, the server 110 includes definable templates in the terse table for pulling by the client device 170 rather than processing the raw data in real time.

The client device 170 may be a dedicated electronic Reader (e-Reader), a smart phone or tablet, laptop, notebook or desktop computer. The client device 170 includes and/or interacts with a display device on which a user may view a visualization, such as a Graphical User Interface (GUI) showing transport information. In addition, the client device 170 provides a User Interface (UI) such as physical and/or on-screen buttons with which a user may interact with the client device 170 to perform functions such as: tapping elements (e.g., bus stop tags, train stop tags, etc.), the name of the input station or site, selecting a bus or subway line, zooming in and/or out of the shipping map, and any other possible interactions.

In one embodiment, the client device 170 includes a table processing module 175 and a visualization module 177, but other embodiments of the map server 110 include different and/or additional components. In addition, functionality may be distributed among components in a different manner than described herein.

The table processing module 175 requests and combines the terse tables to generate application data (e.g., visualization data for rendering a visualization) for implementing the application on the client device 170. The table processing module 175 may include optimized source code in Javascript. In one embodiment, the table processing module 175 determines a dataset for an application that implements visualization, such as rendering on the client device 170. For example, to render a map showing a plurality of bus route conditions, the table processing module 175 determines that data for visualization of bus route paths needs to be defined. The table processing module 175 determines that it is also necessary to define visual data for occupancy of each bus and waiting time of each station. The above-mentioned visualized data defining each characteristic (e.g., path, occupancy, and latency) of the map may describe the color, size, shape, location on the map, etc. of each characteristic. For example, the data designates the latency as stripes having different lengths to indicate different latencies. In particular, the length of the strip may be proportional to the length of the waiting time. In another example, the data designates different paths of the bus line as different colors.

In one embodiment, the table processing module 175 determines a subset of data for implementing an application such as rendering a visualization on the client device 170. For example, the table processing module 175 determines the minimum data set necessary to render the visualization, such as a GUI displaying occupancy of multiple bus lines. Assume that based on the previous request, the table processing module 175 has received a compact table including data for rendering a map showing occupancy of the bus line, such as ten minutes ago. The table processing module 175 stores the received compact table locally in the client device 170. Thus, the table processing module 175 determines what is updated within 10 minutes and then determines the minimum necessary data for rendering the updated occupancy information. In one embodiment, the table processing module 175 periodically deletes expired data, such as data for three months or older.

In one embodiment, the table processing module 175 receives the requested terse table or portion of the terse table from the server 110 and combines the terse table or portion of the terse table with an existing terse table on the client device 170 to generate data for implementing the application on the client device 170. For example, the table processing module 175 combines portions of the compact table with entries previously stored on the client device 170 to generate data for rendering the visualization. The table processing module 175 may combine tables or table entries based on its common authentication information. For example, a first entry describes a site occupancy and includes variables of site Identification (ID), time, and occupancy; the second entry describes site information and includes variables of site ID, site name, and time. The table processing module 175 is able to combine these two entries based on the common variable it owns (i.e., site ID).

The visualization module 177 renders visualizations based on the data generated by the table processing module 175. For example, the visualization module 177 renders a GUI displaying occupancy information for a plurality of subway lines using the merged data from the terse tables. In one embodiment, the visualization module 177 uses a compact and descriptive syntax for the generic visualization based on the graphical syntax. In addition, the visualization module 177 uses extended graphics syntax to support interactions, animations and controls. Visualization module 177 is optimized for modern browsers that use Scalable Vector Graphics (SVG) and Canvas. Similar to the table processing module 175, the visualization module 177 can include optimized source code in Javascript.

For one example embodiment, assume that three terse tables have been stored in database 130. The first is a bus location table: bus location (bus id, path id, station id, timestamp, occupancy) and has 100,000 records, each of size five units. The second is the bus path table: bus route (route id, route name, route code) and has 100 records, each of which is three units in size. The third is a bus stop table: bus stops (stop id, stop name, stop position (latitude, longitude)) and have 1000 records, each of which is four units in size. In order to generate a visualization of a GUI such as information showing all buses and buses on a map throughout the day, a record involving a path name, a path code, a station name, a station location (latitude, longitude) is required. Therefore, a multi-table addition of a bus location table, a bus path table, and a bus stop table is required, resulting in 100,000 records, each of which is 10 units in size. The present system 100 avoids transmitting 1000,000 units (i.e., 100,000x10) of data from the server 110 to the client device 170 when rendering the GUI on the client device 170, which may cause delays due to the huge amount of data that needs to be transmitted. Instead, the server 110 sends only three terse tables to the client device 170, involving a total data size of 504,300 units (i.e., 100,00×5+100×3+1000×4). Thus, by sending the raw terse tables from the server 110 to the client device 170, and having the client device 170 process the terse tables (such as the combined terse tables), the system 100 saves about 50% of the data traffic. Further, many different data records required typically rely on the same terse table, and thus there may be higher savings.

The network 150 enables communication between the storage server 110, the client devices 170, and the es160 and may include the internet. In one embodiment, network 150 uses standard communication techniques and/or protocols. In another embodiment, the items may use custom and/or proprietary data communication techniques in lieu of or in addition to the aforementioned techniques.

Computing machine architecture

Reference is now made to fig. 2, which is a block diagram illustrating components of an example machine capable of reading instructions (e.g., software or program code) from a machine-readable medium and executing the code in a processor (or controller) to act as a client device 170 and/or map server 110, according to one embodiment. In particular, FIG. 2 shows a diagrammatic representation of a machine in the example form of a computer system 200 within which instructions 224 (e.g., software or program code) for causing the machine to perform any one or more of the methodologies described herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in server-client network environments, or as a peer machine in peer-to-peer (or distributed) network environments.

The machine may be a server computer, a client computer, a Personal Computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions 224 (sequential or otherwise) that specify actions to be taken by that machine. Further, when only a single machine is illustrated, the term "machine" shall also be taken to include any combination of machines that individually or jointly execute instructions 224 to perform any one or more of the methodologies discussed herein.

The example computer system 200 includes one or more processors (generally, processor 202) (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), one or more Application Specific Integrated Circuits (ASICs), one or more Radio Frequency Integrated Circuits (RFICs), or any combination thereof), a main memory 204, a static memory 206, which are configured to communicate with each other via a bus 208. The computer system 200 may further include a graphic display unit 210 (e.g., a Plasma Display Panel (PDP), a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)). Computer system 200 may also include an alphanumeric input device 212 (e.g., a keyboard), a cursor control device 214 (e.g., a mouse, trackball, joystick, motion sensor, or other pointing device), a storage unit 216, a signal generation device 218 (e.g., a speaker), and a network interface device 220, which are also configured to communicate via bus 208.

The storage unit 216 includes a machine-readable medium 222 on which are stored instructions 224 embodying any one or more of the methodologies or functions described herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204 or within the processor 202 (e.g., within a processor's cache memory) during execution thereof by the computer system 200, the main memory 204 and the processor 202 also constituting machine-readable media. The instructions 224 (e.g., software) may be transmitted or received over a network 226 via the network interface device 220.

While the machine-readable medium 222 is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that are capable of storing the instructions (e.g., instructions 224). The term "machine-readable medium" shall also be taken to include any medium that is capable of storing instructions (e.g., instructions 224) for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term "machine-readable medium" includes, but is not limited to, data warehouses in the form of solid state memory, optical media, and magnetic media.

Example method

Turning now to fig. 3, fig. 3 is a flow diagram illustrating an example method for providing a terse table, according to one embodiment. Fig. 3 attributes the steps of the method to the record processing module 115 of the server 110. However, some or all of these steps may be performed by other entities. In addition, some embodiments may perform these steps in parallel, perform the steps in a different order, or perform different steps. Additionally, note that in one example embodiment, the steps and/or modules may be implemented as instructions (e.g., 224) that may be executed by the processor 202 described with respect to fig. 2.

Initially, at 310, the record processing module 115 collects raw data from various sources, which as described with respect to fig. 1, may include records collected from public transportation systems such as bus line systems, train systems, subway line systems, and the like. At 320, the record processing module 115 analyzes the collected raw data to generate processed data. For example, the record processing module 115 analyzes the records to estimate motion, latency, and occupancy for each bus, train, or subway line.

At step 330, the record processing module 115 generates a compact table based on the processed data. As previously described with respect to fig. 1, the record processing module 115 extracts information based on the processed data and stores the extracted information in a compact table of the database 130. For example, the record processing module 175 generates a terse table for bus locations, and the terse table includes five columns such as bus ID, path ID, station ID, time stamp, and occupancy. The terse table may include 100,000 entries, each of five units in size.

At step 340, the record processing module 115 receives a request from the client device 170. For example, the client device 170 requests a terse table having a path name, a path code, a station name, and a station location as entries. At step 350, the record processing module 115 retrieves the terse table in response to the request. At step 360, the record processing module 115 provides the terse table to the client device 170. For example, the record processing module 115 sends the terse table to the client device 170 without any processing of the terse table, such as merging the terse table.

FIG. 4 is a flowchart illustrating an example method for implementing an application, such as rendering a visualization on a client device 170, in accordance with one embodiment. Fig. 4 attributes the steps of the method to a table processing module 175 and/or a visualization module 177 of the client device 170. However, some or all of these steps may be performed by other entities. In addition, some embodiments may perform the steps in parallel, perform the steps in a different order, or perform different steps.

Initially, at 410, the table processing module 175 determines a subset of data for implementing an application, such as rendering a visualization. As previously described with respect to fig. 1, to render a GUI showing all buses on a map throughout the day, the table processing module 175 determines that information for route names, route codes, station names, and station locations is required. In one embodiment, table processing module 175 may detect that data describing a path name and path code has been requested due to a previous action and has been stored locally at client device 170. Thus, the table processing module 175 determines that only data describing the station name and station location is needed. At 420, table processing module 175 sends a request for the subset of data to server 110. For example, the table processing module 175 sends a request to the server 110 for data describing the station name and station location.

At step 430, the table processing module 175 receives a compact table for the subset of data from the server 110. For example, the table processing module 175 receives a terse table describing a bus stop, and the terse table has data of a stop ID, a stop name, and a position. At step 440, the table processing module 175 combines the received terse tables to expand the data for implementing the application. For example, the table processing module 175 combines a compact table describing bus stops with previously stored data describing route names and route codes to extend the data necessary to render a GUI showing all buses on a map throughout the day.

At step 450, the visualization module 177 implements the application on the client device 170. For example, the visualization module 177 renders a GUI on the client device 170 showing all buses on the map during the day based on the data.

Example user interface

Referring now to fig. 5-11, example graphical representations for Graphical User Interfaces (GUIs) displaying different visualizations are illustrated. For example, the GUI is generated by the visualization module 177 of the client device 170. Fig. 5 illustrates a GUI 500 showing overall traffic conditions for a train system. For example, the train system includes four train lines. GUI 500 of fig. 5 displays paths for four train lines. GUI 500 also shows the train location per line at each time, the occupancy status of each train, the number of passengers waiting at each station, and the estimated wait time at each station. For example, the record processing module 115 on the server 110 collects records including records collected by public transportation systems and generates processed data based on the raw data. The record processing module 115 then extracts information from the processed data to generate a compact table that includes elements or properties for rendering a GUI, such as GUI 500. When a user of the client device 170 requests a GUI, such as GUI 500, the client device 170 pulls the necessary one or more terse tables from the server 110 and combines the terse tables to render the GUI 500 to the user.

Fig. 6 illustrates graphs 610 and 620 showing the number of people missing a train. For example, chart 610 shows the number of people who have been shifted from 6:00am to 00:00am, from zero shift trains, one shift trains, two shift trains, three shift trains, and four or more shift trains during the day. To display exemplary statistics, the chart 610 also includes a list 615 describing the number of people who have missed a shift train, a two shift train, a three shift train, and four or more shift trains during the 8:15am to 8:30am period. For example, the number of people missing trains in a day may be calculated by the record processing module 175 based on the raw data and stored in a compact table. The client device 170 may pull the terse table and combine the terse table to render a visualization such as the chart 610. Graph 620 shows the number of people who have missed a shift train, a two shift train, a three shift train, and four or more shift trains during the 8:15am to 8:30am period from 1 month 5 days to 3 months 25 days. The chart 620 also includes a list 625 describing the number of people who have missed a shift train, a two shift train, a three shift train, and four or more shift trains during the period of 8:15am to 8:30am on day 3 months 7. Similarly, the number of trains missed from 1 month 5 to 3 months 25 days may be calculated by the record processing module 175 based on the raw data and stored in a compact table. The client device 170 may pull the terse table and combine the terse table to render a visualization such as the chart 620.

Fig. 7 illustrates a visualization 700 showing bus route paths and bus locations. The visualization 700 also displays occupancy of each bus. By the record processing module 115, data describing the route of the bus route, the bus location and occupancy of each bus is extracted and stored in a compact table of the database 130. Client device 170 requests and receives a terse table for rendering visualization 700.

Fig. 8 illustrates

graphs

810 and 820 associated with a particular bus route. For example, chart 810 shows the number of passengers waiting and getting off at each station. Graph 820 shows the average waiting time for that particular bus line during the 6:00am to 00:00am period. The number of passengers waiting and getting off at each station is calculated and stored in a compact table. The client device 170 pulls the raw terse table from the server side and processes the terse table locally to render the chart 810. Additionally, the average waiting time during 6:00am to 00:00am for this particular bus route may be presented in the same manner in graph 820.

Fig. 9 illustrates a visualization 900 showing a view of a bus line system including a plurality of bus lines. Similar to the process described with reference to fig. 5, data describing the route of the bus route, the bus location, and occupancy of each bus is extracted by the record processing module 115 and stored in a compact table in the database 130. Client device 170 requests and receives a terse table for rendering visualization 900.

FIG. 10 illustrates a graph 1000 showing the latency of one month during 8:00AM to 8:15 AM. For example, the latency during 8:00am to 8:15am is calculated and stored in a compact table. The client device 170 pulls the raw compact table from the server side and processes the compact table locally to render the chart 1000.

Fig. 11 illustrates a visualization 1100 showing the outbound commuter flow on a map. In one embodiment, the likely job locations and occupancy locations of passengers using the transportation system may be estimated based on commuter flows. Statistics summarizing commuter experiences may be obtained from the results of the reconstruction module 115 based on collected trip records and/or fleet (sheet) data. The client device 170 requests and receives reconstructed data for rendering the chart 1100.

Additional configuration considerations

Thus, as previously described, the system and method for rapid visual rendering provides a number of advantages over conventional models. For example, the systems and methods allow for faster communications between the server 110 and the client device 170, and thus reduce communication latency. This is particularly helpful for interactive and real-time visualization. In addition, the system and method enable a substantial reduction in the size of data sent at the server 110, such as in applications where the processed data is highly dependent on certain general-purpose data. Further, local caching and processing makes the system suitable for offline use as well. In addition, the system and method enable fast and real-time interaction with large data sets by using simple data chunk logic and handling all processing at the client device 170.

Throughout this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the subject matter herein.

Specific embodiments are described herein as comprising logic or multiple components, modules, or mechanisms. The modules may constitute software modules (e.g., code embedded on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. In example embodiments, one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware modules of a computer system (e.g., a processor or group of processors, such as processor 202) may be configured by software (e.g., an application or portion of an application) as a hardware module that operates to perform particular operations as described herein.

In various embodiments, the hardware modules may be implemented mechanically or electronically. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor such as a field programmable gate sequence (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., as included within a general purpose processor or other programmable processor) that is temporarily configured by software (or program code) to perform particular operations. It will be appreciated that decisions made to mechanically implement the hardware modules in dedicated and permanently configured circuits, or in temporarily configured circuits (e.g., configured by software or program code) may be driven by cost and time considerations.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors (e.g., processor 202), which are temporarily configured (e.g., by software) or permanently configured to perform related operations. Such processors, whether temporarily configured or permanently configured, may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may comprise processor-implemented modules in some example embodiments.

The one or more processors may also be operative to support related operations executing in a "cloud computing" environment or as a "software as a service (software as a service)" (SaaS). For example, at least a portion of the operations may be performed by a group of computers (e.g., a machine including processor 202), which may be accessed via a network (e.g., the internet) and via one or more suitable interfaces (e.g., application Programming Interfaces (APIs)).

The performance of certain operations may be distributed among one or more processors (e.g., processor 202), not only within a single machine, but also deployed across multiple machines. In some example embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., a home environment, an office environment, or a server bank). In other example embodiments, one or more processors or processor-implemented modules may be distributed across multiple geographic locations.

Portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., computer memory). These algorithms or symbolic representations are examples of techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an "algorithm" is a self-consistent operation or similar processed sequence leading to a desired result. In this context, algorithms and operations involve physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, and otherwise manipulated by a machine. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as "data," "content," "bits," "values," "elements," "symbols," "characteristics," "terms," "numbers," or the like. However, these terms are merely provided as convenient labels and are associated with appropriate physical quantities.

Unless specifically stated otherwise, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "presenting," "displaying," or the like, herein refer to the action and processes of a machine (e.g., a computer) that manipulates and transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within the machine's storage(s) (e.g., volatile memory, non-volatile memory, or combinations thereof), registers or other machine components that are used to store, communicate or display information.

Reference herein to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Some embodiments may be described using the expression "coupled" or "connected" along with their derivatives. For example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact. However, the term "coupled" may mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.

As used herein, the terms "include," "have," or other variants thereof are intended to mean non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless explicitly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, the condition a or B is satisfied by any one of the following: a is true (or present) and B is false (absent), a is false (absent) and B is true (or present), or both a and B are true (or present).

In addition, the use of "a" and "an" is used to describe elements and components of embodiments herein. This is for convenience and to give a general sense of the invention only. The description should be understood to include one or at least one, and the singular also includes the plural unless it is obvious that it is meant otherwise.

Those skilled in the art will appreciate, upon reading this disclosure, that there remain additional alternative structural or functional designs for the system and process of rapid visual rendering. Thus, although specific embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise arrangements and instrumentalities disclosed herein. It will be apparent to those skilled in the art that various modifications, changes and variations can be made in the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A computer-implemented method for fast visual rendering, comprising:

determining, using a processor, a dataset required for rendering a visualization of public transportation information on a client device, the dataset comprising at least one of location, name, identifier, occupancy, and time and describing movement of a plurality of transportation means, and the visualization presenting a graphical representation of traffic conditions associated with the plurality of transportation means, i.e. movement of individual transportation means, and the dataset also describing estimated wait times for each transportation line at each station or site;

transmitting a request for the dataset to a server computer;

receiving, at the client device, a plurality of terse tables corresponding to the data set from the server computer in response to the transmitted request, each of the plurality of terse tables storing (i) identification information and (ii) data indicative of occupancy and/or time parameters for a vehicle or station/site as respective data portions for rendering the visualization;

generating, at the client device, the data set by combining the received plurality of terse tables based on common identification information; and

Based on the dataset, a visualization of the public transportation information is rendered on the client device.

2. The method of claim 1, wherein the received plurality of terse tables are a subset of required data for rendering the visualization on the client device.

3. The method of claim 2, wherein combining the received plurality of terse tables comprises:

the received plurality of terse tables is combined with one or more other terse tables present on the client device.

4. The method of claim 3, wherein combining the received plurality of terse tables with one or more other terse tables present on the client device is based on common data between the received plurality of terse tables and the one or more other terse tables present on the client device.

5. The method of claim 1, further comprising:

storing the received plurality of terse tables; and

periodically delete expired terse tables.

6. The method of claim 1, wherein rendering the visualization of the public transportation information includes rendering bars having different lengths to indicate different waiting times.

7. The method of claim 1, wherein generating the dataset by combining the received plurality of terse tables at the client device results in the dataset being greater than about 50% of a combined size of the received plurality of terse tables.

8. The method of claim 1, further comprising:

only entries relating to data defining update occupancy of the vehicle are requested after a certain interval.

9. A computer-readable medium storing instructions that, when executed by a processor, cause the processor to:

based on the user input, determining a dataset required for rendering a visualization of public transportation information on the client device, the dataset comprising at least one of location, name, identifier, occupancy, and time and describing movement of a plurality of vehicles, and the visualization presenting a graphical representation of traffic conditions associated with the plurality of vehicles, i.e., movement of individual vehicles, and the dataset also describing estimated wait times for each traffic line at each station or site;

transmitting a request for the dataset to a server computer;

10. The computer-readable medium of claim 9, wherein the received plurality of terse tables are a subset of required data for rendering the visualization on the client device.

11. The computer-readable medium of claim 10, wherein combining the received plurality of terse tables comprises:

12. The computer-readable medium of claim 11, wherein combining the received plurality of terse tables with one or more other terse tables present on the client device is based on common data between the received plurality of terse tables and the one or more other terse tables present on the client device.

13. The computer-readable medium of claim 9, wherein the instructions further cause the processor to:

Storing the received plurality of terse tables; and

periodically delete expired terse tables.

14. The computer-readable medium of claim 9, wherein rendering the visualization of the public transportation information includes rendering bars having different lengths to indicate different waiting times.

15. A system for rapid visual rendering, comprising:

a memory storing instructions for a visualization module; and

a processor configured to execute the instructions to:

transmitting a request for the dataset to a server computer;