You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Overview
I previously inquired regarding the support of Tableland's support for geospatial operations. However according to a response in the discord developer channel, Tableland currently does not support geometry/geospatial-related queries.
Potential Action/Solution
Introducing a few open geospatial consortium methods (ex. STIntersects) to Tableland would (in my opinion) be the best step forward to see if using Tableland in a geospatial workflow is possible.
Alternative
Using a traditional SQL Server is possible however not ideal if one desires to have a completely decentralized workflow.
I think spatialite is roughly based around the simple features specification... which does use floating point values. Additionally, I think spatialite actually uses geos (c++ geometry library) under the hood. That means it'd be really hard to support this, because geos uses double-precision floating-point values (i.e., double in C/C++) to represent and manipulate geometric coordinates and perform geometric calculations under the hood.
Overview
I previously inquired regarding the support of Tableland's support for geospatial operations. However according to a response in the discord developer channel, Tableland currently does not support geometry/geospatial-related queries.
Potential Action/Solution
Introducing a few open geospatial consortium methods (ex. STIntersects) to Tableland would (in my opinion) be the best step forward to see if using Tableland in a geospatial workflow is possible.
Alternative
Using a traditional SQL Server is possible however not ideal if one desires to have a completely decentralized workflow.
GSP-9
The text was updated successfully, but these errors were encountered: