Earth Sensor Portal - New Features

Published On: July 13, 2020


New Features in Earth Sensor Portal (ESP)

Earth Sensor Portal is our Amazon Web Services (AWS) hosted ("cloud") system designed to provide secure access to a catalog of raster and point cloud data products (i.e. LIDAR, NAIP, Landsat, orthophotos) for both viewing and download/ordering for authorized users.  Earth Sensor Portal provides an online catalog for your organization's data with an intuitive query interface that supports searching for data by any combination of product type, product metadata and data location. 

ESP was crated as the processing, cataloging and delivery solution for the Multi-User System for Earth Sensing (MUSES), a Teledyne Brown sponsored project for the processing of hyperspectral data collected by the DLR Earth Sensing Imaging Spectrometer (DESIS-30) operating on the International Space Station (ISS).  ESP is also available as a stand-alone web service for any organization looking to host their geospatial data archive in the cloud and make that catalog available to the public.  We recently added new features to ESP to support more powerful querying and data download tools and added enhanced support for viewing ancillary data files.

Earth Sensor Portal Display Screen

Figure 1 : Earth Sensor Portal (3D Globe View)

Support for User-Defined Boundaries

Querying and finding data by location has always been supported in Earth Sensor Portal.  Users can enter a specific address or spatial location or browse/search a Name Gazetteer to drive to the location they are interested in reviewing.  They can then see the various data sets available in the catalog that cover the area and download the data for their area of interest.  Using the map extents or manual digitizing a boundary works well for such queries when the area of interest is relatively small and relatively simple.  For example, extracting the most recent LIDAR data for a highway intersection.  However, users of ESP increasingly want to extract data from the catalog automatically segmented in a way that is not the same as the typical "By Project/By Tile" approach that was used to publish it.  One recent example we worked on involved users wanting to extract high resolution LIDAR data by watershed boundary.

LIDAR data is most commonly published "By Project" - a practice we strongly recommend for any base data in ESP by the way - but then delivered to end users by political boundary (city, county, state etc.).  For a watershed, lidar data is often not segmented to the watershed extents unless specifically requested in the original contract.  In addition, the watershed may cross several different data collections and political boundaries depending on when and where the source LIDAR data was collected.  To facilitate querying and extracting LIDAR data "By Watershed" we have added the ability for users to publish their own boundary files to use in querying and extracting any data published in an ESP catalog. 

Watershed Boundaries Added To Named AOI List

Figure 2: Watershed Boundaries Added To Named AOI List

These user-defined boundaries can be imported/published in ESP from a .shp or .kml file and support any arbitrary boundary geometry, large or small, the user wants to implement.  Once published, these Named AOIs can be made available to all users for navigation and placing data orders.  Enabling user-defined boundaries allows users to work with the data in your ESP catalog with any spatial segmentation method independent from the original project collection, including ones that may not even have been considered by the original collection requirements.  Other common examples where this feature is valuable include transmission line or oil/gas corridors, road networks, or any collection of distributed sites of interest (e.g. all aggregate sites in my state, all environmental clean-up sites near me, specific animal habitats of interest).  By giving the user the ability to query and extract data according to their own spatial filters, rather than an arbitrary tiling scheme or by political boundary, it significantly increases the value of your catalog to them.

As a secondary feature, we have also added the ability to save manual boundaries created interactively by the user.  This allows for them to be added to the Named AOI list or simply recalled for future use.

Saving A Site Plan Boundary

Figure 3: Saving a Site Plan Boundary

Support for Ancillary Data Files

Another new feature in ESP is the ability to catalog and publish additional data files along with your baseline imagery or LIDAR data.  A common example would be publishing a derived product, such as a canopy height model, along with the LIDAR point cloud.  Downloading the source LIDAR or imagery data may not be the primary motivation for a user searching your catalog.  In fact, in our experience, many users still prefer to simply download the desired end product over the point cloud or imagery data themselves.  With this new feature, if you have a collection of derived products that are the primary value to your users, these can now be displayed as ancillary files for your base LIDAR or imagery data.  The user can select any combination of these products for download in addition to, or perhaps instead of, the base data.  This can be a very cost-effective option for delivering end products if you have a set of deliverables that need to be QA/QC'd and approved prior to release.  In such scenarios on-the-fly generation to allow the user to create their own product from the base data are not an option.

If you are interested in learning more about how to cost-effectively publish your geospatial data catalog using Earth Sensor Portal, for public or private stakeholders, please give us a call or email us at [email protected] to arrange a demonstration.