AVIATION VIRTUAL SURFACE

SYSTEMS AND METHODS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/316,175, filed March 31 , 2016, and makes a claim of priority thereto. The entire contents of U.S. Provisional Application No. 62/316,175 are hereby incorporated by reference as if fully recited herein.

TECHNICAL FIELD [0002] Exemplary system and method embodiments described herein are directed generally to facilitating the various required functions of the aviation industry, and more particularly, systems and methods directed towards models and visual representations of risk, data consilience and other attributes associated with geospatial information.

BACKGROUND

[0003] While air travel may seem simple from the perspective of an average passenger, this is actually far from the case. In reality, the business of aviation, both commercial and private, has many complicated aspects that need to properly interact in order to convey the aura of a seamless system. These aspects include, without limitation, airport and air traffic management, flight planning, flight operations engineering, emergency management, aircraft maintenance, and industry (e.g., government) regulation.

[0004] From an infrastructure standpoint, airports generally serve as the mechanism by which aircraft and passengers are able to transit from one location to another. That is, airports receive passengers, serve as the conduit by which passengers connect with the various airline operators, and serve as the point of arrival and departure for airline and private aircraft on a daily basis. Airports are not constructed without substantial forethought and planning, which includes consideration of who and what type of aircraft are likely to use a given airport, as well as how airport operations will and might be someday affected by the surrounding area and surrounding structures. Nor are existing airports or their surrounding areas static in nature - rather, existing airports typically undergo temporary and/or permanent changes that affect the users of said airports. Similarly, the areas surrounding airports may change dramatically over time, whether as a result of human progress or of nature.

[0005] Airport and surrounding area information needs to be made available to operators of aircraft and other affected parties. Likewise, changes to airport information or to surrounding area information also needs to be made available or, more desirably, needs to be pushed to operators of aircraft and other affected or relevant parties to ensure that said parties are always using the most current information available. This dissemination of information may occur using a number of models including but not limited to publish/subscribe, download, socket relay, polling or other methods. In a reverse manner, airport managers and others need to understand the operations and aircraft of the carriers and other users of their airports, whether for the purpose of communicating changes that might affect flight operations, for planning changes to better suit the future needs of those users, or otherwise.

[0006] Commercial and private airline operators and pilots, as well as private pilots and others, have a need for airport information. Airport information is critical to flight planning, not just for purposes of scheduling and general route calculation, but also for more specific purposes such as determining proper landing and takeoff procedures for given aircraft, and for emergency response planning.

[0007] It should be apparent, therefore, that changes to airport information can profoundly affect the determinations that must be made by airline operators and pilots. For example, the erection (or removal) of a tall structure within a certain vicinity of a runway may cause a corresponding change in the flight path to be followed by an aircraft during takeoff from or landing on said runway. It is also possible that a given aircraft (or class of aircraft) may no longer be able to use a runaway affected by the erection of a sufficiently tall structure. The growth of trees surrounding an airport may have a similar affect, even if on a more gradual basis. Numerous other examples of relevant changes to airport information also exist, such as without limitation, the shortening or lengthening of a runway or a change in the number or type of navigational aids present. Even temporal events near a given runway may be relevant to personnel engaged in flight planning or the actual piloting of aircraft that will use said runway.

[0008] Obstacle information is also important to flight operations and planning. Obstacles may be either man-made, such as buildings or power lines, or may be natural, such as trees and mountains. The closer obstacles are to airports and runways the higher the likelihood that their existence can interfere with flight paths and procedures. One problem encountered by the aviation industry is that it is often difficult to find a single source of trusted obstacle information for any particular airport and surrounding area. Obstacle surveys may not be performed on a regular basis, and once a few years have passed since a survey has been performed the data from the survey becomes less trustworthy, since obstacles may have changed in the interim. Other surveys are limited in geographic scope. For example, some surveys may only identify obstacles within the FAR Part 77 surface, which includes pre-defined surfaces of land and airspace that must be regulated for obstacles according to federal law. Pursuant to regulation surveys of Part 77 surfaces must include both man- made and natural objects. However, even under FAR Part 77 not every obstacle existing at the time of the survey must be identified. Depending on an obstacle's location and relative size and orientation to other obstacles it may not need to be identified. Overall, Part 77 surfaces are limited to the land and airspace that is large enough to cover takeoff, turns, and approach procedures for a particular runway. If surveys of the Part 77 surfaces are not conducted on a routine basis obstacles may perforate the surface yet not be identified by an airport. An example of this would be trees that have grown over the years, or even a new building that is close to the airport. There may also be obstacles that exist under the Part 77 surfaces that may pose an issue in the event of a non-routine approach or takeoff.

[0009] Part 77 surveys are just one type of source of information about obstacles. There are various types of data that may be analyzed to consider obstacles, including geospatial information from gov't agencies and companies such as Google, and private surveys conducted by various entities, often done by airplane or drone. Depending on the source of obstacle data, the method by which it was collected, the type of data collected, the age of the data, and other factors, certain sources may be deemed higher quality and more reliable than others. Some obstacle surveys have image data that is oversimplified and contain shadowing, which may practically "hide" significant obstacles that exist in the shadowed areas. Also, in many surveys obstacles are defined as a single point or points, and the accuracy of the points is typically a function of the surveying method. This approach fails to appreciate the actual dimensions of an obstacle.

[0010] The reality faced by many aviation professionals is that obstacle data available for an area of interest may be outdated, poor quality, or otherwise limited in quality or content. Another issue is that aviation professionals may not even be aware of the relative quality of the data they are using, the shortcomings in its geographic extent, or any risks created through the use of the data. Aviation professionals may also not even have access to all available sources of obstacle data for an area of interest.

[0011] As with airport information, pilots and other flight operations/planning personnel need access to aircraft performance information. Aircraft performance information is necessary, for example, in order to determine appropriate takeoff and departure procedures for a given runway of a given airport under any number of environmental conditions and aircraft weight and balance scenarios. Aircraft performance information is similarly important in crafting enroute emergency procedures - particularly, but not exclusively, those procedures associated with an engine out on takeoff scenario.

[0012] Surrounding all of the aforementioned aspects of the aviation industry, is regulatory compliance. As one might expect, the aviation industry is heavily regulated. In the U.S., primary regulatory responsibility falls on the Federal Aviation Administration (FAA), which is an agency of the U.S. Department of Transportation that oversees, among other areas of aviation, regulation, certification and safety. Therefore, among other functions, the FAA is involved with airport planning and development projects, as well as airport compliance; is in charge of developing and operating the U.S. air traffic control system; is responsible for the certification of aircraft and for promulgating associated safety practices, developing safety programs and issuing safety alerts; is responsible for certifying airports, airlines and aviation personnel, including pilots and maintenance personnel; and engages in rulemaking and in publishing the Federal Aviation Regulations (FAR) and other policies, guidance, advisories, notices, etc.

[0013] Because of the regulated nature of the aviation industry, it is also important that regulatory personnel have access to accurate and up to date information on airports, airlines and aircraft. Likewise, it is important that other aviation industry personnel such as airport operators, airline carriers and commercial operators, pilots, maintenance personnel, etc., have easy access to the various - and sometimes voluminous - regulatory data relevant to their job function.

[0014] From the foregoing commentary, the importance of information sharing and information access across the various aspects of the aviation industry should be apparent to one of skill in the art. Most basically, information access and information sharing are obviously important simply to ensure that all parties are working with like, and current information. Similarly, access to and notification of changes to such information is also important as it has been explained above how a change in information associated with one aspect of the aviation industry may have a significant impact on one or more other aspects. For example, the benefits associated with the use of even robust and current performance data to calculate the aircraft performance parameters of a given airport departure procedure may be severely diminished if the corresponding airport information is outdated and/or incorrect.

[0015] Problematically, however, there has heretofore been no single system and method capable of accomplishing such functions. Instead, information and changes to information associated with one aspect of the aviation industry frequently remain unknown to other aspects of the aviation industry, or dissemination of such information or changes to information otherwise takes an inordinate amount of time. [0016] In addition to the aforementioned difficulties associated with information sharing and information access, the resolution of conflicting information has also been heretofore problematic. More particularly, there has been no accepted approach or proffered technique of resolution when information from different sources conflicts regarding the same issue, object, location, or other subject matter. For example, several different data sources may disagree on the precise geographic location of a given obstacle, runway location or some other object or subject of interest and, when they do, there has been no accepted approach to resolving the conflict.

[0017] The benefit, if not need, for an interested party to have access to the various conflicting sources of information should be obvious. Likewise, a system and method for accurately resolving conflicts in aviation, aeronautical and/or geospatial information should be apparent.

[0018] Also problematically, presently known and used systems and methods for accessing, presenting and using aviation, aeronautical and geospatial information are not user friendly, and often only certain personnel are able to understand certain information due to the format and/or complexities of the information and the presentation techniques employed. Consequently, it would also be highly desirable to provide a system and method that simplifies the retrieval, presentation and use of such information in a new, more intuitive, and easy to understand and manipulate manner. There is also a particular need for a system that can provide a user with visual appreciation of obstacles and the risks associated not only with the obstacles but with reliance on one or more available data sources.

[0019] Currently known techniques for aircraft performance calculation are typically very mathematical, rather than visual, in nature. Currently known techniques for aircraft performance calculation are also typically based on, for example, runway analysis, or are otherwise not procedure based. Similarly, currently known techniques for aircraft performance calculation are typically not risk-based - that is, such techniques are not designed to present a user with the numerical and visual risks associated with the performance calculation such that a user is able to easily understand and visualize the risks associated with a given procedure, with performance, or with weight and balance decisions (i.e., to balance risk and return). Consequently, there is a need for an aircraft performance calculation system and method that is procedure-based, and that also allows a user to easily visualize the risks associated with a given procedure, with performance, or with weight and balance decisions.

[0020] Similarly, currently known techniques for flight (enroute) emergency planning can make such planning very challenging, and it has also been determined that most operators are not currently willing to perform the continued engineering analysis necessary to effectuate proper enroute emergency planning. Therefore, there is a need for a better solution for providing relevant personnel at least with visual feedback regarding the safest paths to take when experiencing an enroute emergency situation. A similar solution for providing relevant personnel with visual feedback regarding special missed approach procedures would also be desirable.

[0021] Exemplary system and method embodiments described herein solve these and other problems, and additionally offer a novel approach to the manner in which aviation, aeronautical and/or geospatial information is presented to a user.

SUMMARY [0022] Exemplary system and method embodiments described and depicted herein are directed generally to facilitating the various required functions of the aviation industry. To this end, exemplary system and method embodiments will typically have an aeronautical/geospatial database, or series of databases, containing information relating to, for example and without limitation, airports, runways, terrain and obstacles, land use, land cover, navigational aids, communications infrastructure, etc. Other system components may utilize the information from this database(s) to provide users with answers to queries relating to, for example and without limitation, airport planning and management, regulatory compliance, typical flight planning, specialized flight planning (e.g., special departure procedures), flight operations engineering (e.g., aircraft performance), and enroute emergency planning. Most if not all of the information available in the database(s) may be cloud-based, such that the information may be conveniently accessed by other system products/components or functionality via a web browser.

[0023] By providing a centralized database(s) of information relating to virtually all aspects of the aviation industry, information access and information sharing are greatly improved - which helps to ensure that all parties are working with common information. Similarly, by capturing and saving changes to information in the database(s) - often in real time - and encouraging and facilitating the uploading of changes to information and/or comments or other feedback (a.k.a. crowd-sourcing) regarding information or perceived inaccuracies in information, it can also be ensured that all parties are working with the most current information available.

[0024] Some exemplary system and method embodiments may be provided as a suite of separate but cooperating and/or interactive components. For example, and for non-limiting purposes of illustration only, an exemplary solution may include one or more of a terminal/airport-based management component, a dynamic charting component, a risk-based performance calculation component, an enroute emergency planning component, and a regulatory compliance component. Access to a given component may be controlled, for example, via license - such that license level or licensing of a particular component(s) determining what services are available to a given user.

[0025] Other exemplary system and method embodiments may be provided as a single product solution that includes all the functionality of an alternative suite of individual components. In such an embodiment, the particular functionality/services available to a given user may be determined, for example, by subscription level.

[0026] Whether embodied as a multi-product suite or a single product solution, it is contemplated that database information will be fully available, and that the products of a suite or the functional aspects of a standalone solution may interact to provide each other with information required to complete a given task. For example, and without limitation, a terminal/airport-based management component may provide obstacle information to a performance calculation component so that the performance calculation component can most accurately calculate various risk-based departure procedures for a given aircraft of interest. Obviously, a multitude of other interactions are also possible.

[0027] Exemplary system and method embodiments described herein may include a common database populated with a multitude of aeronautical and geospatial information that may be easily and conveniently retrieved, and to which like or similar information or changes to information may be easily and conveniently deposited, preferably through the use of a web browser-based application.

[0028] Exemplary embodiments described herein may include novel systems and methods of using aeronautical/geospatial information to manage the risks at and around airports.

[0029] Exemplary system and method embodiments described herein may include a visual interface for managing data quality, procedure, design and risk associated with airports and the areas surrounding airports.

[0030] Exemplary system and method embodiments described herein may facilitate the resolution of conflicts between information from different sources regarding the same subject matter (e.g., the precise geographic/geospatial location of a given obstacle, a runway location, or some other object or subject of interest, or attributes of aforementioned and other objects) at or near an airport.

[0031] Exemplary system and method embodiments described herein may utilize convergence of evidence techniques for resolving conflicts between information from different sources regarding the same subject matter.

[0032] Exemplary system and method embodiments described herein may include a modeling method for producing unique, multi-dimensional surfaces that visually represent information about an area of interest, such as a flight path around an airport, for which obstacle data is missing, incomplete, old, or otherwise in doubt.

[0033] Exemplary system and method embodiments described herein may include modeling methods to indicate through unique, multi-dimensional surfaces the relative quality and/or reliability of data used and/or the relative confidence of accuracy of values on the surface. [0034] Exemplary system and method embodiments described herein may include modeling methods to indicate through unique, multi-dimensional surfaces the degree of consilience between data provided by two or data sources containing geospatial information about an area of interest.

[0035] Exemplary system and method embodiments described herein may include modeling methods to indicate through unique, multi-dimensional surfaces the amount of risk mitigation necessary to compensate for subjective risks in one or more data sources, and create artificial terrain surfaces that indicate risk mitigation.

[0036] Exemplary system and method embodiments described herein include modeling methods to create a variety of virtual surfaces for aviation purposes that can be utilized in a variety of flight operations applications.

[0037] Exemplary system and method embodiments described herein may include a visual technique for indicating how a selected flight path will penetrate a calculated/generated virtual surface.

[0038] Exemplary system and method embodiments described herein may include a modeling method to determine and apply the effects of the age of an aeronautical survey, or level of risk, onto the source elevation.

[0039] Exemplary system and method embodiments described herein may visually present the results of risk-based decision making to a user.

[0040] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to calculate a risk score in consideration of takeoff and landing performance, and to present (numerically and/or visually) the risks associated with a given procedure, with performance, or with weight and balance decisions.

[0041] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is designed to provide procedure based performance calculations rather than performance calculations based on runway analysis.

[0042] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is designed to make aircraft performance information more visual and less mathematical. [0043] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to conduct complex flight path analyses for aircraft that do not have available 1 ^st principles information.

[0044] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to calculate and present sectorized, one engine inoperative aircraft departure procedures, which indicate different possible flight paths depending on the sector of an airport bounding area within which the aircraft is located.

[0045] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is compatible with modern web browsers, mobile devices and onboard aircraft displays.

[0046] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is capable of dynamically presenting flight procedures, predicted aircraft locations and terminal area information, with real time reaction to changes in information.

[0047] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that permits a user to explore and rearrange the view of aeronautical data that was used to create a given procedure.

[0048] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality with improved information presentation capabilities with respect to an aircraft flight path, including integration for previously accepted or selected engine failure procedures.

[0049] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to utilize contextually sensitive charts as the same basis for the solution to a given inquiry, regardless of the particular aviation industry sector or personnel type from which the inquiry emanates.

[0050] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to visually present an interactive, four-dimensional predictive aircraft flight path, based on normal and non-normal operating configurations. [0051] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to display to a user temporary aeronautical data changes in a pre-rendered view of flight procedure or airport/runway information.

[0052] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to automatically highlight a graphical depiction of flight procedure information when a user highlights corresponding flight procedure information presented in textual form.

[0053] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that provides visual feedback regarding the safest paths to take when experiencing an enroute emergency situation that requires extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing.

[0054] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality wherein sectorized potential descent paths are calculated based on common navigational points over terrain, or based on a regional positioning system.

[0055] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that is adapted to visually indicate special missed approach procedures for a given airport.

[0056] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that utilizes the same aeronautical and geospatial data as other system components or aspects, so as to provide for common user selectable terrain and obstacle considerations.

[0057] Exemplary system and method embodiments described herein may include aviation regulatory compliance and performance impact analysis functionality.

[0058] Exemplary system and method embodiments described herein may include visually-based aviation regulatory compliance and performance impact analysis functionality.

[0059] Exemplary system and method embodiments described herein may include visually-based regulatory compliance and performance impact analysis functionality that is adapted to collect, visualize, and associate collections of, textual information, data tables, business processes, regulations, manuals, guidance materials and other sources of an electronic nature, and to permit access thereto via web browsers and mobile devices.

[0060] Other aspects and features of the invention will become apparent to those skilled in the art upon review of the following detailed description of exemplary embodiments along with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS [0061] In the following descriptions of the drawings and exemplary embodiments, like reference numerals across the several views refer to identical or equivalent features, and:

[0062] FIG. 1 schematically represents a high level view of possible web services architecture for an exemplary system embodiment;

[0063] FIG. 2 schematically represents the interface function of an aeronautical data package that is useable with exemplary system and method embodiments;

[0064] FIG. 3 depicts an exemplary landing page of a terminal area and airport management product of one exemplary system embodiment;

[0065] FIG. 4 depicts an exemplary work area view associated with the exemplary terminal area and airport management product of FIG. 3;

[0066] FIG. 5 depicts an exemplary airport view associated with the exemplary terminal area and airport management product of FIG. 3;

[0067] FIG. 6 represents one exemplary convergence of evidence and de- confliction function associated with the exemplary terminal area and airport management product of FIG. 3;

[0068] FIGS. 7A-7B represent another exemplary convergence of evidence and de-confliction function associated with the exemplary terminal area and airport management product of FIG. 3;

[0069] FIG. 8A schematically depicts a mapped area surrounding an exemplary airport runway, with an indicated area of missing obstacle data; [0070] FIG. 8B schematically represents the effects of obstacle shadowing and survey age, along with a diminishing risk of obstacle interference with increasing aircraft altitude;

[0071] FIG. 9 schematically depicts a multitude of obstacles along a given flight path within some bounding area around an exemplary airport, wherein the obstacles are represented as cylinders whose height represents the obstacle elevation;

[0072] FIG. 10 depicts a terrain-based spline fitted surface applied over the bounding area and obstacle features of FIG. 9;

[0073] FIG. 1 1 depicts the spline fitted surface of FIG. 10 in conjunction with a rasterized set of FAA Part 77 protection surfaces;

[0074] FIG. 12 depicts data sources of an exemplary embodiment of surface creation with 0% risk mitigation;

[0075] FIG. 13 depicts boosted data sources according to the exemplary embodiment of FIG. 12;

[0076] FIG. 14 depicts a CTS surface according to the exemplary embodiment of FIG 12;

[0077] FIG. 15 depicts the amount of boost per source according to the exemplary embodiment of FIG. 12;

[0078] FIG. 16 depicts a CCS surface according to the exemplary embodiment of FIG. 12;

[0079] FIG. 17 depicts a CRS surface according to the exemplary embodiment of FIG. 12;

[0080] FIG. 18 depicts a graph of minimum values according to the exemplary embodiment of FIG. 12;

[0081] FIG. 19 depicts boosted data sources at 10% risk mitigation according to the exemplary embodiment of FIG. 12;

[0082] FIG. 20 depicts a CTS surface at 1 0% risk mitigation according to the exemplary embodiment of FIG. 12;

[0083] FIG. 21 depicts the amount of boost per source at 10% risk mitigation according to the exemplary embodiment of FIG. 12;

[0084] FIG. 22 depicts a CCS surface at 10% risk mitigation according to the exemplary embodiment of FIG. 12; [0085] FIG. 23 depicts a CRS surface at 10% risk mitigation according to the exemplary embodiment of FIG. 12;

[0086] FIG. 24 depicts a CTS surface at 90% risk mitigation according to the exemplary embodiment of FIG. 12;

[0087] FIG. 25 depicts a CCS surface at 90% risk mitigation according to the exemplary embodiment of FIG. 12;

[0088] FIG. 26 depicts a CRS surface at 90% risk mitigation according to the exemplary embodiment of FIG. 12;

[0089] FIG. 27 depicts an exemplary process for creating various surfaces for an area of interest;

[0090] FIG. 28 depicts a Part 77 surface for use with an exemplary embodiment;

[0091] FIG. 29 depicts a USGS elevational model for use with an exemplary embodiment;

[0092] FIG. 30 depicts a USGS DEM surface for use with an exemplary embodiment;

[0093] FIG. 31 depicts a DOF for use with an exemplary embodiment;

[0094] FIG. 32 depicts the DOF of FIG. 31 with spline tension surface processing;

[0095] FIG. 33 depicts a composite of the data sets of Figs. 28, 29, 30, and 31 ;

[0096] FIG. 34 depicts a CTS according to an exemplary embodiment;

[0097] FIG. 35 depicts a CCS according to an exemplary embodiment;

[0098] FIG. 36 depicts a CRS according to an exemplary embodiment;

[0099] FIG. 37 depicts an alternative visual presentation of multiple AVS surfaces;

[00100] FIG. 38 represents an alternative visual presentation (i.e., a profile view) of flight path risk based on an AVS determination;

[00101 ] FIG. 39 represents the general use of a calculated AVS as part of a risk-enabled and performance-based procedure modeling and design function;

[00102] FIG. 40 depicts an exemplary page of an aircraft performance calculation product/function of one exemplary system embodiment; [00103] FIG. 41 represents an exemplary visual presentation of various possible departure paths with associated risk scores as calculated and presented by the aircraft performance calculation product/function represented in FIG. 38;

[00104] FIG. 42 represents an exemplary numerical chart/table that can be generated by an exemplary aircraft performance calculation product/function and used to produce a selected departure risk under alternative weather and aircraft performance conditions;

[00105] FIG. 43 depicts one exemplary route special departure procedure (RSDP) chart that is producible by an exemplary system embodiment;

[00106] FIG. 44 depicts another exemplary RSDP chart that is producible by an exemplary system embodiment;

[00107] FIG. 45 depicts yet another exemplary RSDP chart that is producible by an exemplary system embodiment;

[00108] FIG. 46 schematically illustrates an exemplary process for the construction of the flight paths for an obstacle in relation to producing a sector special departure procedure (SSDP) according to an exemplary system and method embodiment;

[00109] FIG. 47 depicts one exemplary SSDP chart that is producible by an exemplary system embodiment;

[00110] FIG. 48 depicts another exemplary SSDP chart that is producible by an exemplary system embodiment;

[00111 ] FIG. 49A illustrates how various layers of a chart, such as the SSDP chart of FIG. 48, may be turned on or off according to at least some exemplary system and method embodiments;

[00112] FIG. 49B represents the SSDP chart of FIG. 48 with certain layers turned off according to FIG. 49A;

[00113] FIG. 50 illustrates a non-exhaustive collection of unique symbols that may be used on special departure procedure (SDP) charts producible by exemplary system and method embodiments;

[00114] FIG. 51 is an exemplary SID chart that may be generated by exemplary system and method embodiments;

[00115] FIG. 52 is an exemplary instrument approach chart that may be generated by exemplary system and method embodiments; [00116] FIG. 53 is another exemplary instrument approach chart that may be generated by exemplary system and method embodiments;

[00117] FIG. 54 is an exemplary enhanced SID chart showing both an all engines operative and a one engine inoperative flight path;

[00118] FIGS. 55-56 illustrate exemplary dynamic aeronautical charting functionality of an exemplary system and method embodiment, wherein textual or graphical flight procedure information is automatically highlighted when a user selects the corresponding flight procedure information presented in opposite form;

[00119] FIG. 57 is a portion of an exemplary SID chart that demonstrates the predictive flight path modeling and charting abilities of an exemplary system and method embodiment;

