It's now possible to query a JSON field using a GJSON path.
SET fleet truck1 FIELD props '{"speed":58,"name":"Andy"}' POINT 33 -112
You can then use the GJSON type path to return the objects that match the WHERE.
SCAN fleet WHERE props.speed 50 inf
SCAN fleet WHERE props.name Andy Andy
Included in this commit is support for '==', '<', '>', '<=', '>=', and '!='.
The previous queries could be written like:
SCAN fleet WHERE props.speed > 50
SCAN fleet WHERE props.name == Andy
This commit updates to the latest btree and rtree.
The rtree algorithm has been modified in `tidwall/rtree@v1.7`
which now keeps internal and leaf rect sorted by the min-x
coordinate. This make for much faster (up to 50%) faster
searches and replacements, but slightly slower inserts.
Because of the R-tree update, the tests needed to be updated to
account for the change in order for undeterministic WITHIN and
INTERSECTS commands.
The big change is that the GeoJSON package has been completely
rewritten to fix a few of geometry calculation bugs, increase
performance, and to better follow the GeoJSON spec RFC 7946.
GeoJSON updates
- A LineString now requires at least two points.
- All json members, even foreign, now persist with the object.
- The bbox member persists too but is no longer used for geometry
calculations. This is change in behavior. Previously Tile38 would
treat the bbox as the object's physical rectangle.
- Corrections to geometry intersects and within calculations.
Faster spatial queries
- The performance of Point-in-polygon and object intersect operations
are greatly improved for complex polygons and line strings. It went
from O(n) to roughly O(log n).
- The same for all collection types with many children, including
FeatureCollection, GeometryCollection, MultiPoint, MultiLineString,
and MultiPolygon.
Codebase changes
- The pkg directory has been renamed to internal
- The GeoJSON internal package has been moved to a seperate repo at
https://github.com/tidwall/geojson. It's now vendored.
Please look out for higher memory usage for datasets using complex
shapes. A complex shape is one that has 64 or more points. For these
shapes it's expected that there will be increase of least 54 bytes per
point.
