It's now possible to do:
SCAN fleet WHERE "properties.speed < 25 || properties.speed > 50"
Uses javascript-like syntax using the https://github.com/tidwall/expr package.
Automatically reference fields and GeoJSON properties:
SET fleet truck1 FIELD speed 65 POINT -112 33
Can be queried:
SCAN fleet WHERE "speed > 50"
SCAN fleet WHERE "id == 'truck1'"
SCAN fleet WHERE "speed > 50 && id == 'truck1'"
This commit allows for performing WHERE on the object's GeoJSON
properties member.
For example:
SET fleet truck1 OBJECT '{"type":"Feature","geometry":{"type":"Point","coordinates":[-112,33]},"properties":{"speed":50}}'
You can now do:
SCAN fleet WHERE properties.speed > 50
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
The core package uses global variables that keep from having
more than one Tile38 instance runnning in the same process.
Move the core variables in the server.Options type which are
uniquely stated per Server instance.
The build variables are still present in the core package.
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.
Each MATCH is inclusive OR, thus
WITHIN fleet MATCH train* truck* BOUNDS 33 -112 34 -113
will find all trains and trucks that within the provides bounds.
The returned distance value for the kNN test was failing on a
Apple M1 machine. The test expected a hardcoded value.
amd64: 13053.885940801563
apple: 13053.885940801567
Not sure why the difference between the two cpus but I changed
the test to not compare for exact equality.