[00120] FIG. 58 is an exemplary visual presentation of data relating to the airborne emergency decision-making functionality present in an exemplary system embodiment; and

[00121 ] FIG. 59 is a diagrammatic functional representation of one exemplary visual interface to regulatory compliance and performance impact analysis aspect of an exemplary system embodiment. DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[00122] As described above, exemplary system and method embodiments will typically have an aeronautical/geospatial database, or series of databases. For non-limiting purposes related only to illustration and identification within this application, this database or collection of databases, will be referred to as the TEAM DB. The TEAM DB may contain information regarding, for example, airports, runways, aircraft performance data, aeronautical features, navigational aids, communication infrastructure, earth data such as terrain and other features, land use, and land cover, obstacle data, regulatory information, etc. Generally speaking, the TEAM DB may contain all the information required to effectuate any feature or perform any function of any exemplary system and method embodiment described herein. The TEAM DB may be cloud-based, such that the information available therein may be conveniently accessed by other system components or functionality via a web browser. At least some TEAM DB data may be retrieved and stored locally on mobile and other devices to permit certain functionality in the absence of an Internet connection.

[00123] A schematically-represented high level view of exemplary web services architecture that incorporates the TEAM DB is presented in FIG. 1 . Such an architecture may be employed by an exemplary system, or component of a system, described herein.

[00124] As shown in FIG. 1 , the TEAM DB is in communication with the Internet (Web) through an intermediary extract/transform/load component (ETL) that generally speaking, ingests aviation-related data from a multitude of authoritative sources (data bases) and automatically and semi-automatically populates the TEAM DB. The ETL may also receive data from, for example, airport and operator sources - which data may also be added to the TEAM DB once appropriately vetted. One or more customer databases may also exist separately from the TEAM DB. Such customer databases may contain private information that a given customer does not want to share with other industry users. For example, a customer database may contain privately contracted survey information, operation standards governing the flight procedures of the customer, etc. Exemplary system embodiments permit isolation of such a customer database to only the owner (or other authorized user) of the database.

[00125] As a majority of the functionality of an exemplary system embodiment is intended to be accessible via an Internet-connected web browser, the TEAM DB and optional customer database(s) are in communication across a database tier (DB) with corresponding web servers that facilitate communication between an Internet-connected user and the databases. The web servers may be a feature of cloud-computing services offered by, for example, Amazon® web services - a design feature that permits exemplary system embodiments to be virtually infinitely scalable.

[00126] The left hand side of FIG. 1 particularly represents exemplary architecture associated with an exemplary terminal area and airport management product/function of an exemplary system, wherein the terminal area and airport management product/function has been designated as the T+ App only for the sake of brevity. It can be observed that the T+ App, which may be implemented as a JavaScript® application, communicates with the web services, and thus the databases, through a product specific service. The product specific server performs orchestration services between the web servers and the T+ App.

[00127] Moving now toward the right of FIG. 1 , the architecture associated with an exemplary aircraft performance calculation product/function of an exemplary system may be observed. As shown in FIG. 1 , the aircraft performance calculation product/function has been designated as the P+ App only for the sake of brevity. The P+ App receives data from the databases across a computational and business tier (CO) BT, via associated web services, with orchestration services again performed by an appropriate product specific service.

[00128] As also represented in FIG. 1 , the P+ App may be provided with information generated by one or more performance modules Pi - P3 that reside on a separate and scalable server that is in communication with the web servers. The performance modules may, for example, perform various aircraft performance calculations as requested via the P+ App. Data from the performance module server may also be provided to a separate application running on a mobile device.

[00129] As indicated in FIG. 1 , other products/components (e.g., XYZ Apps) would communicate with the TEAM DB and possibly a customer database(s) in a similar manner according to the illustrated and exemplary architecture. Variations to the architecture are, of course, possible depending on the nature of a given XYZ App.

[00130] FIG. 2 schematically represents the interaction between the TEAM DB and a specially developed aeronautical data package (data package) which, generally speaking, is comprised of a set of data files that are written to the file system for input by an automated charting and encoding (ACE) engine and a global procedure designer (GPD). The ACE engine is responsible for generating aeronautical charts, such as but not limited to, the novel special departure procedure (SDP) charts that are described in more detail below. Among other things, the GPD may be responsible for producing airport, runway and NAVAID surfaces, and for designing route SDP and sector SDP charts.

[00131 ] The data package may include, for example, aeronautical and procedure data. The data package acts as an interface mechanism that, among other things, isolates the ACE engine and the GPD from the TEAM DB, thereby leveraging the capability in TEAM DB to generate a data set in digital aeronautical flight information file (DAFIF) and digital vertical obstructions file (DVOF) formats.

[00132] Referring now to FIGS. 3-5, various exemplary web pages of an exemplary terminal area and airport management product/function may be observed. For purposes of only illustration and identification, the terminal area and airport management product/function is labeled as Terminal + in FIGS. 3-5 (see also T+ in FIG. 1 ). As shown, this exemplary landing page allows a user to select from a number of options, including searching for a particular airport by International Civil Aviation Organization (ICAO) designation or by a TEAM DB designation or identification (ID), as well as performing an aeronautical data search, accessing a customer profile, or creating an entity (profile). Other landing page designs, layouts and options are, of course, possible, and nothing presented in FIG. 3 is to be interpreted as limiting the appearance or content of such a landing page.

[00133] Upon selection of an airport, various other pages and options may be presented. FIG. 4 represents an exemplary additional page that may be presented following airport selection. In this case, FIG. 4 visually depicts an exemplary work area view that includes the selected airport, as well as other airports that are within some predefined or user selectable geographic area surrounding the selected airport. An abundance of additional information may be provided on such a graphic presentation, including but not limited to depicted airport boundaries, runways, the presence of navigational aids and waypoints, obstacles, and flight path information. Such information may be represented by various icons, as indicated along the upper-left side of the page in FIG. 4.

[00134] In this particular Terminal product/function example, layer manipulation is also permitted and provided for. For example, each type of information shown may be associated with a given layer of the presented graphic, such that a user can selectively allow or suppress the appearance of a given type of information(s).

[00135] FIG. 5 represents another exemplary page that may be presented following airport selection via the landing page of FIG. 3. In this case, FIG. 5 visually depicts a more detailed view of the selected airport and the area immediately surrounding the selected airport. This view also presents a better indication of obstacles in the potential flight path of an approaching or departing aircraft. Specific airport information is also provided, such as but not limited to the airport ICAO code designation (KEGE in this example), the airport name, and the airport type. A variety of other airport information may also be presented.

[00136] The exemplary page of FIG. 5 also specifies to a user the data sources from which the information used to generate and locate the indicated runways, airports, obstacles, etc., was retrieved, or from the sources from which the information is optionally retrievable. For example, it is indicated in this example that available host nation data sources for the selected airport include FAA CIFP (A424-18) and FAA NFDC. It is also indicated that the information currently displayed is derived from the FAA NFDC data source. It is further indicated that other non-host nation (customer) data sources are also available. In this case, those customer data sources are shown to be A424.

[00137] As should be obvious, a terminal area and airport management product/function such as the exemplary T+ product/function described above and illustrated in part in FIGS. 3-5, is useful to a multitude of different users for a variety of different purposes. Relevant users include, but are not limited to, airport operators, airport designers/builders, airport regulators, pilots, dispatchers, engineers and other personnel associated with flight planning or flight management, manufacturers of aircraft and navigational equipment, and even flight simulator manufacturers. For example, an airport operator might use an exemplary version of the T+ product/function rather than a traditional notice to airmen (NOTAM) or other mechanism to upload airport changes for viewing by airlines and others that utilize the affected airport. An exemplary T+ product/function may permit the airport operator to easily include a description of how the airport changes will affect flights into and out of the airport. Such a notification would become viewable to all users of the associated system as soon as uploaded by the airport operator.

[00138] Airport designers/planners might use an exemplary T+ product/function to, for example, generate runway mockups or to create a hypothetical asset, and the data associated with such activities may be exported to one or more other products/functions of the associated exemplary system to determine the sufficiency of the design or the effect of the construction. As described in more detail below, designers/planners may also use related protection surface (such as a risk surface) data to see how a given airport is affected. Airport regulators might use an exemplary T+ product/function to, for example, test risk concepts, develop planning surfaces, etc. Users such as pilots, dispatchers and engineers might use an exemplary T+ product/function to, for example, see airport information or changes to airport information input by airport operators or others, so that said users have the most current and accurate data against which to fly. Users such as pilots, dispatchers and engineers might also compare the output of information available from an exemplary T+ product/function to a different source of related information, such as an existing chart or NOTAM, to note and possibly resolve any conflicts.

[00139] As would be well understood by one of skill in the art, conflicts between information from different data sources regarding the same information often exist. Common conflicts might include, for example and without limitation, the starting point, length, elevation and/or precise orientation of a particular runway at a given airport, or the presence, location and/or elevation of obstacles within some flight path of interest. Conflicting information can be dangerous - particularly when the source of information ultimately relied upon is wrong. Therefore, another possible feature of an exemplary system and method of the present application is the ability to consider airport and obstacle data from multiple sources, and to perform a de-confliction operation on said data so as to visually present a user with best available information relating to an airport and/or associated area of interest. Such functionality may be an aspect of a terminal area and airport management product/function of an exemplary system embodiment. However, exemplary systems embodiments are not so limited, and such functionality may instead be provided by another product/function.

[00140] FIG. 6 schematically represents one example of the aggregation and de-confliction of information described generally above. In this example, a user has selected a particular airport of interest, and the user desires to see the location and elevation of obstacles surrounding the airport. As may be observed from the first image in FIG. 6, the obstacle data obtained from the FAA No. 405 Spec for this particular airport is insufficient with respect to both the currency and coverage. As a result, this exemplary system also considers Airports Geographic Information Systems (AGIS) obstacle data and applies the AGIS-identified obstacles to the chart, as indicated by the second image of FIG. 6. The exemplary system next performs a de-confliction operation between the FAA No. 405 Spec and AGIS obstacle data to obtain and present an optimized obstacle chart, which is represented by the third image of FIG. 6.

[00141 ] Exemplary system and method embodiments may permit comments and/or other feedback from relevant users (e.g., airport personnel, airline operators, pilots, etc.) regarding the location, elevation and/or other characteristics of obstacles, and may store such information in the TEAM DB or elsewhere for subsequent retrieval and use by one or more products/functions of the system. Consequently, the exemplary system of FIG. 6 also considers and uses such information when determining and presenting the number, location and elevation of obstacles to the user. The inclusion and presentation of user-supplied obstacle data is represented in the last chart image of FIG. 6, where the user-supplied obstacle data has been added to the de-conflicted obstacle data described above to provide the user with the best available indication of obstacle presence, location and elevation.

[00142] While data aggregation and de-confliction can be used to produce a best available solution, as represented in FIG. 6, a best available solution is not necessarily the most accurate or optimized solution. With this in mind, exemplary system and method embodiments described herein may include the ability to determine a best obtainable solution whose accuracy exceeds that of a best available solution.

[00143] One example of providing a best obtainable versus a best available solution to a query is schematically represented in FIGS. 7A-7B. In this particular example, the best obtainable solution is the most likely geospatial location and orientation of a runway of interest, but the described functionality may be applied equally well to other subject matter for which there is a conflict between data sources.

[00144] FIG. 7A represents an overlay of runway location and orientation according to three different data sources. The runway data may be obtained from, for example, host nation data, survey data, imagery data, etc. A different number and/or type of data sources may be considered in other embodiments. In any case, as may be observed in this example, the precise geospatial location and orientation of the runway is slightly different according to each data source. Thus, if the data sources used to indicate the runway location and orientation in this example were considered to be the best available sources, a user would be left to guess as to which of the indicated locations and orientations is correct.

[00145] Alternatively, an exemplary system embodiment may determine and present a best obtainable estimate of the true location and orientation of the runway of interest. Such a best obtainable location is shown in FIG. 7B. In this example, the best obtainable runway location and orientation does not coincide precisely with any of the overlaid locations and orientations depicted in FIG. 7A (although such may not always be the case). Rather, the best obtainable runway location and orientation presented in FIG. 7B is the result of the exemplary system applying a convergence of the evidence technique to the available runway data, and applying a mathematical algorithm to said data to best estimate the true location and orientation of the subject runway. The algorithm may consider various factors such as, but not limited to, the general accuracy associated with the technique from which a given data set was produced (e.g., a ground-based survey versus satellite imagery, etc.).

