struct
, array
or otherwise? We want to balance efficiency, simplicity and developer experience.struct
is a sensible approach, with s.coordinates
being the coordinate array [[lon0, lat0], [lon1, lat1], [lon2, lat2], ... ]
:length(s)
, which would compute the length of the linestring represented by s.coordinates.
This also would enable efficient type checking and verification when data is onboarded or used in a method:The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84.An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.
CRS
flag, handling a range of coordinate reference systems would cause complexity to balloons.coordinates
into a function.s.length()
returns the length of the linestring - but it seems super inefficient and probably unnecessary.eth-spatial.js
and eth-spatial.py
to start - are designed to provide a developer friendly interface between vector spatial data represented in JavaScript / Python environments and those represented in the EVM.web3.js
or ethers.js
, extending those when the developer is interacting with contracts that use Spatial.sol.web3
access to all of the required methods etc to work with spatial contracts)