This commit fixes an issue where expressions were
silently failing when encountering undefined fields.
Instead they should be treating the undefined field like
the number zero. This is required to stay compatible with
how Tile38 handles zeros.
https://tile38.com/commands/intersects/#fieldsFixes#754
This commit fixes a regression in 1.30.0, where an existing
object which has fields will lose those fields when the object
geometry is overwritten using a SET or JSET and no new fields
are provided.
fixes#668
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
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.