[00146] A user of an exemplary system wherein best obtainable solution functionality is offered is not required to make use of said functionality. For example, in the case of the runway of FIGS. 7A-7B, a user may prefer to go with their own best guess as to true runaway location and orientation rather than a system-calculated estimation thereof. As with the aggregation and de-confliction functionality illustrated in FIG. 6, best obtainable solution functionality of an exemplary system may be associated with a terminal area and airport management product/function of an exemplary system embodiment, or with another product/function of the exemplary system.

[00147] As described above, airport area and obstacle data may be used in a variety of ways. However, exemplary systems and methods described herein may also novelly employ obstacle data to produce heretofore non-existent aviation virtual surfaces ("AVS") for communicating information about risk around a given airport or other area of interest.

[00148] It is not uncommon for a given area around an airport that may be relevant to a desired flight path to be indicated on charts as being devoid of or substantially devoid of obstacle data, whether due to a lack of survey or other mapping information, due to shadowing, or otherwise. An example of such an area is represented as the devoid area within the dashed circle of FIG. 8A. While such an area may appear to be devoid of obstacles for such reasons, experienced aviation personnel understand that the risk of obstacles nonetheless existing in such an area (see FIG. 8B) must be taken into consideration for purposes of, for example, airport planning/design, flight procedure design/development, and aircraft performance calculations and risk management.

[00149] However, there is currently no known system or method for accurately predicting the location and elevation of obstacles in such an area nor, therefore, is there currently a known system or method that permits an interested party to assess the risk of a desired flight path over such an area. Furthermore, there is currently no known system or method for providing an interested party with a visual representation of risk over a geographic surface, and allowing an interested party to see how changes in source data and other parameters can change risk.

[00150] Exemplary system embodiments may, therefore, generate a digital, aviation virtual surface (AVS) for an area of interest using a GIS platform such as, but not limited to, ArcGIS® (Esri), QGIS, GeoMedia® (Intergraph), or Grass GIS. While an AVS may be created for any area of interest, users may find AVS embodiments to be particularly useful when the area of interest is one having inadequate obstacle data, conflicting obstacle data, or one that is devoid or substantially devoid of obstacle data. With respect to exemplary embodiments described herein, an AVS may be thought of generally as virtual surfaces that communicate information about risk, data quality, data consilience, or other properties, qualities, and relative characteristics of geospatial information. In some embodiments, an AVS provides a visual aid for analyzing the likelihood of encountering obstructions to navigation and the risks associated with vehicle operations (such as flight operations) over, around, or through them. For example, an AVS may be generated to provide a visual representation of the risk that a vertically-oriented obstacle exists at a given geographic location within an area of interest.

[00151 ] In other embodiments, and as discussed further herein, an AVS may provide a visual representation of data quality, or the amount of consilience (agreement) between multiple data sources. An AVS may provide visual representations of perceived risk, or risk "probability," which may also be presented in terms of risk mitigation. Exemplary AVS embodiments include, but are not limited to, obstacle terrain probability surfaces ("OTP"); composite terrain surfaces ("CTS"); composite consilience surfaces ("CCS"); and composite risk surfaces ("CRS"); which are all discussed further herein.

[00152] The creation of an AVS is a complex process comprised of a number of different steps which may vary according to embodiment. Broadly described, however, an AVS is created according to one exemplary system embodiment by first establishing the earth's surface. This step may actually involve establishing a plurality of "earth surfaces", such as but not limited to a primary earth surface, a secondary earth surface, a first tertiary earth surface, and a second tertiary earth surface. Each of these surfaces is established based on surface data from a specific data source or upon the aggregation of surface data from particular combinations of data sources. In the event of a data conflict, a de-confliction operation may be employed.

[00153] Once the earth surfaces are established, the next step in this exemplary AVS generation process is improving the earth's surface. Generally speaking, this means introducing survey areas with better resolution or improved accuracy or currency, introducing new land cover raster or vector information, introducing land use data, and or utilizing other similar enhancement techniques.

[00154] Subsequent to the step of improving the earth's surface, this exemplary AVS generation process then moves to establishing obstacle surfaces. Establishing obstacle surfaces may be a multi-step process. For example, initial establishment of obstacle surfaces may involve locating all obstacles in an area within some radius around an airport of interest; establishing point obstacle locations according to obstacle nominal X, Y, Z coordinates; establishing vector boundaries between any point obstacles identified as being "connected" obstacles; determining the survey types and dates from all obstacles detected; and retaining survey surfaces and obstruction points, polylines and/or polygons as viewable layers. If a user creating an AVS believes that multiple obstacles (from different data sources) are all representations of the same thing, then a de-confliction operation may be undertaken. The establishment of obstacle surfaces may then proceed to establishing multiple obstacle surfaces, such as but not limited to, a primary obstacle surface, a secondary obstacle surface, a first tertiary obstacle surface and a second tertiary obstacle surface.

[00155] Subsequent to the establishment of obstacle surfaces, this exemplary AVS generation process may then move to the step of defining protection surfaces. The protection surfaces to be defined may include, for example and without limitation, runway protection surfaces, airspace protection, airport protection, NAVAID protection, lighting protection, flight path protection, and all protection surfaces. In this example, it may next be determined what portion of the calculated probability surfaces (volumes) are within Federal Aviation Regulation (FAR) Part 77 (obstructions to navigation) or ICAO Annex 14 surfaces, and what portion is not.

[00156] In an exemplary embodiment, AVS functionality is operative to create a series of three dimensional surfaces whose geospatial parameters may be derived from independent sources of elevation information. Disparate sources of elevation, terrain, manmade obstructions, land use, land cover, survey identification surfaces, airspace protection surfaces, runway protection surfaces, NAVAID protection surfaces and existing flight procedure/airspace surfaces/volumes are combined into multiple raster/vector surfaces that represent confidence intervals (expressed as vertical likelihood). Users of a system with AVS generation functionality will therefore be able to model geometric lines, polylines, polygons, rasters and other complex geometries that can either penetrate one or multiple layers of an AVS or remain above one or more layers of the AVS, depending on the use case. If a user elects to penetrate an AVS layer via a desired flight path, for example, the portion of the path that penetrates the layer will be exposed to a "risk" or "likelihood" of contacting vertical features of the earth or other vertically-oriented (e.g., manmade) obstacles. [00157] There are many different types of multi-dimensional volumes that are relevant to AVS generation and modeling. As discussed herein, the term "volumes" broadly includes multi-dimensional "surfaces" when appropriate. Relevant volumes for AVS include spatial volumes, physical volumes, surface volumes, detection volumes, protection volumes, obstacle volumes, operational volumes, obstacle terrain probability volumes, risk probability volumes. Various volumes and methods of preprocessing volumes are further discussed below.

Spatial Volumes

[00158] An AVS may be comprised of multi-dimensional volumes, herein referred to as "spatial volumes," which may be generated from common geophysical, aeronautical and operational data sources but can also be expanded to other types of data including environmental data. Within each volume of data exists surfaces that a likelihood that an object will exist. The likelihood is an expression of a cumulative distribution functions defined by several common descriptive statistics which incorporate the accuracy, density, history and extent of the source information. Where surfaces from different volumes intersect, a hazard model is applied that expresses the likelihood and severity of a navigation event into a risk assessment. As discussed more herein, this risk information can be visualized through a heat map, analyzed along one or more paths/surfaces/volumes to determine a risk score for a route, or can be used to determine the quality of source information used with the goal of conflating several sources of data together.

[00159] Spatial volumes are created from sources of information that either contain or relate to geospatial information. Spatial volumes as raster surfaces may contain the following information: X&Y geodetic coordinates in a system known to general coordinate conversion capabilities (for example, WGS-84 decimal latitude and longitude inputs); Z-values expressed as elevations measured for sea level based on NAVD88 or as an additive to an existing volume's Z-value; z-inheritance from another surface; source type to help restrict certain kinds of sources into logical volume construction; volume inheritance (for example, obstacle inheriting the lateral and vertical properties of a detection volume); primary raster values; secondary raster values and attributes (for example, horizontal accuracy, vertical accuracy, vertical probability density, horizontal probability density, origination data, frequency of update, and growth rate). Spatial volumes used in exemplary AVS systems and methods can often be categorized as either input categories (physical, surface, detection, protection, obstacle, operational, etc.) or output categories (obstacle terrain probability ("OTP") volumes, risk probability volumes.

Physical Volumes

[00160] Physical volumes are 3-D representations of geospatial information that represents the shape of the bare earth, or nearly bare earth. Common sources include GTOPO, ASTER, ICESAT, NED and even SRTM. Less common sources are representations of runways, railways and roadways.

[00161 ] Physical volumes represent a space which is thought to be impermeable at all elevations below the stated value and is semi-permeable within the limits of the described accuracy. Physical volume accuracy is typically only described by the method in which the source information was obtained, and is often expressed by a linear error (LE) and a confidence interval or likelihood (for example, 90%). Physical volumes do not require a probability density function because the intention of the volume, and its accuracy, is to define an area in which the bare earth may very likely exist. Information about the origination date for the source of the physical volume is a required element which will frequently be used in the creation of an OTP. The frequency of update is not required as most physical volume sources do not contain this information replacing, instead replacing one source directly by a newer version. Growth rate information is also optional for this volume as the time scale for changes are usually measured on a geologic rather than a natural or environmental timeline and is therefore usually greater than the update rate from new physical volume sources.

[00162] Physical volumes may be created by adding additional metadata properties to raster based elevation information used as the input. On occasions where a physical volume is to be defined by a polygon (road, railroad, runway) then an initial raster will have to be created which can capture the lateral and vertical resolution of the input polygon. The physical surface/polygon is then overlaid onto this new raster and the elevation values for the polygon are inherited by the underlying raster grid. In grid cells where no overlap occurs a value of n/a may be stored.

[00163] Attributes about the raster are then defined by the user through a GUI, or direct file manipulation of the metadata. Once both the rasterization of the original surface and the metadata containing attributes are created, the physical volume is considered complete.

Surface Volumes

[00164] Surface volumes are a 3-D representation of geospatial information that can represent a physical surface that is not considered to be the bare earth. A surface volume can be something as simple as first return information collected during remote sensing, like SRTM or LIDAR. Surface volumes can also be created from more complicated applications of user expressed semi-permeable descriptive statistics applied as an additive to a physical volume. These include, but are not limited to, land use land cover additives, runway design surfaces, or even runway safety areas.

[00165] Surface volumes may be sourced from information that was considered to be impermeable beneath the elevation in the raster set, but they are more usefully defined as a volume of varying permeability with accuracy and probability density characteristics that extend above and below the base elevation value. Surface volume accuracy is either defined by the user in terms of horizontal and vertical accuracy or is an inherited property from a physical volume. Surface volume probability density may be defined by the user in the vertical extent. Information about the origination date may be required for the creation of the OTP, particularly if the volume is intended to be used as an alternative source of information when compared to physical volumes. The frequency of update may be specified in situations where a growth rate is also defined.

[00166] Surface volume creation is dependent on the kind of source information used. For surface data sets which are already in a raster format, the only necessary addition to the data may be the required attributes which can be added to a metadata file via a GUI or directly input into the file. Surface data sets which are represented by a polygonal surface, or which inherit the properties of a physical volume, will require a base raster to be established of sufficient resolution to capture the necessary lateral and vertical geometric features. In some embodiments resolutions of no more than 1 0m and no less than 0.1 m will be required. The raster will then inherit the vertical elevation values of the surface described. In raster cells where no overlap of the surface exists, then a value of n/a will be stored. Where an overlap of the surface and a physical raster occurs, an additional raster algebra step may be required to apply a vertical additive to the raster cell in order to achieve the intended surface volume elevation.

Detection Volumes

[00167] Detection volumes are 4-D surfaces that are used to help detect the presence of objects or changes to objects. Detection volumes are considered to be an area over which a person or technology is responsible for observing, measuring or reporting data which would typically be considered in an obstacle volume. Beneath the surface, detection is not performed meaning that the probability density of obstacles is at most impermeable and at a minimum user defined. Detection volumes do not prohibit the existence of obstacles or other physical volumes.

