Unearth Overview
What is Unearth
Unearth is a Location-based platform that allows you to extend your existing software's capabilities to incorporate Location-based experiences and data storage. Unearth has a set of APIs in addition to a web application and two native mobile applications (iOS and Android) that can be optionally utilized in a whitelabel capacity.
Unearth's Valuable Capabilities
Customize the schema stored in Unearth using a Schema Builder in just minutes to...
- Match your software's schema without lengthy mapping code
- Create custom schemas for each one of your end customers
- Customize map visualizations based on key properties
Store location data in our proprietary and performant data model for fast retrieval, such as location-based searches
Best in class map rendering and 'no-GIS required' end user interactions
How to Integrate with Unearth
There are three ways to utilize Unearth's capabilities, and all can be augmented using Unearth's APIs.
- Whitelabel
- Embedded Experience
- API
Main Developer Use Cases
You've likely found yourself here for one of the following reasons:
- Your company has decided to whitelabel Unearth's web and/or mobile applications in order to offer Location-aware Mapping solutions to your customers. Unearth's APIs allow automation of data import/export between your existing systems and Unearth.
- You are building a custom map-based application to enable a specific use case utilizing a combination of Unearth APIs and apps.
- You are an existing Unearth customer and would like automate data Import/export between Unearth and your internal systems for deeper in house analytics and analysis.
How Unearth Works
With Unearth, you can map assets, capture field information, and collaborate with your team.
Unearth is a flexible platform that can be used in any type of project – whether that’s linear construction, operations, and maintenance or even management of a ski resort. As such, Unearth enables users to model their data so it coincides with their unique schema.
To navigate this flexibility within the API and/or the UI using Unearth's web application, it’s important to understand a few key concepts:
Concept: | Description: |
---|---|
Accounts | A User may belong to one or more Accounts. Accounts can be organized by company, vendor, program, team, individual, and more. Example: A manager at a utility could belong to their company’s Account as well as the Accounts of the service contractors they oversee. Let’s call this manager Carl and unpack their situation further in the following sections. |
Projects | An Account is made up of zero or more Projects. Users create a Project based on an address or the boundaries of a polygon on the map, and Projects store and manage data associated with that area. Projects may be added, modified, and deleted from within the Account. The data schema for Accounts and Projects aren’t customizable. Example: Carl can access a service contractor’s Account and finds multiple Projects based on different neighborhoods within this Account. When they select a specific Project, they see all of the infrastructure and inspections logged in that neighborhood. |
Assets | Projects can be made up of zero or more Assets. Assets are the essential data points of a Project, and their data schemas are quite flexible. Example: Now that Carl has accessed a Project, they find a variety of Assets: gas pipeline, parcel data for each home, inspections, work assignments, flagged issues, damage assessments, and more. These Assets are organized in a table view and represented visually on the map. |
Asset Types | All Assets share a set of common properties (e.g., timestamps, creator, ID, etc.). But Assets also have custom fields. The structure of these unique properties is based on the Asset Type. To successfully create or update an Asset’s properties, you must understand the Asset Type and adhere to the valid data structure. Example: Each of the Assets that Carl sees in the vendor’s Project is a different Asset Type. An “inspection” pinned to the map has fields specific to the gas lines that the service contractor must inspect for issues. There’s a drop-down to select for material type and a media field to attach inspection video. A “damage assessment” logged nearby is a different Asset Type and doesn’t have these properties. |
Asset Forms | Where an Asset Type describes the properties of an asset, how those are stored, and what values are valid, an Asset Form describes how those values are presented in a user interface, interpreted in API parameters, or emitted in export formats. Example: Carl chooses a completed inspection asset. He clicks on the asset to open its form, where he can see all of the details of its properties. He can verify that the vendor has performed the work correctly, and may make updates as necessary. |
Feature Types | While an Asset Type defines the unique properties of an Asset, Feature Types define how that Asset is mapped. OnePlace can map both raster and vector data. Example: Carl decides to open a Project within their utility’s Account that was created to manage pipeline construction. They can toggle on recent drone imagery to see progress across the site – an example of raster data. They also see Points marking dig permits, Lines mapping the recently installed pipeline, and Polygons denoting equipment staging areas – all examples of vector data. |
Features | Features are closely related to Feature Types and inform how an Asset is represented visually on the map. An Asset’s representation is determined by two things: Feature Type and feature styling. Example: When reviewing the construction project, Carl can easily see the difference between different Asset Types on the map because they have different styling. A “dig permit” is represented by a little shovel in an oval at a specific Point, a “staging area” is a dark blue Polygon, and the “pipeline” is a thick gray Line. The Features for each Asset Type are unique. |
Roles & Permissions | Unearth has six Roles that restrict actions a User can do while using OnePlace: Owner, Admin, Manager, General User, Limited User, and Viewer. Each role has its own unique permissions controlling what the User can create, edit, view, or delete. Example: As a Manager, Carl can create, view, and edit all content. This includes a “dig permit” in the pipeline project. They can view the “dig permit,” change the status to “open,” and tag a team member, Debbie, in a comment. Because Debbie is a Viewer, they can view the properties of the “dig permit” and comment in response but are unable to edit the status like Carl. |
Updated almost 2 years ago