WET Water Resources: A Google Earth Engine Python API Tool to Automate Wetland Extent Mapping Using Radar Satellite Sensors for Wetland Management and Monitoring
Explore the source record for details and available documents.
Lori Berberian↗
SEARCH · Engineering Papers
Results for “API,”
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
InVEST Urban Development: Incorporating Earth Observation Data into the Integrated Valuation of Ecosystem Services and Tradeoffs (InVEST) Urban Flood Risk Mitigation Model Python API
Urban flooding poses as one of the biggest issues for cities today as its impacts are amplified by both climate change and urbanization. The Natural Capital Project’s Integrated Valuation of Ecosystem Services and Tradeoffs (InVEST) Urban Flood Risk Mitigation (UFRM) model, which benefits from its simplicity and robustness, is commonly used in NASA DEVELOP projects for disaster mitigation, urban planning, and environmental justice issues. While the InVEST UFRM model was able to produce the surface water runoff and retention map sufficient for the scopes of past projects, the model’s accuracy and spatial variability need improvement. Since the current InVEST UFRM model employs constant rainfall depth for all pixels in the area of interest (AOI), the model suffers from inaccurately estimating rainfall depth, runoff volume, and flood depth. Therefore, we adapted the model so that satellite-based precipitation raster datasets (i.e., Integrated Multi-satellitE Retrievals for Global Precipitation Measurement [GPM IMERG]) can be used instead of a single constant value. We simulated the flood events on August 21st and August 22nd, 2017, in Wyandotte County, Kansas using both our modified and the original InVEST UFRM model and then compared the results after incorporating rainfall raster into the model. Areas with developed land on the land use map predicted moderate to high flood volume in the original volume regardless of the actual amount of precipitation. The modified model considered the rainfall depth’s spatial variation achieving less overestimation of flood runoff and volume at low-to-moderate rainfall area.
Urban flooding↗
A Framework Approach for Evaluation of Potential Degradation of APIs for Long-Duration Spaceflights
Explore the source record for details and available documents.
Andrey Massarsky↗
An Application Programming Interface for Synthetic Snowflake Particle Structure and Scattering Data
The work by Kuo and colleagues on growing synthetic snowflakes and calculating their single-scattering properties has demonstrated great potential to improve the retrievals of snowfall. To grant colleagues flexible and targeted access to their large collection of sizes and shapes at fifteen (15) microwave frequencies, we have developed a web-based Application Programming Interface (API) integrated with NASA Goddard's Precipitation Processing System (PPS) Group. It is our hope that the API will enable convenient programmatic utilization of the database. To help users better understand the API's capabilities, we have developed an interactive web interface called the OpenSSP API Query Builder, which implements an intuitive system of mechanisms for selecting shapes, sizes, and frequencies to generate queries, with which the API can then extract and return data from the database. The Query Builder also allows for the specification of normalized particle size distributions by setting pertinent parameters, with which the API can also return mean geometric and scattering properties for each size bin. Additionally, the Query Builder interface enables downloading of raw scattering and particle structure data packages. This presentation will describe some of the challenges and successes associated with developing such an API. Examples of its usage will be shown both through downloading output and pulling it into a spreadsheet, as well as querying the API programmatically and working with the output in code.
reflectivity properties of snowflakes↗
Using Social Media and Mobile Devices to Discover and Share Disaster Data Products Derived From Satellites
Data products derived from Earth observing satellites are difficult to find and share without specialized software and often times a highly paid and specialized staff. For our research effort, we endeavored to prototype a distributed architecture that depends on a standardized communication protocol and applications program interface (API) that makes it easy for anyone to discover and access disaster related data. Providers can easily supply the public with their disaster related products by building an adapter for our API. Users can use the API to browse and find products that relate to the disaster at hand, without a centralized catalogue, for example floods, and then are able to share that data via social media. Furthermore, a longerterm goal for this architecture is to enable other users who see the shared disaster product to be able to generate the same product for other areas of interest via simple point and click actions on the API on their mobile device. Furthermore, the user will be able to edit the data with on the ground local observations and return the updated information to the original repository of this information if configured for this function. This architecture leverages SensorWeb functionality [1] presented at previous IGARSS conferences. The architecture is divided into two pieces, the frontend, which is the GeoSocial API, and the backend, which is a standardized disaster node that knows how to talk to other disaster nodes, and also can communicate with the GeoSocial API. The GeoSocial API, along with the disaster node basic functionality enables crowdsourcing and thus can leverage insitu observations by people external to a group to perform tasks such as improving water reference maps, which are maps of existing water before floods. This can lower the cost of generating precision water maps. Keywords-Data Discovery, Disaster Decision Support, Disaster Management, Interoperability, CEOS WGISS Disaster Architecture
0↗
DIP for Service Providers
The second DIP workshop’s topic is DIP for Service Providers. The workshop presentation covers topics such as DIP onboarding process, service authentication, catalog service capabilities, API requirements, NASA services and their access points, and data requirements for service providers. The Onboarding Process describes the required documentation that enables to collaborate with NASA as well as other industry partners through DIP. Also, step by step approach for the partner to take to register services or consme services through the DIP platform. The Catalog Service describes the different ways for the users to search for services that are of interest as well as registering services to the platform, so other users can search and discover. The API Requirements and Service Specifications describes the benefits of DIP's API management approach via API Gateway where services are managed centrally but ownership is decentralized and partners completely own the administration of their own services. NASA Services and Data Access Points topic describes the services, both data access service and machine learning prediction service, that NASA provides via the DIP platform in near time and post operations via REST API endpoints defined on the API Gateway. Also, NASA's approach for data storage process is explained. The Data Requirements for service providers describes the requirements for storing and exposing to support the performance of services that are provided by the service providers. Lastly, NASA's technology development plan with preliminary scheduler will be presented. There will be a Q&A session at the end of each segment of the presentation to solicit feedback from the participants.
ATM-X↗
HDF-EOS 2 and HDF-EOS 5 Compatibility Library
The HDF-EOS 2 and HDF-EOS 5 Compatibility Library contains C-language functions that provide uniform access to HDF-EOS 2 and HDF-EOS 5 files through one set of application programming interface (API) calls. ("HDFEOS 2" and "HDF-EOS 5" are defined in the immediately preceding article.) Without this library, differences between the APIs of HDF-EOS 2 and HDF-EOS 5 would necessitate writing of different programs to cover HDF-EOS 2 and HDF-EOS 5. The API associated with this library is denoted "he25." For nearly every HDF-EOS 5 API call, there is a corresponding he25 API call. If a file in question is in the HDF-EOS 5 format, the code reverts to the corresponding HDF-EOS 5 call; if the file is in the HDF-EOS 2 format, the code translates the arguments to HDF-EOS 2 equivalents (if necessary), calls the HDFEOS 2 call, and retranslates the results back to HDF-EOS 5 (if necessary).
Ullman, Richard↗
A simulation study of the recession coefficient for antecedent precipitation index
The antecedent precipitation index (API) is a useful indicator of soil moisture conditions for watershed runoff calculations and recent attempts to correlate this index with spaceborne microwave observations have been fairly successful. It is shown that the prognostic equation for soil moisture used in some of the atmospheric general circulation models together with Thornthwaite-Mather parameterization of actual evapotranspiration leads to API equations. The recession coefficient for API is found to depend on climatic factors through potential evapotranspiration and on soil texture through the field capacity and the permanent wilting point. Climatologial data for Wisconsin together with a recently developed model for global isolation are used to simulate the annual trend of the recession coefficient. Good quantitative agreement is shown with the observed trend at Fennimore and Colby watersheds in Wisconsin. It is suggested that API could be a unifying vocabulary for watershed and atmospheric general circulation modelars.
Choudhury, B. J.↗
Quantifying spatial and temporal variabilities of microwave brightness temperature over the U.S. Southern Great Plains
Spatial and temporal variabilities of microwave brightness temperature over the U.S. Southern Great Plains are quantified in terms of vegetation and soil wetness. The brightness temperatures (TB) are the daytime observations from April to October for five years (1979 to 1983) obtained by the Nimbus-7 Scanning Multichannel Microwave Radiometer at 6.6 GHz frequency, horizontal polarization. The spatial and temporal variabilities of vegetation are assessed using visible and near-infrared observations by the NOAA-7 Advanced Very High Resolution Radiometer (AVHRR), while an Antecedent Precipitation Index (API) model is used for soil wetness. The API model was able to account for more than 50 percent of the observed variability in TB, although linear correlations between TB and API were generally significant at the 1 percent level. The slope of the linear regression between TB and API is found to correlate linearly with an index for vegetation density derived from AVHRR data.
Choudhury, B. J.↗
A proposed application programming interface for a physical volume repository
The IEEE Storage System Standards Working Group (SSSWG) has developed the Reference Model for Open Storage Systems Interconnection, Mass Storage System Reference Model Version 5. This document, provides the framework for a series of standards for application and user interfaces to open storage systems. More recently, the SSSWG has been developing Application Programming Interfaces (APIs) for the individual components defined by the model. The API for the Physical Volume Repository is the most fully developed, but work is being done on APIs for the Physical Volume Library and for the Mover also. The SSSWG meets every other month, and meetings are open to all interested parties. The Physical Volume Repository (PVR) is responsible for managing the storage of removable media cartridges and for mounting and dismounting these cartridges onto drives. This document describes a model which defines a Physical Volume Repository, and gives a brief summary of the Application Programming Interface (API) which the IEEE Storage Systems Standards Working Group (SSSWG) is proposing as the standard interface for the PVR.
Jones, Merritt↗
Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes
Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.
DiNucci, David C.↗
CAPRI: A Geometric Foundation for Computational Analysis and Design
CAPRI is a software building tool-kit that refers to two ideas; (1) A simplified, object-oriented, hierarchical view of a solid part integrating both geometry and topology definitions, and (2) programming access to this part or assembly and any attached data. A complete definition of the geometry and application programming interface can be found in the document CAPRI: Computational Analysis PRogramming Interface appended to this report. In summary the interface is subdivided into the following functional components: 1. Utility routines -- These routines include the initialization of CAPRI, loading CAD parts and querying the operational status as well as closing the system down. 2. Geometry data-base queries -- This group of functions allow all top level applications to figure out and get detailed information on any geometric component in the Volume definition. 3. Point queries -- These calls allow grid generators, or solvers doing node adaptation, to snap points directly onto geometric entities. 4. Calculated or geometrically derived queries -- These entry points calculate data from the geometry to aid in grid generation. 5. Boundary data routines -- This part of CAPRI allows general data to be attached to Boundaries so that the boundary conditions can be specified and stored within CAPRI s data-base. 6. Tag based routines -- This part of the API allows the specification of properties associated with either the Volume (material properties) or Boundary (surface properties) entities. 7. Geometry based interpolation routines -- This part of the API facilitates Multi-disciplinary coupling and allows zooming through Boundary Attachments. 8. Geometric creation and manipulation -- These calls facilitate constructing simple solid entities and perform the Boolean solid operations. Geometry constructed in this manner has the advantage that if the data is kept consistent with the CAD package, therefore a new design can be incorporated directly and is manufacturable. 9. Master Model access This addition to the API allows for the querying of the parameters and dimensions of the model. The feature tree is also exposed so it is easy to see where the parameters are applied. Calls exist to allow for the modification of the parameters and the suppression/unsuppression of nodes in the tree. Part regeneration is performed by a single API call and a new part becomes available within CAPRI (if the regeneration was successful). This is described in a separate document. Components 1-7 are considered the CAPRI base level reader.
Haimes, Robert↗
Doclet To Synthesize UML
The RoseDoclet computer program extends the capability of Java doclet software to automatically synthesize Unified Modeling Language (UML) content from Java language source code. [Doclets are Java-language programs that use the doclet application programming interface (API) to specify the content and format of the output of Javadoc. Javadoc is a program, originally designed to generate API documentation from Java source code, now also useful as an extensible engine for processing Java source code.] RoseDoclet takes advantage of Javadoc comments and tags already in the source code to produce a UML model of that code. RoseDoclet applies the doclet API to create a doclet passed to Javadoc. The Javadoc engine applies the doclet to the source code, emitting the output format specified by the doclet. RoseDoclet emits a Rose model file and populates it with fully documented packages, classes, methods, variables, and class diagrams identified in the source code. The way in which UML models are generated can be controlled by use of new Javadoc comment tags that RoseDoclet provides. The advantage of using RoseDoclet is that Javadoc documentation becomes leveraged for two purposes: documenting the as-built API and keeping the design documentation up to date.
Barry, Matthew R.↗
Application Program Interface for the Orion Aerodynamics Database
The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced
Robinson, Philip E.↗
Pulmonary Inflammatory Responses to Acute Meteorite Dust Exposures - to Acute Meteorite Dust Exposures - Exploration
New initiatives to begin lunar and martian colonization within the next few decades are illustrative of the resurgence of interest in space travel. One of NASA's major concerns with extended human space exploration is the inadvertent and repeated exposure to unknown dust. This highly interdisciplinary study evaluates both the geochemical reactivity (e.g. iron solubility and acellular reactive oxygen species (ROS) generation) and the relative toxicity (e.g. in vitro and in vivo pulmonary inflammation) of six meteorite samples representing either basalt or regolith breccia on the surface of the Moon, Mars, and Asteroid 4Vesta. Terrestrial mid-ocean ridge basalt (MORB) is also used for comparison. The MORB demonstrated higher geochemical reactivity than most of the meteorite samples but caused the lowest acute pulmonary inflammation (API). Notably, the two martian meteorites generated some of the highest API but only the basaltic sample is significantly reactive geochemically. Furthermore, while there is a correlation between a meteorite's soluble iron content and its ability to generate acellular ROS, there is no direct correlation between a particle's ability to generate ROS acellularly and its ability to generate API. However, assorted in vivo API markers did demonstrate strong positive correlations with increasing bulk Fenton metal content. In summary, this comprehensive dataset allows for not only the toxicological evaluation of astromaterials but also clarifies important correlations between geochemistry and health.
Harrington, A. D.↗
Microphone Phased Array NetCDF/HDF5 Archival Files: Application Program Interface Reference
An application program interface (API) has been developed for the creation and access of structured data files generated by microphone phased arrays utilized in aeroacoustics research. Two structured binary file formats are supported, namely NetCDF (Network Common Data Form) and HDF5 (Hierarchical Data Format) files. The API consists of a library of routines callable from C, Fortran or Matlab, with native versions of the API provided for each language. The libraries are divided into categories for file handling, file definition and initialization, data writing, data recovery, and error handling. The API is intended to provide a mechanism for generating self-describing binary files for long-term archiving of raw and processed data generated by phased array systems.
Humphreys, William M., Jr.↗
Extending the Capabilities of Thermal Desktop with the OpenTD Application Programming Interface
With the release of Thermal Desktop 6.0, users now had the ability to interface with some of the many elements and constructs of a Thermal Desktop model through external applications developed using the TD API (Application Programming Interface). This file allows applications to be developed in the .NET framework and interface to a number of object types within a Thermal Desktop model. The release of 6.1 expands the subset of objects able to be manipulated and now includes the raw geometrical information of surfaces. With the release of 6.1, the API was now referred to as OpenTD. This paper discusses some of the utilities and capabilities developed using the OpenTD API at the NASA Goddard Space Flight Center. These include utilities to help with configuration control of models and case sets, addition of logic to better process heater performance, and a methodology implemented to allow for submodel level processing of radiation couplings to include smaller radks where needed in a cryogenic region without using the same criteria for the warmer portions of the model. This last utility is targeting a reduction in run time without sacrificing accuracy. Lastly, some lessons learned, work-arounds, and wishes for the next release of the OpenTD API are also presented.
Thermal Desktop↗
TOLNet’s FAIR Journey: Yesterday, Today, and Tomorrow
The Tropospheric Ozone Lidar Network (TOLNet) has generated over a decade of ozone vertical profile data products over North America and contributed to several air quality focused field studies. The science value of the TOLNet data has been demonstrated in numerous peer-reviewed publications on air quality and ozone relevant research. As the broad scientific community has moved towards adopting FAIR Principles to make data more findable, accessible, interoperable, and (re)usable, the TOLNet team has been consistently making data more FAIR. This effort has many challenges, partially reflecting on the FAIR principles being domain agnostic while the implementation needs to be domain specific. The FAIR principles declare the dependence on the community standards, domain-relevant metadata, and rich metadata. This presentation uses the TOLNet data and data system as an example to explore the best practices to implement FAIR principle. Particularly, we will examine the metadata and the “richness” to support findability and usability as well as machine-to-machine actionability via API. Last year, as part of our FAIR journey, we launched the TOLNet website (https://tolnet.larc.nasa.gov/) and the API (https://tolnet.larc.nasa.gov/api/). Part of this process included extracting and cataloging metadata across the entire TOLNet mission timeframe. This enabled users to search through the mission by various metadata criteria, improving the findability and accessibility. And computers could connect directly to the TOLNet API to extract both metadata and data, providing a level of interoperability never present before for TOLNet data. On top of that, all new TOLNet data is now automatically validated using the API to ensure it complies with GEOMS standards, aiding in reusability. It takes both technology and scientists working together to make progress. The next step is to evaluate the current TOLNet offerings against NASA’s Practical Guide for Open, Free & FAIR NASA Earth Science Data Products (https://doi.org/10.5067/DOC/ESCO/ESDSWG-0002V1).
TOLNet↗