[00168] Detection volumes may be required as part of the definition of an obstacle volume's horizontal extent and may also be required to act as a vertical limitation on probability density. Detection volumes also provide a useful probability density of elevations underneath the listed elevation. Typical sources of detection volumes include AC-1 50-5300-18B VGA and NVGA, ICAO Annex 15 and NOAA 405 Specification. Non-traditional sources for detection volumes can be a simple extent used for a spot or localized obstacle collection survey. Detection volumes frequently inherit the properties of the source from which they were created and therefore must have a defined set of descriptive statistics for horizontal and vertical accuracy. Detection volumes must also have user defined probability density statistics but only in the vertical extent. Origination date and the frequency of update/detection may be critical pieces of information for the detection surface and have significant impacts on the applicability of the probability density results along with any descriptive statistics identified regarding the growth rate of the volume. [00169] Detection volumes may be created by overlaying a protection surface onto a raster with sufficiently fine resolution to capture any lateral or vertical changes in geometry as accurately as possible. In some embodiments, resolutions of no more than 10m and no less than 0.1 m may be required. The raster will then inherit the vertical elevation values of the surface described. In raster cells where no overlap of the surface exists, then a value of n/a may be stored. Attributes about the raster are then defined by the user through a GUI, or direct file manipulation of the metadata. Once both the rasterization of the original surface and the metadata containing attributes are created, the detection volume is considered complete.

Protection Volumes

[00170] Protection volumes are 4-D surfaces that are used to help deter the creation of new objects or changes to existing objects. Similar to detection volumes, protection volumes are considered to be an area over which a person or technology is responsible for observing, measuring or reporting data which would typically be considered in an obstacle volume. However, the purpose of a protection volume is to restrict, delay and/or prohibit the presence of any new objects above the protection surface, thereby decreasing the overall probability density of unknown elevation points above the input surface. In practice, a protection volume will not have a "0" probability density above the surface, but the likelihood that undetected obstacles exist above the protection surface is much lower than the likelihood that undetected obstacles exist below it. Beneath the protection surface, detection is not performed meaning that the probability density of obstacles is at most impermeable and at a minimum user defined. Typical sources of protection volumes include FAR Part 77, ICAO Annex 14, runway, NAVAID and lighting obstacle control surfaces. Non-traditional sources for protection volumes may be generated form instrument procedure obstruction clearance surfaces.

[00171 ] Protection volumes frequently inherit the properties of the source from which they were created and therefore may have a defined set of descriptive statistics for horizontal and vertical accuracy. Protection volumes may also have user defined probability density statistics only in the vertical extent. Origination date and the update/detection frequency may be critical pieces of information for the protection surface that have significant impacts on the applicability of the probability density results along with any descriptive statistics identified regarding the growth rate of the volume.

[00172] Protection volumes may be created by overlaying a protection surface onto a raster with sufficiently fine resolution to capture any lateral or vertical changes in geometry as accurately as possible. In some embodiments, resolutions of no more than 10m and no less than 0.1 m may be required. The raster will then inherit the vertical elevation values of the surface described. In raster cells where no overlap of the surface exists, then a value of n/a may be stored.

[00173] Attributes about the raster are then defined by the user through a GUI, or direct file manipulation of the metadata. Once both the rasterization of the original surface and the metadata containing attributes are created, the protection volume may be considered complete.

Obstacle Volumes

[00174] Obstacle volumes are 4-D surfaces that represent objects which have been proposed, detected, measured and/or sensed to exist. Objects may be described as 1 or more types of geometries including a point, polygon, circle, cylinder or 3-D polygon. Objects in the obstacle volume may also represent a collection of those geometric 1 -D, 2-D and 3-D features which share a common extent and attributes.

[00175] In order to create an obstacle volume, knowledge about the extent, or volume, over which an obstacle was detected may be provided. For singular objects, the detection volume will likely not be any larger than the object or a rasterized version of the object's footprint. For complex objects, the 3-D/4-D detection volume under which the objects were detected may be used along with horizontal and vertical probability densities to assist with advanced 3-D spatial probability density function application.

[00176] In exemplary embodiments, obstacle volumes inherit the properties of the detection volume used to detect the objects being described, including the horizontal and vertical uncertainty. Additionally, the objects may have a set of descriptive statistics pertaining to the vertical and horizontal probability density function. The horizontal probability density function relates to the real world methods used to detect and simplify obstacles. This effect, known as "shadowing," can be well-described using horizontal probability density functions coupled with other lateral accuracy information inherited form the detection volume or overridden by the user.

[00177] The origination date and growth applications to the descriptive statistics are also attributes that may be defined on obstacle volumes. However, the update/detection frequency may not be as important with obstacle volumes because the age of an obstacle volume will most often be compared to the age of the detection volume. And while most obstacle volumes will not experience significant growth over time, the detection volume will experience significant growth over time.

[00178] Obstacle volumes may contain two sets of elevation values: the elevation for the top of the objects and the elevation for the base. Because an obstacle volume will only store one elevation value, it is possible to generate two obstacle volumes for the same set of objects which are related either to one and other. The practical application for comparing the base elevations of objects is as a means of checking the validity, likelihood, or risk of a physical volume when compared to an obstacle volume, or vice versa. This is because the base elevation of an object would most likely be attached to "bare earth".

[00179] Obstacle volumes may be constructed by combining an obstacle source with a detection volume raster. When an object from the source input is present at one or more grid points in the detection volume raster grid, then the new obstacle volume raster may be updated to receive the elevation value of the object in the obstacle source. If the obstacle source file contained only a single point, then only one raster grid value in the detection volume raster would overlap and all other raster grid cells in the new obstacle volume would not contain a target elevation from the obstacle source. If the obstacle source file contained a single object that was described as a single 2-D or 3-D object, then the multiple grid cells underneath the x, y footprint of the object would have their elevation values assigned to the obstacle volume raster.

Spline Tension

[00180] If the obstacle source file contains multiple objects (1 -D, 2-D, or 3-D) then a special horizontal transformation occurs to create a spline tension surface between the points of objects, limited by the x,y,z extents of the detection volume, for the elevation values associated with the top of the objects. This may be achieved by running a raster algebra spline tension model over each raster grid cell underlying the detection area, and ensuring that a continuous spline tension surface creates elevation values in all raster cells that do not otherwise have a defined 1 -D, 2-D or 3-D object. The lateral extent of the spline tension may not exceed the lateral dimension of the detection area, and the vertical extent of the spline tension elevation application may not fall beneath the detection volume elevation. In obstacle volume grid cells where the spline tension elevation falls beneath the elevation of the detection volume, the vertical elevation of the detection volume may be applied to the obstacle volume instead of the spline tension value. In the event that a detection volume is higher than a stated obstacle elevation, or in the event that a spline tension surface cannot be calculated between objects in the obstacle source, then the obstacle volume process will create an error log indicating the discrepancy.

Operational Volumes

[00181 ] Operational volumes are 4-D surfaces that represent the spatial area in which a moving object is anticipated to exist. Moving objects within an operational volume are represented by a statistical likelihood definition which expresses a correlation between the amount of time spent in an area and the volume of space in which the object can exist.

[00182] Operational volume sources can be created from sources that express an object in motion using certain degrees of freedom. The paths taken by a moving object can be simplified to express a particular area and vertical extent, such as a UAS operational area, or they can originate from more complicated paths like one engine inoperative and all engine operating aircraft trajectories. When using operational volumes to express complicated trajectories, it may be desirable to divide up the potential paths into smaller 4-D volumes which are later summed together in other applications.

[00183] Operational volumes require information about the horizontal and vertical accuracy, and horizontal and vertical probability density function in order to be used. The origination date, frequency/update and any growth characteristics may be optional yet highly useful pieces of information for comparing operational volumes to other historical surfaces (especially Environmental Volumes). Growth rate information may be used when an operational volume is anticipated to change over time, e.g. increased frequency of moving objects over time.

[00184] Operational volumes can either be described as a raster with advanced metadata information to convert it into a volume, or it can be a netCDF. When an operational volume is defined by a netCDF, the intent of the additional information is to store more than one elevation value per raster grid cell to represent a minimum, mean and maximum elevation which would vary in such a way that a probability density function could not otherwise be universally applied across.

[00185] Operational volumes are typically constructed independently from all other volumes. However, there may be situations in which a protection volume can be converted into an operational volume. For aeronautical applications, this would be a useful adaptation for an instrument approach surface that was converted into an operational volume, or even a runway protection surface. When an operational volume inherits the properties of another non-operational volume, only the 3-D extents of the volume may be inherited requiring that all other descriptive statistics be created independently from the inherited volume.

[00186] Operational volumes may be created by overlaying a moving object surface onto a raster with sufficiently fine resolution to capture any lateral or vertical changes in geometry as accurately as possible. In exemplary embodiments resolutions of no more than 1 0m and no less than 0.1 m will be required. In raster cells where no overlap of the surface exists, then a value of n/a may be stored.

[00187] When an advanced operational area needs to be defined, requiring minimum, mean, and maximum elevation values, then a second and third moving object surface may be overlaid onto the raster for the information to be stored. Attributes about the raster are then defined by the user through a GUI, or direct file manipulation of the metadata. Once both the rasterization of the original surface and the metadata containing attributes are created, the operational volume is considered complete. Obstacle Terrain Probability Volumes

[00188] By combining multiple spatial volumes together an obstacle and terrain probability volume (OTP) can be constructed. An OTP "volume" is a set or category of surfaces that share fundamental processes or metadata. Construction of an OTP may be achieved utilizing user definable algorithms to combine accuracy, probability density, age, update/frequency, growth and volume type to achieve the desired effect of the OTP. In some embodiments, an OTP may be a netCDF which stores elevation and descriptive or comparative statistical values like standard deviations, likelihoods, or hypothesis test results. OTPs may be used for performing several tasks related to assessing and combining other spatial volumes of information including composite surface creation, geospatial deconfliction and measuring the effectiveness of one volume/surface over others.

Risk Probability Volumes

[00189] Operational volumes and OTPs may be combined to create a new volume which is used to determine complex relationships relating likelihood and severity together to form risk scores. This new volume is herein referred to as a Risk Probability Volume (RP) and represents a user-defined combination of likelihoods taken from the Operational volume and the OTP. Assessing the likelihood of an event may be performed with a user defined combination of CDF or CCDF results at the single point where an OTP and an Operational volume intersect. Assessing the severity of an event may also be performed with the creation of user defined conditional matrix which relates to the Operational Volume CDF and an OTP CDF in categories of severity (ICAO SMS). The conditional matrix may be either dependent solely on elevation and other descriptive/comparative statistics, or it can incorporate source type as well. The likelihood of an operational volume may be calculated with the spatial integration of the intersection of the OTP and Operational Volumes. Risk may be assessed through a combination of likelihood and severity results over the Operational Volume netCDF to achieve a risk probability netCDF.

[00190] The aforementioned AVS data sources and AVS generation steps may be used to produce a graphical (i.e., visually-presentable) risk probability surface for a given area around a selected airport. The process and a resulting exemplary AVS are represented generally by FIGS. 9-1 1 . A multitude of detected vertically extending obstacles in the form of earth surfaces and/or other obstacles within an area supposedly devoid of such features, are represented in FIG. 9 by a like number of vertically-oriented cylinders. The position of each cylinder coincides with the geographic location of a corresponding detected feature, while the height of a given cylinder represents the elevation of its corresponding feature.

[00191 ] An AVS may be visually presented as, for example, a spline tension surface - meaning a surface that is produced through spatial interpolation by fitting tension splines between input points (i.e., determined obstacles). As represented in the example of FIG. 10, such a surface may be visualized generally as a sheet of flexible material that is draped over a series of underlying objects of different elevations. In the case of FIG. 10, the underlying objects of different elevations are the cylinders of FIG. 9 that represent a multitude of detected vertically extending obstacles. The three-dimensional nature of the generated surface as well as areas of greatest and lowest elevation are clearly evidence on the AVS of FIG. 10. As indicated, a AVS may utilize color to indicate elevation (i.e., be presented as a "heat map"), such as in FIG. 10, where the color yellow and similar hues are used to represent higher elevations, and red represents lower elevations. When color is used, a color scale may also be provided to associate a particular color with a corresponding elevation.

