Skip to main content
Version: Next

Accuracy/Limitations

Javascript-only​

  • The geoprocessing library currently only supports geoprocessing functions that run in a NodeJS environment. You have the ability to invoke any Lambda function, the framework just doesn't have first class support for writing and publishing functions in any other languages.

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​

TurfJS​

TurfJS vector function (particularly those that use Turf.JS) measure distance and area by approximating them on a sphere. Turf.js functions 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 (> 60), then the accuracy will be quite good, and the error quite small (within 5%) compared to more exact algorithms.
  • And if your planning objectives target creating areas that capture a given % of something, for example 20% of the rocky reef habitat in the entire planning area, then the effect of error in area calculations should be limited to none as long as the area calculations are done using the same algorithms.

Sources: