Spatial search

Both types accept "lat,lon" on input:

RPT trades LLPSF’s speed and simplicity for shape support: it indexes a point or shape as a set of grid cells at increasing precision levels (a recursive prefix tree over a geohash- or quad-based grid), which is also what makes heatmap faceting possible — the same cell structure the index already maintains is the heatmap grid. See Spatial Search for the full field-type comparison and every configuration attribute.

\{!geofilt} filters to documents within a radius (great-circle distance) of a center point; \{!bbox} filters to the axis-aligned bounding box enclosing that same circle — cheaper to compute since it skips the per-document distance calculation, at the cost of also matching the box’s corners outside the actual circle.

Outside a [source] block those same filters are written escaped, as \{!geofilt sfield=store_location pt=40.7,-74.0 d=10} and \{!bbox sfield=store_location pt=40.7,-74.0 d=10}, so AsciiDoc does not try to interpret the braces. sfield names the spatial field, pt the center point (lat,lon), and d the radius in kilometers. Both parsers work against LatLonPointSpatialField and RPT fields alike.

geodist() is a function query that computes the distance from a point to a spatial field’s value, usable anywhere a function query is — sort, fl (to return the distance), or inside a boost function.

geodist() takes the field and point either as explicit arguments (as above) or implicitly from sfield/pt request parameters when called as bare geodist(). Because it is an ordinary function query, it also composes with relevance the same way any other function does — see Function queries for boosting a text query by proximity instead of only sorting by it, and Relevance & scoring for how a boost function folds into the final score.

RPT fields (and BBoxField, for boxes) accept Well-Known Text shapes on both indexing and querying, using the \{!field} query parser (or the RPT-specific spatial predicate syntax) rather than geofilt/bbox, which only understand a center point and radius.

Outside a [source] block that filter is written escaped, as \{!field f=delivery_zone}Intersects(POLYGON(…​)). The spatial predicate defaults to Intersects (shares any point with the query shape) and also accepts IsWithin (field shape entirely inside the query shape), Contains (field shape entirely encloses the query shape), IsDisjointTo (shares no point), and IsEqualTo — the same relation vocabulary as Elasticsearch’s geo_shape query, spelled differently. RPT ships two spatial-context implementations selectable per field type: JTS (spatialContextFactory="JTS"), flat-plane geometry with support for polygons with holes and self-intersection repair, and Geo3D (spatialContextFactory="Geo3D"), which computes on the actual ellipsoid rather than a flat projection — more accurate for very large shapes, at higher CPU cost per query.

RPT fields support a facet type that returns a grid of document counts over a bounding region — the data behind a density heatmap overlay, computed from the same prefix-tree cells the field indexes with. It is available both as the legacy facet.heatmap request parameter and, preferably, as a type: heatmap block in the JSON Facet API — see Faceting for the JSON Facet API in full.

geom bounds the region as a WKT envelope or a ["minX,minY" TO "maxX,maxY"] range; gridLevel picks a fixed cell resolution directly (higher = finer), while distErrPct picks one relative to `geom’s size instead — set exactly one of the two. The response is a compact counts matrix (row-major, bottom-to-top) sized to fit the requested resolution, meant for rendering rather than paging through like a terms facet.