-
Notifications
You must be signed in to change notification settings - Fork 3
Home
The documentation in this wiki is now maintained at https://seasketch.github.io/geoprocessing
Table of Contents
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.
- 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.
- Templates for common planning use cases that can be installed into your project.
- 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.
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 includinggeoprocessing-workspace
andgeoprocessing-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.
- 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.
- 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.
Since the data is spherical (WGS84), most geoprocessing functions in this library (particularly Turf.JS) measure distance and area by approximating them on a sphere. Algorithms are typically chosen that strike a balance between speed and accuracy. So choose accordingly. That said:
- 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 usually acceptable.
- 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:
- Fast Geodesic Approximations
- Calculate distance, bearing and more between Latitude/Longitude points
- Haversine Formula on Wikipedia. Used by turf-distance. Error up to 0.5%
- Some algorithms for polygons on a sphere - used by turf-area. Greater error at higher latitudes vs. Vincenty.
- Vincenty algorithm used by turf-vincenty-inverse
- GeoJSON spec WGS84 requirement.
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.
- When working with VectorDatasources, requesting a union of subdivided eez polygons will occasionally throw a "looping" error - see https://github.com/seasketch/geoprocessing/issues/72 and https://github.com/seasketch/union-subdivided-polygons/issues/5. It is not recommended to use unionProperty with the EEZ datasource, unless you thoroughly test with the country you are working with. In practice this is not necessary anyway unless you are working with a complex EEZ boundary.