[00192] When the number of input points is low and/or the variation in elevation between input points is small, a RPS may appear less contoured. A RPS with minimal contour variation may be representative of a surface created, for example, using only basic terrain data, or possibly a surface generated using a regularized spline, as opposed to a tension spline, fitting method.

[00193] In FIG. 1 1 , a rasterized set of FAR Part 77 protection surfaces (as represented by the blue and purple hues) associated with the area in question has been combined with the AVS of FIG. 10. As can be observed, the area of interaction between the FAR Part 77 protection surfaces and the AVS results in a further enhanced graphical representation of the area surrounding the exemplary airport and, thus, an even better understanding of the overall surface against which takeoffs and landings must be executed. Measuring the Effectiveness of a Detection or Protection Volume

[00194] OTP volumes may also be used to analyze the effectiveness of a detection or protection volume. This is especially beneficial for users that rely on the effectiveness of the OTP volumes for other geospatial or aeronautical design applications. The ability to measure the effectiveness of a detection or protection volume is similar to geospatial deconfliction, except that the detection and protection surfaces themselves may be analyzed for their basic design purposes as well as their overall effectiveness towards the OTP volume in the space "above" the design and protection volumes. The differences may be stored in an OTP representing comparative statistical results rather than elevations.

Creating Composite Surfaces

[00195] Direct combination of volumes using probability density functions and base values to achieve a target cumulative distribution function score (CDF) or complementary cumulative distribution function (CCDF). The User defines a target CDF or CCDF, and the user can choose to apply a ranking system to give volumes a conditional precedence over others based on their type. For example, a user may choose to apply a "boost" system to give volumes a numerical precedence over others. The resulting CDF and CCDF are combined to achieve the target OTP and resulting surface(s) which were used to create the composite.

Performing Geospatial Deconfliction

[00196] The concept of geospatial deconfliction relates to the challenge that multiple sources of geospatial and aeronautical information attempt to express a "version" of truth which may or may not coincide with the accuracy or intent of other sources of information. The concept is also complicated by the fact that the best definition of an object, or the surface of the earth itself, may be well defined by combining multiple sources together while omitting others.

[00197] To assist in the task of geospatial deconfliction, an OTP can be compiled to create surfaces which measure the resulting likelihood of a point or surface to be better or more poorly served from the inclusion or omission of other volumes. Exemplary embodiments may create an OTP which calculates the likelihood, using a confidence test, that the input volume is already captured by another volume, or is not captured by another volume. Other exemplary embodiments may create a composite surface OTP with the target source and compare it to a composite surface OTP without the target source. Users may use OTP to achieve geospatial deconfliction to incorporate a new volume of information into the overall target model; deactivate a volume of information from the overall target model; correct potential source information for a particular volume; or create additional volumes which isolate areas that appear to be discrepancies.

Preprocessing

[00198] In an exemplary embodiment it may be necessary to preprocess one or more data sets introduced for use. Different data sets may have different geospatial formats. They may be raster or bit-mapped images or vector images consisting of points, lines, and polygons. Raster files may exist in various formats such as, but not limited to, BIL, BIP, BSQ, GeoTiff, and ArcGrid. As a part of preprocessing, sources of obstacle data are in vector format may be converted to raster format.

[00199] In some exemplary system and method embodiments, novel models may be used to create various virtual surfaces from one or more data sets, including CTS, CCS, and CRS surface, allowing a user to visually and analytically interpret information about one or more input surfaces.

Creation of a Composite Terrain Surface (CTS)

[00200] An initial step in generating a CTS is the selection of one or more input surfaces that cover an area of interest. The input surfaces may be identified as So, Si, S2 . . . SN. In various embodiments different numbers of input surfaces may be utilized. The input surfaces may be preprocessed according to various methods including those described herein, in order to arrive at a set of congruent raster grids may be characterized by a common coordinate reference system, grid resolution and pixel value data type.

[00201] In a next step, a rule base is applied in order to classify the input surface data sets along a data property dimension, which in an exemplary embodiment may be referred to as confidence or "risk." For example, elevation data that is not deemed of high quality and/or accuracy may be deemed to have a relatively higher risk of causing a collision, especially during critical phases of flight such as takeoff and landing. For flight safety purposes it may be desirable to reduce any perceived risk of collision caused by a data set by adding conservatism to elevation values via a coefficient that correlates to the perceived risk of collision. The coefficient is referred to herein as a "boost factor."

[00202] An example of a rule base for input surface data sets is shown below:

Table 1 : Exemplary Rule Base for Data Sets

[00203] The "% Confidence" may be the percentage of confidence that the elevation values in a data set are accurate, whereas the boost factor is applied for the lack of confidence and to reduce the risk to zero.

[00204] In the example rule base shown in Table 1 , the boost factor for Class 6 data sets is 0 because there is no amount of boosting that can overcome the lack of confidence in the data. On the other hand, if a data set is deemed to be Class 1 (Best), then its elevation values will not be altered when they are multiplied by the Boost Factor of 1 . Upon application of the boost factor to the data sets based upon their designated classes, a revised set of classified surfaces is created, identified as SO, S'i , S'2 . . . S'N.

[00205] The classified surfaces are used to construct the CTS through application of the following function:

Equation 1 : = MAX(SO, S'i , S' ₂ .. . S'N)

[00206] In Equation 1 , MAX is a function that selects the maximum value for every location or pixel. Creation of a Composite Consilience Surface (CCS)

[00207] In an exemplary embodiment, a CCS is created by first computing the degree to which each pixel value in a boosted set (SO, S' i , S'2 . . . S'N) differs from the corresponding pixel value in the data set with the highest subjective confidence. If SO were the data set with the highest subjective confidence, for example a Class 1 according to the rule base of Table 1 , then the measure of consilience would be calculated by the following function:

Equation 2: f = Abs(S'o - S'N)

[00208] If S' i and S'N contain very different values for each coincident pixel, then the absolute value of their differences will be very large. If they have identical values than the absolute value of their differences will be zero. Table 2 below demonstrates the application of Equation 2 to each of the data sets (S'i , S'2 . . . S'N), and the resulting consilience raster matrices.

Table 2: Consilience Matrices

[00209] Next, the CCS is computed according to the following equation:

Equation 3: / = SUM(C' i , C" ₂ . . . CN)

[00210] The result is a surface where each pixel's values range from zero to infinity. A pixel value of 0 represents a 100% agreement between the data sets. A pixel value of 1 or higher represents a disagreement between the data sets. Since this is another raster surface, it can be symbolized using graduated visualization techniques such as heat maps.

Creation of a Composite Risk Surface (CRS)

[00211 ] In an exemplary embodiment the risk surface is created by first calculating the amount of boost (risk mitigation) applied to each individual source surface. This may be performed using the following equation: Equation 4: / = Abs(S ₀ - SO)

[00212] This results in a set of values symbolized herein as BPSo, BPSi ... BPSN). Once the boost per source is calculated across each dataset, the sum of all values of boost per source per pixel ("CTSTB") is calculated to arrive at the total amount of boost in the composite surface.

Equation 5: / = SUM(BPS ₀ , BPSi ... BPSN)

[00213] The CRS is created by computing the percentage of total boost (risk mitigation) in related to the CTS pixel values.

Equation 6: / = CTSTB/CTS ^* 100

[00214] Both the CTSTB and the CRS may be visually displayed to a user as a surface. The values may be symbolized as elevations or by using graduated visualization techniques such as heat maps

[00215] Figures 12 through 17 represent an exemplary calculation of a two- dimensional CCS from data sources So, Si , and S2 for a risk of 0%, wherein the data sets are comprised of the following values which represent elevation:

Table 3

[00216] A visual representation of these values is shown in Fig. 12. Data sources So, Si , and S2 are assigned to various confidence classes and given boost factors to compensate for lack of confidence (1 .0, 1 .2, and 1 .2 respectively). The values for the boosted surfaces - SO, S'i , and S'2 - are as follows:

Table 4

[00217] A visual representation of these values for 0% risk is shown in Fig. 13. Fig. 14 shows the CTS calculated by using Equation 1 . Fig. 1 5 shows the amount of boost per source, by applying Equation 2. A composite showing the CCS, calculated using Equation 3, is shown in Fig. 16. The percentage of boost in the overall composite (CRS) is calculated pursuant to Equations 4 through 6, with the results displayed as a surface in Fig. 17.

[00218] For 10% risk, the minimum value of each pixel across the data sets is determined, as shown in Fig. 19. Put another way, the lowest elevations identified for a geographic areas of interest are selected. Applying a 10% risk mitigation means first determining for each pixel whether or not values of SO, S'i , and S'2 are greater than the lowest elevations. If they are then the values of SO, S'i , and S'2 remain in the dataset. If they are not, then the minimum values replace them. Put another way, the least conservative values are never smaller than the lowest values in the source. Continuing the above example using So, Si , and S2, the minimum values are:

Table 5

[00219] Applying the 10% risk mitigation results in the following values for SO,

Table 6

[00220] These values are represented in Fig. 19. Figs. 20 - 23 depict visual representations of a CTS surface, boost per source, a CCS surface, and a CRS surface, all with 10% risk mitigation.

[00221 ] Applying a 90% risk mitigation to SO, S'i , and S'2 in the same manner results in the following values for SO, S'i , and S'2: Table 7

[00222] Figs. 24 -26 depict visual representations of a CTS surface, a CCS surface, and a CRS surface, all with 90% risk mitigation. As can be seen from a comparison of Figs. 26 and 23, there is much higher boost required to mitigate a 90% risk than with a 1 0% risk.

[00223] One of ordinary skill in the art will appreciate that because the CCS, like the CTS, is a raster surface, the level of disagreement between the data sets can be symbolized using graduated visualization techniques. For example, colors can be used to identify the levels of disagreement (i.e., be presented as a "heat map"). The color red and similar hues may be used to represent high levels of disagreement, and yellows and greens representing moderate to low levels of disagreement. A scale may be provided to associate a particular color or other visual identifier with a corresponding level of disagreement. A color gradient or other gradient can allow a viewer can appreciate the level of disagreement between data sets from a quick visual inspection of the surface.

[00224] One of ordinary skill in the art will also appreciate that although some examples have been provided using data sources with a single row of values, 3- D spatial analysis and 3-D surfaces may be created through the use of multi-row and multi-column raster matrices.

[00225] Referring to Figs. 33-36, an exemplary embodiment of 3-D virtual surface generation based upon multiple input data sets for an area of interest is shown. The area of interest is the Part 77 primary surface of the airport runways at the Tucson International Airport in Arizona (ICAO code: KTUS). A flow chart, shown in Fig. 27, diagrams the process of modeling three surfaces (CCS, CRS, and CTS) from four input data sets. The four input data sets are (1 ) Part 77 surface; (2) USGS digital elevation model (DEM) surface; (3) Shuttle Radar Topography Mission (SRTM) surface; and (4) a digital obstacle file (DOF) pre- processed to include a spline tension surface applied over the DOF obstacles. Visual images of each of the four input data sets are shown in Figs. 28-32, including images of the DOF file before and after spline tension surface processing (Figs. 31 and 32). A view of a composite of the four input data sets is shown in Fig. 33.

[00226] In this exemplary embodiment, the CTS is generated according to the following rule base which applies the following boost factor coefficients to compensate for pre-determined confidence in the data sets and resulting risk:

Table 8

[00227] Pursuant to Equation 1 set forth above, a virtual 3-D CTS 10 is generated and visually displayed to a user as shown in Fig. 34. As shown in this exemplary embodiment, the generated CTS 10 is graphically shown in combination with the composite of the four input data sets. Its floating appearance is the result of the boost factors applied to the data sets and the max function of Equation 1 .

[00228] Referring to Fig. 35, a virtual CCS 20 generated according to Equations 2 and 3 above is displayed with the CTS 10. In this embodiment, the CCS 20 is visually presented to the user as a "heat map" where green indicates a low degree of agreement (consilience) between the data sets and red indicates a high degree of agreement (consilience) between the data sets. Although in Fig. 35 the only other visual indication is the KTUS runway 100, it will be appreciated that the CCS 20 could be visually displayed to a user along with the original data sets or other surfaces or volumes as desired by the user. Furthermore, instead of using a heat map the CCS 20 could be represented as a function of elevation or in other graphical ways that indicate the varying levels of consilience between the data sets.

[00229] Referring to Fig. 36, a virtual CRS 30 generated according to Equations 4-6 above is displayed as a heat map on the CTS 10. In this embodiment, the CRS values are represented according to interval classes where blue indicates low risk (-25% to -26%); yellow indicates mid risk (-28%); and brown indicates high risk (-30%). In various embodiments different interval classes or ways of representing the CRS may be utilized.

[00230] One or more AVS datasets may be presented to a user in a variety of ways. For example, instead of or in addition to surface like that presented in FIGS.24-26, the results of a AVS determination may be presented in a manner like or similar to that illustrated in FIGS. 37 and 38. In FIG. 37, multiple generated AVS surfaces (surfaces A, B, and C) are shown over a series of obstacles. In an exemplary embodiment, providing the user with multiple AVS surfaces at once, where each surface represents a different level of risk, allows the user to visually appreciate how risk may be mitigated, an aid in decisions regarding flight operations and/or aircraft performance.

[00231 ] In FIG. 38, a number of exemplary obstacles in the form of vegetation, a radio tower and a building are shown to reside in an area surrounding an airport that is generally indicated as being devoid of obstacles based on one or more typical sources of available information. However, after employing an AVS generation technique such as that described above, it is determined that obstacles exist and an AVS is developed and applied to the area of interest. As the obstacles may interfere with a departing aircraft, the AVS can be used to visually indicate the percentage of risk of not clearing one or more of the obstacles on takeoff for various flight paths having different performance characteristics. In this particular example, the performance characteristics of each flight path is indicated as a height above the runway at a given distance from brake release (i.e., a climb rate). Each flight path is also designated as having a particular percentage of risk.

[00232] It can be understood from FIG. 38 that AVS generation functionality may be a feature of a risk-enabled and performance-based procedure modeling and design technique. For example, once an AVS is generated, the AVS may be used along with other information to determine risk-based flight procedures. Such a risk-enabled and performance-based procedure modeling and design technique may also require the functionality and/or data associated with more than one product/function of an exemplary system embodiment. For example, such a modeling and design technique may incorporate planning, regulatory compliance, performance calculations, and charting functionality. The basic concept of using an AVS in risk-enabled and performance-based procedure modeling and design is represented generally in FIG. 39.

[00233] Datasets created by the systems and methods described herein could be exported and distributed for use by outside software applications. The datasets contain elevation data, among other information, which may be used by a variety of outside software applications including flight performance software, flight operations software, etc.

[00234] In an exemplary embodiment, a software system is provided that allows a user the ability for AVS generation, and the ability to manipulate surfaces and change various attributes as desired. Such a system may allow a user to select any location or pixel and see the elevational data and other associated information for that value or pixel. The software system may allow for the import/export of data sources and created data sets. The software system may also receive updates to data sources in real time.

[00235] The ability to distribute a multi-layer surface (for example, a CSS and CRS composite) requires a novel solution. Generally, the distribution of gridded data is achieved through available raster file formats such as GeoTIFF and ArcGrid. Many available raster file formats support multi-band information storage. The bands may store red, green, and blue (RGB) values, or any portion of the electromagnetic spectrum. The type of data in each individual band/channel does not have to be the same. For example, a raster file with three bands could store data as (FLOAT, INT, INT).

[00236] A novel solution for distributing a multi-layer surface is to use a multi- band raster format to encode the CCS and CRS data sets, for example. Accordingly, each pixel contains the values from the CCS and CRS data sets.

[00237] Although the AVS systems and methods described herein are aimed at applications in the aviation industry, the same systems and methods can be applied in other industries as well, including, but not limited to, the general automobile industry, the autonomous car industry, the submarine and submersible industry, and the drone industry. [00238] As previously mentioned, exemplary system and method embodiments may include aircraft performance calculation functionality. The aircraft performance calculation functionality is intended to provide a risk-based performance data computation platform that allows the associated exemplary system to calculate limiting takeoff and landing performance, and to present a user with the numerical and visual risks associated with the performance calculation process, flight procedure design, and weight and balance assumptions. In the context of flight operations, this allows a user to understand the risks associated with a given procedure, with performance, or with weight and balance decisions - in other words, to balance risk and return. Such a method of flight procedure design differs from typical methods in that it employs procedure-based performance calculations as opposed to those based on, for example, a runway analysis.

[00239] In this regard, FIG. 40 illustrates an exemplary data entry page of an exemplary performance calculation product/function of such a system. As shown in FIG. 40, a user may select a particular aircraft for which to undertake a performance calculation. The system facilitates the input of various other information for use in the performance calculation. For example, and without limitation, performance may be calculated with respect to a given airport and a particular runway at said given airport. The condition (e.g., wet/dry) of the runway may also be input, as may, without limitation, other airport/runway characteristics such as elevation, slope and runway length information (e.g., TORA, TODA, ASDA); aircraft conditions such as but not limited to weight, anti- ice and flap settings; and environmental conditions such as wind speed and direction, barometric pressure and temperature. METAR data may be provided as shown to assist a user with providing the required environmental input data.

[00240] Based on the input data, the exemplary performance calculation product/function then calculates a risk score in consideration of performance (i.e., most risky vs. most likely). Calculated risk scores in consideration of performance may be visually presented to a user in several ways. One example of such a visual presentation appears in FIG. 41 . In the exemplary presentation of FIG. 41 , several calculated possible departure flight paths are presented for a given aircraft, airport, runway, weather conditions, etc., as explained above. For purposes of illustration, risk scores are associated with some of the possible flight paths. While these exemplary risk scores use a combination of alphanumeric and numeric characters, other formats are of course also possible. The presentation of FIG. 41 also indicates the source(s) of data upon which each calculated flight path is based.

[00241 ] Upon selecting a flight path from the graphical presentation of FIG. 41 , a pilot or other user may be presented with numerical data in the form of a chart or table that will allow the given aircraft to maintain a like risk score with changes in environmental conditions (e.g., barometric pressure and/or temperature) and/or aircraft performance parameters (e.g., takeoff speed). One such exemplary data table is illustrated in FIG. 42, as may be presented to a user on a mobile device such as an iPad®, etc., for convenience and ease of use.

[00242] In making performance calculations, a performance calculation product/function of an exemplary system may also use data obtained from sources other than the data entry source illustrated in FIG. 40. For example, a performance calculation product/function of an exemplary system may import relevant data form other products/functions associated with the system. These other products/functions may include, without limitation, a terminal area and airport management product/function and a regulatory compliance product/function. In the former case, imported data may include data related to, for example, an initial straight area (ISA), an ISA extension, an extended ISA, and sectors of a circular bounding area of interest.

[00243] Another possible feature of an exemplary system embodiment is the ability to create a special departure procedure (SDP). One basic example of such a special departure procedure is a route special departure procedure (RSDP) that provides instructions and guidance for a one engine inoperative departure situation. A RSDP is described as being basic in nature herein because it includes only one route.

[00244] One example of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 43. As can be observed, this exemplary RSDP is associated with a departure from Runway 33 of the Aspen/Pitkin County Airport (KASE/ASE) in Aspen, Colorado, and includes instructions and route guidance for returning to KASE upon a one engine inoperative departure situation. A second example of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 44. This RSDP is also associated with a departure from Runway 33 of KASE, but is presented in portrait format as opposed to the landscape format of the RSDP of FIG. 43. Additionally, the RSDP of FIG. 18 directs an aircraft to the Rifle Garfield Regional Airport (KRIL) in Rifle, Colorado in the case of a one engine inoperative departure situation.

[00245] An exemplary enhanced version of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 45. In comparison to the RSDP charts of FIG. 43 and FIG. 44, the RSDP chart of FIG. 45 includes additional information. For example, the RSDP chart of FIG. 45 includes flight operation instructions that are superimposed along the flight path depicted on the chart for both an engine failure and all engines operating situation. The RSDP chart of FIG. 45 also includes specific flight operation procedures for an all engines operating takeoff, whereas the RSDP charts of FIGS. 43-44 simply instruct the user to follow the standard instrument departure (SID) associated with the nearby LINDZ waypoint. A number of unique SDP symbols also appear on the RSDP chart of FIG. 45 to provide additional weather, obstacle and other miscellaneous information to a user. A non-exhaustive collection of such SDP symbols are shown in enlarged form in FIG. 51 , along with a brief description of their meaning. These SDP symbols may be used on other types of SDP charts, such as for example, the exemplary SSDP charts described below and shown in FIGS. 47-49.

[00246] Another, novel, example of a special departure procedure is a sector special departure procedure (SSDP). Generally speaking, a SSDP takes into account the obstacle and terrain environment surrounding a given airport and presents different possible flight paths for a one engine inoperative departure situation depending on the given sector of a circular airport bounding area within which the aircraft is located. The determination of a SSDP may also consider various aircraft performance parameters, such as but not limited to, radii of turn corresponding to two selected speed values, nominal climb gradient, critical climb gradient for obstacle reporting, loss of climb gradient in turns, minimal profile used for obstacle filtering, and maximal value of the climb gradient. [00247] An exemplary process for determining a SSDP may include initially partitioning the surrounding circular airport bounding area into sectors, after which a specialized algorithm may deploy a simplified aircraft model to create a number of imaginary flight paths to each obstacle/terrain point in sector coverage, seeking the most critical case that results in maximal climb performance degradation. The algorithm may augment obstacle/terrain altitudes by a value corresponding to the loss of climb gradient along each of the flight paths and may sort all obstacles and terrain points for a sector by the distance along the corresponding flight path. These augmented and sorted obstacles and terrain points may then be pushed through a multi-step filtering process to produce a list of significant obstacles and terrain points which, if cleared, guarantee safety for one engine inoperative take off, reaching declared sector safe altitude.

[00248] FIG. 46 illustrates the above-described exemplary process for the construction of the flight paths for an obstacle. Each of the alternate flight paths is composed of an initial turn until reaching a direction to fly straight to the obstacle. When the path reaches the obstacle position, the flight path follows a climbing turn spiral trajectory to reach the sector safe altitude. These connected turns deliberately create the least favorable flight path, maximizing the loss of climb gradient. The climb gradient loss may be converted to an altitude decrement that may then be used to compute derived obstacle height and to compare these values for different flight paths.

[00249] One example of a SSDP producible by an exemplary system and method embodiment is illustrated in FIG. 47. As can be observed, the airspace surrounding the Fort Lauderdale Hollywood International Airport (KFLL/FLL) has been depicted to show a simple "single" sectorized departure along with other aeronautical features of relevance. The sectorized area in which the aircraft must remain is depicted by the large circle identified on its boundary by the central VOR (FLL 1 16.5) and the distance from the VOR/DME that the aircraft must remain (i.e., 25NM). The altitude that the aircraft must attain to avoid obstacles in any portion of the sector is identified beneath the name of the common sector "A" as 21 00ft Pressure Altitude. Closer to the runway is a small polygon which is referred to as the straight area. The straight area is the area within which an aircraft must initially attempt to fly along the extended runway centerline prior to turning into the sector. The straight area is also depicted in greater detail on the lower left hand part of the SSDP diagram, and is defined both by a series of latitude and longitude points, as well as a distance from a common NAVAID which, in this example, is the 2NM arc (depicted as a straight line on the top of the polygon) listed as FLL 2NM.

[00250] The exemplary SSDP of FIG. 47 also presents several other pieces of information that are important for pilots to consider during the use of the SSDP. For example, at the center of the SSDP chart is a depiction of the runways, including the runway for which the SSDP is intended. A compass, indicating magnetic variation from True North, is also indicated in the top right portion of this exemplary SSDP chart. The polygons outlined in blue on the SSDP chart represent different airspace boundaries that are controlled by communications over different frequencies. Furthermore, the grey sections of the primary sector indicate areas where the NAVAID used to create the primary sector may not provide a reliable reading.

[00251 ] Another example of a SSDP producible by an exemplary system and method embodiment is illustrated in FIG. 48. As can be observed, the airspace surrounding the Fort Smith Regional Airport (KFSM/FSM) has been divided 5 navigable sectors A through D, plus a sector labeled as "STRAIGHT". When using this exemplary SSDP, a pilot is able to choose which of the 5 sectors, or combinations thereof, the pilot intends to stay within in the event of an engine failure during takeoff. A given sector may only be entered into after maintaining a flightpath along the extended centerline through the straight area depicted in the lower left corner of the SSDP chart. This exemplary SSDP chart also indicates that larger aircraft that wish to utilize the "STRAIGHT" sector in an engine failure situation must delay entry into said sector until the aircraft has passed through the "EXT STRAIGHT AREA" depicted in the lower right corner of the SSDP chart. This required additional straight ahead flying distance without turning, ensures that the higher speeds and greater turn radii associated with larger aircraft will be contained completely within the "STRAIGHT" sector. In addition to the navigable sectors, this exemplary SSDP chart also indicates terrain in shades of brown, and hydrography information in shades of gray. Assorted notes are also incorporated into this SSDP chart example, including caution messages associated with Sectors A and D to indicate A-1 0 Warthog military aircraft could be flying low to the ground in those sectors.

[00252] FIGS. 49A-49B illustrates how the charting functionality of an exemplary system and method embodiment may permit a user to customize charts, such as by controlling the various layers that form a given chart. In this regard, FIG. 49A depicts an exemplary layer control menu where a user has elected to turn off Sector A and Sector C of the SSDP chart shown in FIG. 48. FIG. 49B represents the SSDP chart of FIG. 48 with Sector A and Sector C turned off according to the menu selections of FIG. 49A. Other layers may also be present and be controllable in other charts, as may other chart functionality.

[00253] At least from the foregoing written description of exemplary system and method embodiments and the related drawing figures, it should be apparent that one important aspect thereof is a shift toward the presentation of information in a visual, rather than textual, numeric or other format. For example and without limitation, exemplary system and method embodiments described herein may permit a user to better visualize the geospatial area around an airport, to visualize geospatial conflicts (and the de-confliction thereof), to visualize aircraft performance, and to visualize the risk associated with decisions about aircraft performance, flight operations, etc. Consequently, exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is capable of presenting, among other information, flight procedures, predicted aircraft locations and terminal area information, with real time reaction to changes in information.

[00254] The dynamic aeronautical charting functionality of an exemplary system embodiment may be employed in the production of a multitude of different charts related to flight planning and flight operations. For example, as shown in FIG. 51 , a dynamic aeronautical charting product/function of an exemplary system may be used to produce a SID chart. This exemplary SID chart is for Runway 1 B of the Keflavik International Airport (BIKF) in Iceland, but charts for other runways of other airports may also, of course, be generated. Similarly, a dynamic aeronautical charting product/function of an exemplary system may be used to produce an instrument approach chart as depicted in FIG. 52. The exemplary instrument approach chart of FIG. 52 is a GPS approach chart for Runway 01 L of the Andrews Airforce Base (KADW) in Camp Springs, Maryland, but instrument approach charts for other runways of other airports may also be generated. Another such instrument approach chart is shown in FIG. 53, with this exemplary chart being a DVOR/DME instrument approach chart for Runway 20 of the Paya Lebar Airport (WSAP) in Singapore.

[00255] The dynamic aeronautical charting functionality of an exemplary system embodiment may also interact with other products/functions of the system to generate relevant charts or other visual presentations (see generally the ACE element of FIG. 2 in this regard). For example, a dynamic aeronautical charting product/function of an exemplary system may receive an output of information from a terminal area and airport management product/function (or another product/function) of the system and use said information to produce a terminal/airport area chart, a risk probability surface chart (see, e.g., FIGS. 1 1 - 12), or any of a multitude of other charts associated with airport management, flight operations planning, etc. Similarly, for example, a dynamic aeronautical charting product/function of an exemplary system may receive an output of information from a performance calculation product/function (or other product/function) of the system and use said information to produce a visual indication of aircraft performance, a visual indication of risk in consideration of performance (see, e.g., FIG. 41 ), etc.

[00256] The dynamic aeronautical charting functionality of an exemplary system embodiment may also include an enhanced ability to visually present an aircraft flight path, including the integration of previously accepted or selected engine failure procedures, or procedures associated with other normal and non- normal operating configurations. This ability is reflected, for example, in the RSDP charts of FIGS. 43-45 and the SSDP charts of FIGS. 47-48. Another such exemplary chart that is representative of such a charting ability is illustrated in FIG. 54. As can be observed, the chart of FIG. 54 is directed to a departure from a particular runway of a given airport (i.e., Runway 17R of Henderson Executive Airport in Las Vegas, Nevada), and includes a detailed visual depiction of a planned or suggested waypoint-based flight path for both an all engines operative (AEO) or one engine inoperative (OEI) departure situation. [00257] The dynamic aeronautical charting functionality of an exemplary system embodiment may be further operative to facilitate or enhance the chart generation and/or analysis process. For example, as represented in FIGS. 55- 56, the dynamic aeronautical charting functionality of exemplary system and method embodiments described herein may be adapted to automatically highlight a graphical depiction of flight procedure information (e.g., a route segment) when a user selects (e.g., clicks on or taps on) corresponding flight procedure information presented in textual form, or to automatically highlight flight procedure information presented in textual form when a user selects a graphical depiction of said flight information. In this particular example, the result is that the associated textual and graphical flight procedure information (route segments) are thereafter highlighted in green.

[00258] The dynamic aeronautical charting functionality of an exemplary system embodiment may be further employed in the process of predictive flight path modeling, which may be a feature of the dynamic aeronautical charting product/function, a performance calculation product/function, or some other product/function or combination of products/functions of an exemplary system embodiment. More specifically, a dynamic aeronautical charting product/function of an exemplary system embodiment may be used to visually display a predicted flight path, such as a predicted departure flight path.

[00259] One exemplary embodiment of visually displaying a predicted flight path is depicted in FIG. 57. FIG. 57 is intended to be representative of a SID chart, but with textual and other information removed for clarity. As shown in FIG. 57, the planned/expected SID departure from this hypothetical runway generally calls for a right turn at the 5 nautical mile mark from runway end, followed by a slow turn back to the left to intercept the VOR path to an initial waypoint indicated as WP 1 .

[00260] The exemplary enhanced chart of FIG. 57 also novelly includes a predicted flight path that deviates from the anticipated SID flight path. Predictive flight path modeling may be performed, for example, as briefly described above. An exemplary system and method embodiment may calculate the predicted flight path based on a number of factors, such as without limitation, aircraft performance and/or weight and balance factors, and environmental factors such as temperature, pressure, crosswind speed, etc.

[00261 ] In any case, it has been determined in the example of FIG. 57 that, for one or more reasons, a given aircraft of interest departing from the depicted runway will most likely deviate from the planned SID flight path. This deviation is indicated (by the dashed line) on the chart of FIG. 57 as the predicted actual flight path of the aircraft during departure. As may be observed, a visual depiction of the predicted actual flight path versus the planned SID flight path may be very useful, as in this example where such a deviation alters the flight path around an obstacle.

[00262] As would be well understood by one of skill in the art, flight planning - particularly with respect to flights that require extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing - may be challenging. During flight planning, there is a need for a visual means of ensuring there exists an escape path to airports within gliding range of a planned flight path. Similarly, there is a need for a visual means of ensuring the presence of airports along the planned flight path at which a special missed approach procedure (SMAP) may be executed.

[00263] Other flight planning difficulties also exist. For example, scheduled air carriers (FAR Part 1 21 operators) and commuter and on-demand carriers (FAR Part 135 operators) are often faced with challenging single engine net ceiling and terrain clearance issues (e.g., 7,1 00ft; Anti-Ice On). Such operators need a better flight planning solution than is currently available. Furthermore, there is a need for dispatchers and flight followers to be able to see and react to changes in the flight path of an aircraft with updated performance limitations as the flight proceeds.

[00264] Analysis has also revealed that, while flight planning that properly considers diversions to alternate airports in emergency situations actually requires a continued engineering analysis, most operators do not undertake such additional analysis. Similarly, most operators do not want to limit takeoff or landing weight to accommodate such a possibility.

[00265] In light of these industry needs and issues, an exemplary system and method embodiment according to the present application may further include airborne emergency decision-making functionality. More specifically, an exemplary system may include an airborne emergency decision-making product/function that is adapted to provide visual feedback to relevant aviation industry personnel regarding the safest paths to take when experiencing an enroute emergency situation. Such airborne emergency decision-making functionality is of particular, but not exclusive, importance with respect to flights that require extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing. Such functionality and the information provided thereby may be relevant to aviation industry personnel such as, for example and without limitation, flight crews, dispatchers, flight followers, pilots and controllers.

[00266] An airborne emergency decision-making product/function of an exemplary system embodiment may be operative to, for example and without limitation: create a visual performance solution that satisfies enroute regulatory compliance and risk management requirements; support advanced terrain clearance calculations for all operating regulations; support advanced extended- range twin-engine operational performance standards (ETOPS) for all operating regulations; create a seamless transition between terminal area aircraft performance and enroute aircraft performance that allows a user to manage the risk levels; and create a solution that simultaneously supports pilots and planners in mobile disconnected mode or in an ASD/Flight planning tie-in. As with other possible products/functions of an exemplary system embodiment, an exemplary airborne emergency decision-making product/function may utilize the same aeronautical, geospatial and other data stored in a common database (e.g., TEAMDB). Utilizing common data ensures, for example, that users are flight planning based on the same terrain and obstacle considerations.

[00267] An airborne emergency decision-making product/function of an exemplary system embodiment may also provide a semi-automated method for the sectorized handling of potential descent paths based on common navigational points over terrain, or based on an AVS. An exemplary visual depiction of such airborne emergency decision-making functionality - including the sectorized handling of potential descent paths - appears in FIG. 58. [00268] Yet other exemplary system and method embodiments may include a visual interface to regulatory compliance and performance impact analysis. More particularly, an exemplary system embodiment may be adapted to collect, visualize, and associate collections of, textual information, data tables, business processes, regulations, manuals, guidance materials and other sources of an electronic nature through a semi-automated or fully automated process

[00269] An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to establish connections between different areas of aviation services, which promotes information sharing and use. An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to encourage community interaction, thereby helping to ensure that information is as current and accurate as possible. An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to more clearly indicate to a user, such as through a visual presentation of information, how a given change will affect other systems, rules, compliance, etc. An exemplary visual interface to regulatory compliance and performance impact analysis may also be functional to notify users if relevant performance or other data changes.

[00270] Additionally, because much of the information that will be collected, visualized, and/or associated by an exemplary visual interface to regulatory compliance and performance impact analysis is likely to be textual in nature, an exemplary visual interface product/function may be adapted to parse complex textual information into components which can more easily be linked or associated with other textual information in a graphical database, for ultimate visualization to an end user. A diagrammatic functional representation of one exemplary visual interface to regulatory compliance and performance impact analysis product/function is shown in FIG. 59.

[00271 ] As briefly discussed previously, an exemplary system embodiment may comprise a suite of individual, but possibly interacting, products. Such an embodiment may be analogous to, for example, the Microsoft® Office suite of products, wherein a plurality of individual products/applications provide different functionality within the product suite, and wherein at least some of the products are able to share information with or use information from some of the other products. Access to the various product functionality in such an embodiment may be controlled, for example, by controlling the purchase of, or the license associated with, each product. Alternatively, all of the available products of an exemplary system may be present but locked out or otherwise deactivated based on user license level, etc.

[00272] Alternatively, all of the functionality of the aforementioned series of individual products of a product suite may instead be imparted to one product. In such an exemplary system embodiment, a user may simply be directed to select the type of task to be performed as opposed to selecting a particular product that the user assumes to be the correct product for performing the desired task. Access to various functionality may again be controlled, for example, by license level, etc.

[00273] As also previously described, the various products/functions or areas of various functionality of an exemplary system embodiment, may retrieve (and/or send) data to a common database of aeronautical, geospatial, and/or other information. The various products/functions or areas of various functionality of an exemplary system embodiment may also share information in various ways to accomplish a particular task. For example, a charting engine may receive data from one or more system products/functions, in order to visually present information to a user.

[00274] It should also be noted that the various products/functions of an exemplary system embodiment may all or selectively be provided with the ability to operate in a cloud-based environment, such as but not limited to the ability to communicate with a common database via a web browser and mobile applications. At least some of the various products/functions of an exemplary system embodiment may also, or instead, be adapted so as to be provided as mobile solutions, such as on a non-connected or intermittently connected mobile device.

[00275] While certain exemplary system and method embodiments are described in detail above, the scope of the invention is not considered limited by such disclosure, and modifications are possible without departing from the spirit of the invention as evidenced by the following claims: