Spatial.sol
A Solidity library of topological and geometric functions
Many of the applications we envision will require us to perform spatial operations in smart contracts. To this end, a few years ago (at ETHParis) we outlined and experimented with a Solidity library for performing these operations - measuring the length of a linestring, testing to see if lines intersect, checking to see if a point is inside a polygon, etc. Our draft code is here.
We prototyped a location-aware wallet (early experiments that may lead to truly local currencies). At the time we were discouraged due to computational complexity leading to high gas costs, but Layer 2 solutions like Polygon and xDai, alternative lower cost EVM-compatible blockchains like IoTeX or Avalanche and, of course, Eth2 does mean that these kinds of operations will be increasingly viable in smart contracts.
We are developing the first version of the
Spatial.sol library and plan to release it under an open source license. Developing the library entails tackling several technical challenges, and to build a production-quality library will be quite involved.Spatial.sol is required for many of the location-based dapps and spatial contracts we envision, including the verifiable spatial data registries described here. We are researching which functions the library should include, and will look to Turf.js for inspiration. Some functions we expect to include are:- Boolean verification algorithms like
isPolygon,isLineand so on sqrt- Conversion helper functions like
degreesToNanoradians. - Various geometric functions like
distance,area,centroid,length,perimeter - Angular functions like
bearing,rhumbBearing - Geometric helper functions like
boundingBox, convexHull - Boolean topological tests like
pointInBbox,pointInPolygon,intersects - Functions for manipulating geometries such as
difference,dissolve,intersect,union, etc.
These functions will serve as a basis for the first cohort of applications built on Astral. Note that these are primarily vector operations - we anticipate that raster analysis techniques may be useful (recreating some of the functionality of RasterIO, for example), but will leave that for a future version of Spatial.sol. We still need to research the feasibility of supporting multifeature data structures like multipoints, multilines and multipolygons, as well as more complex shapes like polygons with holes. Version 1 will not support 3-dimensional volumes (polyhedra), but we anticipate that many use cases will require implementation of this functionality in future - for example, to test if an aircraft has entered some airspace.
We anticipate that one of the most difficult aspects of building smart contracts designed to work with spatial data is accommodating the diversity of spatial reference systems. The Earth is not a perfect sphere - it is a geoid - and many different systems are used to represent positions relative to the planet. Geodesy matters, and implementing systems that accommodate different spatial reference systems, converting between them etc will be a complex technical challenge.
Spatial.sol has a dependency: Trigonometry.sol, developed and open sourced by Sikorka (docs, code). This library appears to have been abandoned a few years ago, and lacks a tangent method, which is useful in some operations like the bearing between two points. Spatial.sol will require an audited Trigonometry.sol to be secure.We anticipate that we'll want to develop a corresponding client library
eth-spatial.js, to abstract some of the complexities of supplying spatial data to contracts using Spatial.sol. Our goal is to ease the developer experience - we expect that many developers will be working with GeoJSON in the client.eth-spatial.js will be designed to seamlessly accept common data formats used on the web (starting with GeoJSON) and prepare the spatial data for use in contracts that use the Spatial.sol library. One example process here will be converting decimal degrees to integers to be used in the contract, possibly nanoradians.Likewise, our aim is for
eth-spatial.js to easily convert from on-chain spatial data to web-ready GeoJSON. We may look into developing a subgraph to index on-chain geospatial data - the final step to fetching this data will be presenting it in a format that interoperates with common spatial data libraries like Leaflet, Mapbox GL JS etc. An eth-spatial.py library would also probably be helpful, as would implementations in other languages - future work to do.We anticipate this library will need a thorough audit. We would like to explore how we can ensure ongoing support and development of the library once it is developed and open sourced.
Last modified 1yr ago