Patent Application
20140280319
A Geographic Information System (GIS) captures, stores, analyzes, manages, and presents data linked to geographic locations. Example GISs include Google Earth™, ArcGIS® from ESRI, and commercial fleet management services.
In general, a GIS presents tools for users to query and make decisions based on geographic information. The geographic information may be spatial and temporal; and is often heterogeneous, from divergent sources, and may contain structured and unstructured data. As a result, the processing of this data becomes complex and involves numerous challenges. For example, the use of multiple, disparate tools are often necessary in order to process and analyze geospatial data in real-time. These tools are often expensive and can require specialized skills and training to use. In addition, each tool may require the data to be in different formats, increasing the difficulty in combining heterogeneous types of data.
Another challenge associated with current commercial systems is that much of the information currently stored in these systems is either historical or static in nature. While this is acceptable for visualizing data such as road-maps, and even handling a single moving object, such as in global positioning system (GPS) navigation where a moving vehicle is the only dynamic object represented, there exists a gap in presenting and handling the dynamic information associated with moving objects in the surrounding environment having different locations, speeds, shapes and trajectories.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Certain embodiments provide a GIS system that leverages video streaming sensor nodes and presents the dynamic information associated with moving objects in a manner that can be used across a variety of clients. In addition, techniques are discussed for minimizing bandwidth issues.
An application programming interface (API) is provided in which clients may access and use dynamic information associated with moving objects in a surrounding environment.
An application programming interface (API) for a Geographic Information System (GIS) is disclosed. The API enables clients to perform visual querying and rendering.
Querying, analysis, and visualization of real-time data pertaining to at least two moving objects in conjunction with relatively static multi-temporal geospatial data can be facilitated on client devices through the presentation of the API.
A GIS server, that may provide a GIS service including the API, can incorporate data from mobile video sensors and streaming technologies in order to present streaming and/or video data.
In certain embodiments, the GIS server can perform the step of processing and analyzing geographic, spatial and/or temporal data to provide visual representation of the trajectories of relevant objects, which may be known to the server in advance or transmitted in real time, sampled, and have uncertainty aspects.
Geographic data exploration can be enhanced through incorporation of moving objects. For example, at the client, moving objects of a specific area of interest may be viewed overlaid on geospatial data. According to embodiments of the invention, dynamic movement of objects within the geographic area and at specific resolutions of interest can be presented. This translates to the user as a real-world experience with objects moving across their screen or “zooming” by them.
User scenarios that may be supported include, but are not limited to: (1) the user is on board a moving object whose trajectory (e.g., location as a function of time) is known a priori to the server; (2) the user is on board a moving object whose trajectory is generated in real-time and received by the server; or (3) the user is located at a fixed point.
Likewise, the trajectories of relevant objects may be known to the server in advance or received by the server in real time and sampled. Visual querying and rendering can be provided to the client.
The network 115 can include, but is not limited to, a cellular network (e.g., wireless phone), a point-to-point dial up connection, a satellite network, the Internet, a local area network (LAN), a wide area network (WAN), a WiFi network, an ad hoc network or a combination thereof. Such networks are widely used to connect various types of network elements, such as hubs, bridges, routers, switches, servers, and gateways. The network 115 may include one or more connected networks (e.g., a multi-network environment) including public networks, such as the Internet, and/or private networks such as a secure enterprise private network. Access to the network 115 may be provided via one or more wired or wireless access networks as will be understood by those skilled in the art.
The client device 105 may be, but is not limited to, a personal computer (e.g. desktop computer), laptop, personal digital assistant (PDA), mobile phone (or smart phone), tablet, slate, terminal, or set-top box.
The GIS server 110 may include distributed servers that execute real-time continuous queries to facilitate rendering and collaborating with vehicular ad-hoc networks (VANets) 120 and other video streaming sources. For example, a mobile sensor (e.g., on a drone aircraft or even a smart phone) with geo-positioning and communication capabilities and a camera can capture vehicles and pedestrians that are in line of sight and/or a stationary sensor with communication capabilities and a camera can be installed at geographically distributed locations such as at a traffic light, and these videos and/or images be communicated over a network, and ultimately collected by the GIS server 110.
The GIS server 110 may include one or more computing devices. For example, the GIS server 110 can include one or more blade server devices, standalone server devices, personal computers, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, network-attached storage devices, and other types of computing devices.
In embodiments where the GIS server 110 includes multiple computing devices, the server can include one or more communications networks that facilitate communication among the computing devices.
For example, the one or more communications networks can include a local or wide area network that facilitates communication among the computing devices. One or more direct communication links can be included between the computing devices. In addition, in some cases, the computing devices can be installed at geographically distributed locations. In other cases, the multiple computing devices can be installed at a single geographic location, such as a server farm or an office. Certain embodiments of the invention can be practiced in distributed-computing environments where tasks are performed by remote-processing devices that are linked through a communications network. In a distributed-computing environment, program modules can be located in both local and remote computer-readable storage media.
The GIS server 110 can also access multiple geographic information sources 130 for static and/or dynamic geographic information. Once the results from the information sources are received by the GIS server 110, the GIS server can perform steps of filtering and formatting the results; storing the results in a database, transforming the results into a visual representation, and/or transmitting the results in a form to client devices.
The client device 105 can communicate with the GIS server 110 to obtain visual data and information on relevant moving objects based on criteria submitted by a user of the client device 105.
To allow ergonomic formulation of queries, a user interface can be provided in a web browser of the client device 105 in which the end-user will be provided the ability to graphically manipulate objects and navigation examples. The presented data about the object can include the object's existing and computed properties, including location, description, context, and personalization. This query pattern adds information retrieval and database selection-like constraints to traditional spatio-temporal queries. Such constraints give users the flexibility to execute free-text searches (information-retrieval style) on unstructured data, or refined attribute-based predicate retrieval (SQL style) on structured data. For example: “visualize the trajectories of large green trucks near the current point” is a query where “green” is a keyword, “truck” is a category, and “large” translates into a numerical predicate.
Certain embodiments provide support for requests to the GIS server 110 from the client that include functions for opening historic movement trajectories, getting live movement trajectories from the server, getting a video player (or a view of a player) to play videos captured on a given trajectory, and getting movement trajectory inside a search window that a user is interested in.
An API method for performing these functions is disclosed. The GIS services API involves a set of request messages available to a client 105 (or server) along with a definition of the structure of response messages sent to the client (or server). The response messages from the GIS 110 server to the client 105 may be in a markup language such as Extensible Markup Language (XML) or JavaScript Object Notation (JSON). The GIS services provided by GIS server 110 can interact programmatically over the network through industry standard Web protocols, such as, but not limited to, XML, JSON, Hypertext Transfer Protocol (HTTP) Representational State Transfer (REST), and Simple Object Access Protocol (SOAP).
According to certain embodiments of the invention, API functions that may be called by the client 150 include:
The search window is described by a series of points in latitudes and longitudes bounding the area that the user is interested in.
When the API/GIS server receives the incoming message, the API/GIS server determines whether the incoming message includes a historic traces request “getHistoricTraces” (202). If the incoming message includes the historic traces request (“Yes” of 204), the API/GIS server may get some or all historic traces and sends response back to client (204). The server may get this information from a database.
The API/GIS server also determines whether the incoming message includes a live traces request “getLiveTraces” (206). If the incoming message includes the live traces request (“Yes” of 206), the API/GIS server may get some or all live traces and sends response back to client (208). The server may get this information from at least one sensor having a camera.
The API/GIS server also determines whether the incoming message includes a video player request “openPlayer” (210). If the incoming message includes the open player request (“Yes” of 210), the API/GIS server may open the video player in the portal (e.g., user interface of client browser) and may stream video to client (212).
The API/GIS server also determines whether the incoming message includes a get movement trajectory request “openSearchWindowWithPolygon” (214). If the incoming message includes the get movement trajectory request (“Yes” of 214), the API/GIS server may get the traces located within the search window back to client (216). Information about the specific trajectory may be obtained from at least one sensor having a camera within a geographic region associated with the search window or from information associated with the search window that is stored in a database.
An example of a SOAP request for “getHistoricTraces” is as follows:
An example of a SOAP request for “openPlayer”, which shows an argument for a streaming video channel, is as follows:
A user interface can be provided in which a map is displayed as part of a geographical visualization view of a region. When a user selects an object (such as one of the moving objects) displayed in the geographical visualization view in order to see its video, the user interface can request the video from the GIS server using, for example, the openPlayer request. Once the client receives the streaming video captured by the sensor corresponding to the selected object, the user interface can present a video player in the portal to show the video stream. While watching the video stream, the user can interact with the video player, resulting in changes to the geographical visualization view of the region. For example, the user may manually shift a time pointer in the video stream being watched in the player. In response to receiving this input, the interface can reposition the moving object on the map. In some embodiments, a polygonal projection of the sensor's view to earth surface can be provided as part of the visualization and synchronized with the playback of the video player.
In some implementations, the client can request “getHistoricTraces” and “getLiveTraces” at regular intervals, for example, every second. For each request, the server may return an XML formatted file that contains the name of the movement trajectories and the coordinates of the points of the trajectories. The client may draw these trajectories on the map within a user interface and list them in a Trajectory Control panel provided to the client. In one implementation, related streaming videos that lie on the trajectory path can be displayed in response to receiving an input command, such as a right click by a mouse connected to the client device or by a touch or other gesture of a touchscreen of the client device, on the trajectory path itself. A pop-up window can be displayed with the option of “Open Player” that, if selected, would proceed to send a request for the streaming video to the server and open a window to view that video.
In some implementations, trajectory paths may be drawn in a manner to minimize unnecessarily obscuring other elements on the screen, for example as a thin red line. This, however, can make it more difficult for users to be able to select the trajectory path itself. To mitigate this and help users to select on the trajectory paths, an invisible buffer can be placed around the trajectory path lines that when an input indicating a selection is received on the invisible buffer, it is understood to be a selection of the trajectory path itself. Thus, the trajectory paths can be displayed with minimal disruption to the geographic visualization while still maintaining the ability to select the line for a second action. The user interface can include markers to tag the movement trajectories on the map in case the trajectories are too small to be seen from global view. The Trajectory Path Control panel can list available movement trajectories returned from the server in response to one of the requests for getting trajectories. When a trajectory is selected in the Trajectory Path Control panel, the view of the trajectory path from the perspective of an object along the trajectory path can be provided (e.g., representing a scenario where a user is on board the moving object).
In certain embodiments, client-server bandwidth can be optimized. In one embodiment, the client can periodically consult the server for moving objects instead of using a constant stream of data. The rate of checking for moving objects and the number of moving objects will influence the bandwidth required. Algorithms that deal with time- and speed-based stream predictions and collision detection can be used to minimize the number of checks to the server and the number of objects consulted. To optimize client-server bandwidth, objects that are moving slowly in the viewable window (indicating that they are far away), can be checked for updates less often. Objects that are close or moving at a fast pace are checked more frequently. Also, objects that are not travelling on a collision course with the client's viewable window can be ignored altogether. Of course, if a change of direction is detected, the collision course can be re-evaluated.
In certain embodiments, the future location of a moving object is predicted for obtaining visual results of moving objects (positions) to optimize client-server bandwidth. Location prediction refers to statistical methods that derive patterns or mathematical formulas whose purpose is, given the recent trajectory of a moving object, to predict its future location. In one related embodiment, sensor data streams are queried, wherein each update from a sensor is associated with a function allowing prediction of future values of that sensor. The sensor commits to update its value whenever the difference between the observed value and the value estimated using the prediction function exceeds a certain threshold. Location prediction enables selective transfer of moving objects' data from the server to the client. More specifically, moving objects whose locations are predicted to be viewable will be transferred, whereas other moving objects' data will not, to optimize client-server bandwidth.
The subject systems and methods can be used in a wide variety of applications and settings including, but not limited to, weather monitoring, troop dispatching, endangered species tracking, disaster mitigation, general aviation monitoring, fleet management, transportation and highway patrol problems, traffic analysis and visualization, commanding and controlling mobile sensors; commanding and controlling operations (e.g., homeland security, law enforcement and disaster response).
In one embodiment, the system and method of the invention enables situational monitoring by law enforcement (e.g., notice is provided to law enforcement regarding a hit and run accident). In a specific embodiment, video surveillance recordings, which are used in specific locations, are accessed in real time and integrated with other forms of critical information (e.g., airborne and vehicle-borne sensors). By way of example, law enforcement officers would be able to use the invention to quickly pin point the geographic location, view streaming media of the current location to quickly assess the situation, and, through the use of additional sensors, track the offender's vehicle.
Certain techniques set forth herein may be described or implemented in the general context of computer-executable instructions, such as program modules, executed by one or more computing devices. Generally, program modules include routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.
Embodiments may be implemented as a computer process, a computing system, or as an article of manufacture, such as a computer program product or computer-readable medium. Certain methods and processes described herein can be embodied as code and/or data, which may be stored on one or more computer-readable media. Certain embodiments of the invention contemplate the use of a machine in the form of a computer system within which a set of instructions, when executed, can cause the system to perform any one or more of the methodologies discussed above. Certain computer program products may be one or more computer-readable storage media readable by a computer system and encoding a computer program of instructions for executing a computer process.
Computer-readable media can be any available computer-readable storage media or communication media that can be accessed by the computer system.
Communication media include the mechanisms by which a communication signal containing, for example, computer-readable instructions, data structures, program modules, or other data, is transmitted from one system to another system. The communication media can include guided transmission media, such as cables and wires (e.g., fiber optic, coaxial, and the like), and wireless (unguided transmission) media, such as acoustic, electromagnetic, RF, microwave and infrared, that can propagate energy waves. Communication media, particularly carrier waves and other propagating signals that may contain data usable by a computer system, are not included as computer-readable storage media.
By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, a computer-readable storage medium includes, but is not limited to, volatile memory such as random access memories (RAM, DRAM, SRAM); and non-volatile memory such as flash memory, various read-only-memories (ROM, PROM, EPROM, EEPROM), magnetic and ferromagnetic/ferroelectric memories (MRAM, FeRAM), and magnetic and optical storage devices (hard drives, magnetic tape, CDs, DVDs); or other media now known or later developed that is capable of storing computer-readable information/data for use by a computer system. “Computer-readable storage media” do not consist of carrier waves or propagating signals.
In addition, the methods and processes described herein can be implemented in hardware modules. For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), and other programmable logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.
Any reference in this specification to “one embodiment,” “an embodiment,” “example embodiment,” etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment. In addition, any elements or limitations of any invention or embodiment thereof disclosed herein can be combined with any and/or all other elements or limitations (individually or in any combination) or any other invention or embodiment thereof disclosed herein, and all such combinations are contemplated with the scope of the invention without limitation thereto.
It should be understood that the examples and embodiments described herein are for illustrative purposes only and that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application.
The present application claims the benefit of U.S. Provisional Application Ser. No. 61/792,985, filed Mar. 15, 2013, which is hereby incorporated by reference herein in its entirety, including any figures, tables, or drawings.
This invention was made with government support under Award Number HRD-0833093 awarded by the National Science Foundation. The government has certain rights in the invention.
| Number | Date | Country | |
|---|---|---|---|
| 61792985 | Mar 2013 | US |
