Below are some of the most frequently asked questions we receive at OpenTopography. Don't see an answer to your question? Please e-mail us at firstname.lastname@example.org
OpenTopography is a distributor of free high-resolution, Earth science-oriented topographic data, related tools, and resources. For more information, visit the About section.
The OpenTopography Portal does not require any software to use other than a standards-compliant browser.
OpenTopography Portal supports most standards-compliant browsers. We actively support, test and troubleshoot issues on Google Chrome, Internet Explorer, Firefox and Safari. The 3D point cloud browser visualization function is tested and working with Google Chrome, Firefox and Safari, but not yet in Internet Explorer browsers. It is expected that most WebGL-capable browsers should be able to support this visualization.
You do not need an OpenTopography account to access and process lidar datasets. However, registering for an OpenTopography account has the following advantages:
1. Access to a personalized workspace.
2. Real-time status updates for your lidar jobs.
3. Access to previously submitted point cloud jobs.
4. Overview of point cloud processing statistics from your lidar jobs.
5. Increased job size limits
Log in to your myOpenTopo account and click the "Update Profile / Change Password" link under "My Account".
After filling out the registration form, you will be sent a confirmation notice to the email address provided. Click the link provided in the confirmation email to activate your account. Check your spam inbox if you cannot find the email right away. if you still have trouble logging in to your myOpenTopo account, please email us at email@example.com.
Users can apply for "Power User" status which will enable larger downloads per job (up to 350 million points with gridding services, or up to 500 million points for point cloud only). Users can apply for power user status in the MyOpenTopo section, and need to supply justification for the increased job limits.
Requests are more likely to be approved if users provide answers to the following questions:
All outlines indicate areas that have lidar coverage and are discoverable via OpenTopography. As you zoom in, the dots become polygons indicating lidar data coverage. Areas outlined in red represent data available through OpenTopography for download. Purple outlines are data that have been contributed to OpenTopography through the Community Contributed Data feature. Green outlines are part of an experimental program to provide access to the USGS 3DEP datasets. As of Jan 2021, USGS 3DEP data are only available to US academics with a valid .edu email account. This policy may change in future depending on future funding levels. To learn more about the USGS 3DEP program click here
You can view images representing the digital elevation models (DEMs) as hillshades (where the DEM is artificially illuminated) on your home computer using Google Earth. For more specialized work a geographic information system (GIS) is needed (e.g., ArcGIS, GlobalMapper, or QGIS). To work directly with the point cloud data software such as LASTools, CloudCompare, or PDAL could be useful. These programs let you interact with and analyze the elevation data.
No. Lidar data are available for many regions covering various Earth science-related disciplines such as hydrology, biology, and geomorphology. Please visit our data map for a web map showing data coverage, or for a listing of lidar datasets available on OpenTopography go to our data catalog . On the data catalog, note the tabs for the different classes of datasets: OT High Resolution, USGS 3DEP, Community Contributed, and Global datasets.
Currently, there are 16 datasets on OpenTopography that have concurrent orthoimagery:
The B4 dataset had orthophotos collected concurrently with the lidar survey. However, they are not available through OpenTopography because they were not acquired with a true photogrammetric camera and thus require additional processing. High-resolution aerial imagery is available via the U.S. Department of Agriculture National Agriculture Imagery Program (NAIP).
At present, OpenTopography does not directly host full waveform lidar data. However, OpenTopography links to the OpenAltimetry project which provides access to ICESat-1 datasets, which are full waveform, and cover the globe. OpenAltimetry also provides access to ICESat-2 datasets, which are derived from a photon counting instrument and also cover the entire globe.
From the data page, zoom in to the area of interest highlighted on the map using the navigation bars on the left. When you are close enough, click the blue "Select a Region" button below the zoom bar. Left-click and drag your mouse to create a box over your area of interest. Once you've selected the area, a list of available datasets and product formats for that area will appear below the map. Note that there are numerous tabs to classify the data that was found: OT High Resolution Topography, USGS 3DEP, OT Community Contributed, and Global data. If you are searching for data in an area with sparse data coverage, our global datasets will certainly cover the area. Click the "Get Data" button and navigate to the dataset landing page. Beside each step in the workflow, there is a grey "?" which has more information about the data products and concepts applied in that step.
Visit this page for comprehensive OpenTopography guides and tutorials.
Lidar topographic data processed and delivered as a standard digital elevation model (DEM) at the optimum resolution for the dataset often fit many users' needs. These data are typically delivered as bare earth (ground) and full feature (all returns) surfaces organized into tiles (e.g. 1 km2). The DEMs are in a GIS-compatible format and are compressed (zipped) to reduce their size.
Point cloud data are the first result from the laser scanner and may be the laser returns from the canopy, structures, and Earth's surface and are thus x,y,z points plus attributes. Creating a custom DEM from point cloud data lets the user define the area of interest and set the DEM-processing parameters which allows for more versatility and greater control over the dataset.
Visit this page for comprehensive OpenTopography guides and tutorials.
OpenTopography distributes some data as "tarballs," which is a specific compressed file format with the extension ".tar.gz". A ".tar.gz" file is a compressed archive file format similar to the more familiar .ZIP. OpenTopography writes out custom DEM data and point cloud files as .tar.gz files to make the files smaller and therefore convenient to download. Files downloaded from OpenTopography will look something like this: dems.tar.gz, where the .tar.gz indicates that it is a .tar file compressed with gzip compression. To work with a custom DEM product produced in OpenTopography, you first need to uncompress the .tar.gz file to access the actual DEM files which can be imported into a GIS.
There are several programs you can use to unzip lidar data. For Windows OS some common programs are: 7-Zip, winzip, winrar, and IZArc. For MAC OS, users can right-click on the file in Finder and select, 'Open with Archive Utility.app'.
For command line users: Type the following command in the directory where the '.tar.gz' files reside: tar -zxvf filename.tar.gz (replace 'filename.tar.gz' with the file you wish to uncompress).
NOTE: The command line command will work in UNIX, LINUX, and the Windows DOS command prompt.
After clicking the KMZ filename next to "Download KMZ file" in the "Visualization" section on the "Jobs Results" page, Google Earth should open automatically (Google Earth needs to be installed for this to work). If Google Earth does not open automatically, you can always right-click on the filename and select "Save link as" to save the file to your local machine and open the file directly from Google Earth. If Google Earth does not take you to your area of interest automatically, check the access window on the left-hand side of the screen. The new file should be under "Places." Click the box next to the file to turn it on and double-click the name to automatically zoom in to the area of interest on the map.
Yes, OpenTopography offers bulk data download of point cloud and raster data for registered users. The system is designed for advanced users seeking to download large amounts of data quickly and who have the bandwidth, expertise, and software necessary to manage the terabytes of data available. Data are stored in SDSC's Universal Scale Storage (USS) service offering, a Qumulo hybrid cloud file storage system. We expect that users accessing bulk data have the ability to automate downloads using the AWS Command Line Interface or other compatible GUI clients. To access bulk data download, log into OpenTopography and navigate to your dataset of interest. A "bulk download" link is visible on the dataset metadata landing page and above the point cloud and raster data download and processing maps. Click the "Bulk Download" link - a pop-up with a link to the bulk interface as well as specific details on how to automate downloads using both the AWS Command Line Interface and Cyberduck is shown.
If there are no OpenTopography datasets in your area, there are a couple of options to still acquire data. OpenTopography has 4 different global datasets that cover the globe at a variety of resolutions. These datasets are only available in raster format with resolutions ranging from 30 - 500 meters. If these global raster datasets are not sufficient and lidar point clouds are needed in an area with no data, OpenTopography provides access to the US Interagency Elevation Inventory (USIEI) catalog. Users can access the catalog by clicking the link under "Other Data Sources" of the webmap on the "Find Data" webmap. By using the USIEI catalog, users can get metadata, including info about data access, for other datasources throughout the US.
One of OpenTopography's primary goals is to democratize the distribution of lidar data to the Earth science community. For OpenTopography to achieve this, the collective needs of the Earth science community must be made known to OpenTopography. For example, what are some aspects of lidar technology in terms of data discovery, access, and integration that prevent the Earth science community from being able to carry out research in an efficient and timely manner? What new lidar tools and datasets do the Earth science community feel the need to be developed/made available? We invite members of the Earth science community to provide us with feedback that we hope will help shape the future of OpenTopography. Contact us for more information.
The OpenTopography Tool Registry provides a community-populated clearinghouse of software, utilities, and tools oriented towards handling, processing, and analyzing lidar data. Registered tools range from source code to full-featured software applications. We welcome contributions to the registry via the Contribute a Tool page.
To get an account on the Community Dataspace, users must apply through their MyOpenTopo portal and provide a detailed description of why their dataset would be appropriate for the OpenTopography Community. Users should provide details such as:
Each submission is reviewed by OpenTopography staff and approved on a case-by-case basis. For more information about the Community Dataspace, visit our Contribute Page . For detailed information on the Community Dataspace, how to apply, and how to upload data once approved is available in our tutorial document.
At OpenTopography we strive to make data access to quality topographic datasets as painless as possible . Unfortunately, OpenTopography does not have the resources to host all available lidar collections, and so we must prioritize which datasets we host. OpenTopography is a National Science Foundation (NSF) funded facility, and as a result, we only receive funding to host Earth Science related, research-grade, topographic datasets. We do have collaborations with non-NSF organizations, however, we receive separate funding for hosting those datasets. Basically, we do not have unlimited funding, and the hosting of local, state, and international lidar collections is not within the purview of our NSF funding, and would require a separate funding agreement.
We are always willing to work with new partners to host datasets. If there is a dataset that you would like to have available in OpenTopography, we encourage users to contact the owners of the datasets, and ask them to contact us with regards to a potential collaboration. We have a proven platform that makes lidar data much easier to use, and increases the return on investment for any lidar data collection.
OpenTopography data can be downloaded in LAS, LAZ or ASCII file formats. The following list describes each dataset type.
LAS: (from ASPRS): "The LAS file format is a public file format for the interchange of 3-dimensional point cloud data between data users. Although developed primarily for exchange of lidar point cloud data, this format supports the exchange of any 3-dimensional x,y,z tuplet. This binary file format is an alternative to proprietary systems or a generic ASCII file interchange system used by many companies. The problem with proprietary systems is obvious in that data cannot be easily taken from one system to another. There are two major problems with the ASCII file interchange. The first problem is performance because the reading and interpretation of ASCII elevation data can be very slow and the file size can be extremely large, even for small amounts of data. The second problem is that all information specific to the lidar data is lost. The LAS file format is a binary file format that maintains information specific to the lidar nature of the data while not being overly complex."
LAZ: The compressed form of a LAS file.
ASCII: Stands for American Standard Code for Information Interchange. ASCII files are text files containing information about the points in a dataset organized into columns. To define a point cloud, ASCII files must have x,y, and z point columns. The ASCII format is not unique to 3-dimensional point cloud data.
All datasets available via OpenTopography are multiple returns. Depending on the dataset, you can choose to download and produce DEMs for: bare earth points, vegetation returns, structure returns, or all returns. We retain all attributes for the datasets that we host, so if you choose to download the point cloud data you will find attribution for classification as well as return number. Intensity is occasionally available as well. To find out more about the classification of a specific dataset, access the full metadata and survey reports.
As of ASPRS LAS specification 1.4, files can have up to 15 returns per outgoing pulse. However, most systems have a limit of 4-5 returns per outgoing pulse. The "number_of_returns" attribute is the total returns for a given outgoing pulse. The "return_number" attribute is assigned as a number from 1 to 15 (as of LAS 1.4 spec) in a scheme that identifies which return is the last return recorded for a pulse:
First return with subsequent returns detected.
Second return with subsequent returns detected.
Third return with subsequent returns detected.
First return with no subsequent returns detected.
Second return with no subsequent returns detected.
Third return with no subsequent returns detected.
You should not expect each set of returns to have the same x and y position because the laser scanner is only perfectly vertical (at nadir) once per scan. For the rest of the scan the laser is pointing off nadir and hence the laser pulse passes obliquely through vegetation and will result in different x and y positions for returns from the same outgoing pulse. It is important to keep in mind that the point cloud is composed of multiple passes of the scanner over a survey area and therefore when you download points from OpenTopography, you are getting a merged point cloud back that represents all returns for the area you selected.
"Pulse number" is another way of saying collection time. Typically, each lidar point has an attribute indicating when the point was collected (in GPS time) in addition to the x, y, and z values. Sorting the data by collection time can be useful for identifying the geometry of the data acquisition, amount of swath overlap, and places where you may have edge artifacts from swath edges.
Some browsers - particularly older versions of Internet explorer - will try to open the LAS or LAZ file directly in the browser. Because the browser does not know how to read the lidar files, this will show up as a bunch of meaningless, random characters in the browser window. If this occurs, simply right-click on the lidar file and select, "Save link as..." to download the file locally. Lidar files can then be analyzed with tools such as: LAStools, CloudCompare, PDAL, or GIS software such as ArcGIS, GlobalMapper, etc.
Tile index shapefiles have been created for each data collection and can be downloaded from the "bulk" section of each dataset. The tile index file is a zipped shapefile with a naming convention of: DatasetShortname_TileIndex.zip (e.g. UT18_Dennison_TileIndex.zip). This shapefile will show the extent of each of the LAZ files so that users can download specific tiles of interest.
A digital elevation model (DEM) is a gridded representation of a surface with regular spacing between the grid nodes (sometimes called the resolution). DEMs are raster formatted representations of a surface. The term, "DEM" if often used interchangeable with digital terrain model (DTM), however, a DTM is a more specific term that refers to a gridded representation of the bare-earth surface of the ground. Conversely, a digital surface model (DSM) is a gridded representation of the lidar first returns, and is often used as a proxy for canopy height. Users can obtain a rough estimation of a canopy height model (CHM) by simply subtracting the DTM from the DSM.
Widely available DEMs are typically too coarse to provide adequate representation of small features (for example, the cell sizes in most USGS DEMs are 10-30 meters on a side). DEMs created from lidar datasets have a much higher resolution (often sub-meter), which allows the user to see more details of the landscape. They permit us to represent the landscape at the appropriate scale in which landforms can be delineated individually (in other words, at 10-30 meters on a side, a cell may contain a channel and a hillslope but can only delineate one of them, while at 0.5 m individual channels and hillslopes can be identified).
OpenTopography has a step in the workflow (step 3b, "Calculate point count") to calculate and visualize the point count for a given area. Each grid cell is populated with the number of points within the user defined search radius. This product can be exceptionally useful for evaluating lidar return concentration and allows users to better understand what resolution DEM the dataset will support.
In addition, ArcGIS has several tools for handling point cloud data. Assessing lidar coverage may be important before beginning any major processing on your machine. Visit the ArcGIS Assessing lidar coverage and sample density page to learn how to assess lidar coverage and density.
This typically happens when either (1) the user-defined search radius is not large enough, or (2) the density of the original point cloud is low. There are various factors that control the density of point clouds. These include the speed at which the scanner was flown, the scanning rate, the aircraft's average altitude, and the amount of overlap between each swath. As a result, point clouds contain a heterogeneous distribution of point densities. When you create a DEM in OpenTopography, elevation values of the spatially heterogeneous points are used to interpolate a regularly gridded surface. As a result, areas that do not have a sufficiently dense point coverage will produce "holes" in the DEM. There are two ways to handle this: (1) increase the search radius of the gridding method, or (2) use the null filling feature.
There is no precise rule about grid resolution, but ideally you would like each grid cell to be representative of at least a single elevation value. In most cases with lidar data, the cell value is calculated from a few points. Points2Grid (P2G), the gridding software developed by OpenTopography, essentially assumes that grid resolution is greater than point spacing (i.e. a 1 m DEM can be created from 3 shot/m2 data density), and thus it is appropriate to perform a local operation on the points (e.g. take the mean values in a search area around the grid cell center). If your shot spacing is greater than the grid resolution, you will need to use a true interpolator like a spline or kriging to fit a surface to the points and to fill the holes. Take a look at this page and this page to learn more about how P2G works.
As a rule of thumb, to determine what grid resolution is supported by a given lidar point cloud density, take the square root of the point density per unit area (e.g., 5 pts/meter2). Point densities for each lidar dataset can be found below the "Overview" section. For example, if a dataset has a point density of 5 pts/meter2, then this dataset will roughly support approximately a 50 cm grid. (√(1/5) = 0.45). When extracting ground points only, users should assume a lower point density in the ground class, for example, 2 pts/meter2. In this case, the chosen grid resolution should be no smaller than 70 cm (√(1/2) = 0.7).
Note that for fairly dense data sets like the GeoEarthScope and B4 projects, you can reliably make DEMs at 0.25-0.5 m resolutions with 0.8-1 m search radii. The advantage of using the OpenTopography custom DEM functionality comes in the ability to simultaneously run a number of jobs using various search radii and grid resolutions. Once the jobs are complete, you can determine which DEM is optimal for your project's needs.
While some datasets have standard DEM options for downloading larger GIS files, we do not yet offer this service. However, there are three options available that might help:
Users often have issues with loading a DEM into graphics programs like Photoshop or GIMP. The issue is that OpenTopography outputs the tif files as a 32-bit files where the pixel values are elevations. Photoshop (and GIMP) try to interpret these elevation values as byte values (0-256 if 8 bit image, 0-32767 if 16 bit image). In order for the images to be displayed properly in these programs, users need to scale those elevations values to byte values - either 0-256 or 0-32767 depending on if you want a 8-bit or 16-bit image.
There are a couple of ways to deal with this:
There are also methods to deal with these files within GIMP/Photoshop without first converting, but they are more complicated. Users can read more about those methods here
For some lidar datasets there often are linear or "corduroy" effects in the data, especially towards the edges of flight paths where the errors in the data can be larger. Corduroy effects often occur when there is a mismatch or vertical offset between overlapping scans. The vertical mismatch can be caused by a variety of conditions such as: excessive aircraft turbulence, large bank angles, poor GPS solutions, low quality detectors, or a variety of other factors. Depending on how the data is post-processed and what controls the data provider used, these artifacts can often make it into the final product. Unfortunately, there is nothing the user (or OpenTopography) can do to fix this as it is in the raw data that we receive.
Naturally, these effects are not in all datasets, and there are some techniques users can take to minimize the effect. One option is to set a coarser grid resolution, and to keep the point density of the dataset in mind when setting an appropriate grid resolution. If the artifacts are still present at a coarser resolution, users may want to try our other gridding algorithm under "DEM Generation (local gridding)". This technique is different than the TIN generation in that it will average all values within a given circle with a given radius, centered on each grid cell. Users can control the grid size, the search radius, and the size of the null-filling window. This technique will produce null values if the search radius does not find any data. However, you can set a "roving window" size that will fill in these gaps based on an average of the surrounding cells. This is still doing interpolation and averaging of the data, so it is "smoothing" the data, but if the artifacts are in the raw data, there limited options.
Another option is to use the raster data that is provided by the data provider instead of generating your own from the raw point cloud. Some data providers give us their own derived raster products. Generally these are at 0.5 or 1 meter resolution, but they may have had extra processing to produce a "cleaner" raster. This is all dependent on what algorithms and data QA/QC the data provider chose to use. So, this will vary per dataset, but it may be another option to reduce the effect.
A .kmz file is a zipped .kml file (Keyhole Markup Language). KML is a file format used to display geographic data in an Earth browser, such as Google Earth and Google Maps. KML files are used to pinpoint locations, add image overlays or outline an area. For more information, visit the Google kml page.
Yes. In your Google Earth access window on the left side of the screen below the "Places" tab there is a slide bar that will allow you to fade between Google Earth and lidar.
This will depend on how the slopeshade imagery was created. OpenTopography produces hillshade KMZs as part of the visualization step. For some datasets (e.g., EarthScope, Tahoe), slopeshades are pre-generated and accessible via the OpenTopography Google Earth imagery files. To create slopeshade imagery for your area of interest, check the "Generate hillshade and slope grids in grid format" box on the job submission page under "Derivative Products". Then make sure to select, "Generate additional Google Earth KMZ files" under the Visualization stage to generate google earth files for the hillshade images.
For raster terrain products that were produced outside of OpenTopography, you will need to use other software to convert your hillshade or slopeshade imagery to the KMZ format. Simply saving the file as a .tiff or other graphics format will not work. There are various software that have this functionality and include Global Mapper, MapTiler, and ArcMap.
The Google Earth lidar KMZs simply show imagery derived from the DEM data. There is no elevation information associated with the imagery when viewed as a KMZ in Google Earth. Google Earth will only display elevation information for the native elevation mesh which is derived from a variety of sources (USGS National Elevation Dataset, SRTM, etc). Rarely are the native Google Earth elevations as accurate as those from the lidar data. If your project requires the use of accurate elevation values, you will need to use a true GIS software package (e.g., Global Mapper, ArcGIS).
This is a known issue with the early deliveries of the NoCal data and has been resolved for the later deliveries. However, for older deliveries the fix here is to use the "Define Projection" tool in ArcToolbox to redefine the projection for the misaligned tiles to what it should be (WGS_1984_UTM_Zone_10N). Note that you want to redefine the projection NOT reproject the data. The data in the file have the correct coordinates, ArcMap just gets confused and puts it in the wrong place because the projection definition is wrong.
The geometries of some active fault datasets on OpenTopography are generally long, narrow swaths that are parallel to the major faults in the region (e.g., the San Andreas fault system). These data are arbitrarily tiled into 1 km2 tiles regardless of how many points are in each tile. For tiles that fall on the edge of the point cloud, there may be very little data in a tile. You can see this issue clearly if you overlay the hillshade data on the tile index in Google Earth (both files are available in the Google Earth files page.
The EarthScope lidar data were delivered in ASCII format with the following schema:
X, Y, Z, GPSTIME, INTENSITY, CLASSIFICATION, FLIGHT_LINE
As you can see, return number is not included. Classification is included however. The LAS files are generated on the fly by OpenTopography and are written using the information delivered by the data provider. As such, the schemas for point cloud data can vary greatly.
This is a common challenge encountered by the terrestrial laser scanning (TLS) community. OpenTopography's DEM-generating algorithms were designed to process "2.5D" datasets (i.e., every x,y coordinate has one and only one z value). These algorithms have a hard time processing true 3D datasets (i.e., an x,y coordinate may have multiple z values). There exist several software packages that are specifically designed to handle TLS data.
Examples of such software include Polyworks Pro, RiScan (companion to Riegl TLS scanners, and Leica Cyclone. You may also find other software solutions available in the computer aided design community (e.g. AutoCAD 3D Studio Max, Geomagic) since TLS is increasingly being used in urban modeling and engineering applications. For volumetric data representation, netCDF is a good format and has been used in seismic tomography and other 3D geophysical applications.
OpenTopography hosts the following datasets that cover dune fields:
The NOAA Digital Coast site also contains datasets that cover dune fields along U.S. coastlines.
Software for do-it-yourself point cloud classification or filtering is relatively limited. There are various commercial software packages such as LAStools, Terrasolid, and MARS that are designed for production environments (i.e. for use by a lidar vendor).
In the free/open-source realm, GRASS GIS may have a robust point cloud classification capability. Another open source option is PDAL which uses the Simple Morphological Filter (SMRF) algorithm to classify ground points.
Finally, you might want to take a look at this paper: Evans, J.S., and A.T. Hudak (2007), A multiscale curvature algorithm for classifying discrete return lidar in forested environments. IEEE Transactions on Geoscience and Remote Sensing 45(4):1029-1038. Download at: http://www.treesearch.fs.fed.us/pubs/29032.
Intensity is a measure, collected for every point, of the return strength of the laser pulse that generated the point. It is based on the reflectivity of the object struck by the pulse. Other descriptions for intensity include "return pulse amplitude" and "backscattered intensity of reflection". Intensity is used as an aid in feature detection and extraction, lidar point classification, and as a substitute for aerial imagery when none is available. If your lidar points include intensity values you can make images from them that look similar to black and white aerial photographs. To learn about creating an intensity image, visit this page.
Some lidar datasets (e.g. the EarthScope datasets), use elevations with respect to the ellipsoid, not the more commonly used orthometric (height above sea-level) elevations. The ellipsoid heights are measured along the ellipsoid normal in contrast to the orthometric heights, which adjust for Earth's gravity through a geoid model. In many applications, the term elevation most commonly refers to the orthometric height of a point. This page from ESRI provides a more detailed discussion.
Ellipsoid heights from GPS surveys are converted to traditional orthometric values by applying a geoid height using the latest geoid model from the National Geodetic Survey (NGS). You can calculate the geoid separation using this page. Once you have the separation value, you can "move" the DEM into the correct orthometric location using raster math (e.g., the raster calculator in ArcGIS).
The Corps of Engineers Coordinate Conversion (CORPSCON) tool can be used to transform the point data (XYZ ASCII) ellipsoid heights into NAVD88 elevations using various GEOID models, including the latest iteration, GEOID12A. The converted point data files can be then re-gridded to the ArcInfo raster format using your preferred interpolation technique.
If your job failed or does not fully complete, all OpenTopography staff get an email notification, so rest assured we are aware of the issue and are looking into the problem. However, below are some common causes of failed jobs, and what you can do to ensure a successful job completion:
Gridding at too fine a resolution
Most failed jobs are due to users trying to grid the point cloud at too fine a resolution. A simple formula to determine what grid resolution is supported by a given lidar point cloud density is to take the square root of the point density per unit area (e.g., 5 pts/meter2). Point densities for each lidar dataset can be found below the "Overview" section. For example, if a dataset has a point density of 5 pts/meter2, then this dataset will support approximately a 50 cm grid. (√(1/5) = 0.45). When extracting ground points only, users should assume a lower point density in the ground class, for example, 2 pts/meter2. In this case, the chosen grid resolution should be no smaller than 70 cm (√(1/2) = 0.7).
Large Selection Area with a Narrow Dataset
Another common reason for failed jobs is when selecting a large area over a narrow dataset (such as data over a river or fault). In these scenarios, when gridding the area of interest, there is a high proportion of NoData cells within the region specified. For these cases, it is best to divide the region into smaller units to avoid the high proportion of NoData cells, then use a GIS program to mosaic them together.
There may be cases where there is an intermittent network issue that interrupts a job and causes it to fail or not fully complete. In these cases, it is best to wait a short amount of time for the network to stabilize, and then users can easily re-submit the same job by clicking on the link provided in the email, and then click the link which says, "modify and resubmit this job".
Users can easily script access to OpenTopography datasets that are in bulk storage using the AWS Python SDK. Users must first have an AWS account and set up their credentials. Refer to this page for details on how to set up AWS credentials. Here is a simple Python script to download a dataset from bulk:
from botocore.config import Config
from botocore import UNSIGNED
s3 = boto3.resource('s3',endpoint_url='https://opentopography.s3.sdsc.edu', config=Config(signature_version=UNSIGNED))
bucket = s3.Bucket('pc-bulk')bucket.download_file('NZ18_Banks/CL2_BX24_2018_1000_4007.laz','CL2_BX24_2018_1000_4007_LOCAL.laz')
In this example, the file, "CL2_BX24_2018_1000_4007.laz" is being downloaded from the project, "NZ18_Banks", and will be saved locally as, "CL2_BX24_2018_1000_4007_LOCAL.laz". Note a the project name is also called its shortname, and can be found on each dataset's landing page.
There is no consensus as far as we can tell. At present, "lidar", "LIDAR" and "LiDAR" are used interchangeably in publications, industry websites and agency websites. For example, recent publications in Science (e.g., the Oskin et al.'s (2012) paper on differencing of the El Mayor-Cucapah pre- and post-earthquake lidar datasets have used "LIDAR". At OpenTopography, we are moving toward using "lidar" for the same reason "radar" is not spelled "RADAR" (which is an acronym for radio detection and ranging). See Prentice et al.'s, (2009) article ("Illuminating Northern California's Active Faults") in Eos for this usage.
There are various lesson plans and short courses that are designed for teaching about lidar data and applications in the classroom. Please visit our Resources for Educators page for information on how to contact us about sharing your teaching resources.
For Earth science-oriented lidar terms, you might want to subscribe to Arizona State University's lidar group and the UNAVCO list, both of which are announcement lists. OpenTopography also has a newsletter that you can subscribe to. Also follow OpenTopography on Facebook or Twitter for announcements. There are also various lidar groups on professional networking sites such as LinkedIn including the OpenTopography LinkedIn group.