Skip to main content
Version: 6.1.0

Introduction

The SeaSketch Geoprocessing framework is an all-in-one solution for developing low-cost and low-maintenance geoprocessing functions and reports for the web, with Typescript. Simplified publish to cloud with auto-scaling to meet high demand.

This framework is part of the SeaSketch ecosystem.

Who is this framework for?​

This framework is primarily designed for people that want to create and host their own geoprocessing functions and reports and plug them into their SeaSketch project, though it is not dependent on SeaSketch.

It is used for all SeaSketch projects.

Goals​

  • Serverless architecture that scales up to meet high demand, then scales down to near zero cost when not in use.
  • First-class Typescript development experience.
  • Provide a stable environment for writing analytical reports with React.
  • Utilize cloud-optimized data formats including Flatgeobuf and Cloud-optimized GeoTIFF (COG)
  • Open source license

License​

Geoprocessing source code is licensed under a BSD 3-clause license and any reuse or modifications must retain this license with copyright notice.

Wiki docs, including any code snippets in tutorials, are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Creative Commons License

Features​

  • Cloud-native serverless architecture
  • Plug-and-play with SeaSketch platform
  • End-to-end support and use of Typescript
  • Project generator with templates and built-in commands for common project tasks
  • Library of React UI components ready to add to reports.
  • Docker workspace preloaded with open source geo tools for data preparation.
  • Supports extended GeoJSON feature types called Sketches and SketchCollections suited to collaborative spatial planning
  • Uses cloud-optimized techniques for storing and retrieving large datasets over a network including Flatgeobuf, Cloud-optimized GeoTIFFs (COGs), and subdivision.
  • Toolbox of geoprocessing functions utilizing Turf JS, Geoblaze, Simple Statistics.
  • Cloud-native serverless architecture using AWS Cloud Formation, with automated provisioning and migration as a project evolves.
  • APIs for accessing project resources and integration including REST, Web Socket, and IFrame postMessage.

3rd Party Building Blocks​

You will interact with a number of building blocks when creating a geoprocessing project, many of which are 3rd party software and services. The main building blocks include:

  • Github - hosts the geoprocessing code repository. It's also the recommended place to host your geoprocessing project.
  • NPM - the Node Package Manager or NPM, hosts the geoprocessing Javascript package and allows it to be installed on your computer. It consists of an online repository for hosting Javascript packages, and a client library that is bundled with NodeJS on your local computer.
  • NodeJS - an open source, cross-platform Javascript environment that allows Javascript code to be run on your computer. The geoprocessing framework is written almost entirely in Typescript, which is converted to Javascript. Every time you run a geoprocessing command, NodeJS is what is used behind the scenes to execute it.
  • Docker hub - Docker Hub is a container image registry. Container images are lightweight, standalone, executable packages of software that include everything needed to be self-sufficient: code, runtime, system tools, system libraries and settings. Docker Hub publishes the geoprocessing docker container images including geoprocessing-workspace and geoprocessing-db, which together provide a full suite of geospatial software needed by the geoprocessing framework, and that you can use for working with and publishing your geospatial data.
  • Docker Desktop - software used to create and run instances of the geoprocessing container images on the users computer. For Windows users, it also provides a way to install and run the geoprocessing framework within the Windows Subsystem for Linux (WSL).
  • VS Code - provides an integrated development environment (IDE) for managing a geoprocessing project including code editing, command-line terminal, Github integration, and more.
  • Amazon Web Service (AWS) - AWS is the cloud service provider that ultimately hosts your geoprocessing project and integrates with a SeaSketch project to run reports on demand. It provisions the necessary storage, compute and database infrastructure automatically using CDK.

Known Limitations​

Javascript-only​

  • The current version of the library only supports spatial libraries written in Javascript. This includes Turf JS, Geoblaze, cheap-ruler and anything else you can find. There is discussion about supporting any analysis that can be packaged into a Docker container now that Lambda has added container support. This will be done as need arises.

Coordinate System Support​

  • Vector data, on import, is converted to WGS 84 (EPSG 4326). Vector toolbox functions expect data to be in this projection.

  • Raster data, on import, is converted to an equal area projection (NSIDC EASE-Grid 2.0 Global)[https://epsg.io/6933]. Raster toolbox functions should work with any grid-based projection but anything other than equal area will have accuract issues.

  • Geoprocessing functions in this library currently only support GeoJSON data in the World Geodetic System 1984 (WGS 84) [WGS84] datum (aka Lat/Lon), with longitude and latitude units of decimal degrees.

Calculation Error​

Since the data is spherical (WGS84), most toolbox functions in this library (particularly those that use Turf.JS) measure distance and area by approximating them on a sphere. Algorithms are typically chosen that strike a balance between speed and accuracy.

  • If the geographic area of your project is small, on the order of a few hundred to a thousand miles, and not at high latitudes, then error is relatively small.
  • Reporting the percentage of an area is not subject to the error of the algorithm for calculating the area. For example, if you write a function to calculate the % of a particular habitat captured by a polygon that overlaps the habitat, as long as the area of the total habitat, and the area overlapping the habitat are calculated using the same formula, then the percentage of the two should be the same as if it were calculated using a more accurate area formula.

Sources:

Known Issues​

These are important to keep in mind when developing reports:

  • If users cannot draw sketches on land, then Rasters must be clipped to land. This is true for any place within the planning area that the user cannot draw.
  • Holes should not be allowed in sketch polygons (such as via shapefile import), unless they are due to preprocessor clipping of non-eez areas like land.

The reason is because Geoblaze doesn’t handle holes in polygons. When given a polygon for overlap, like geoblaze.sum(raster, polygon) if it finds value within the hole, it will include it in the result (think sum) when it should exclude it. The right solution is to add support to geoblaze. In the interim a hack was done in the overlapRaster toolbox function to remove any holes from the sketch GeoJSON just prior to running a geoblaze.sum or geoblaze.histogram. So if you allow the sketch have holes that should exclude raster value, that will not happen! The toolbox function will just remove the holes and happily include any raster value that is there.