Geometry

Appears when a type stores GeoJSON. Draws the geometries on a server-rendered SVG map with zoom-to-feature and fit-all, and lists vertices, length, area, centroid and OGC validity per document.

A type can hold geometry at more than one path — a Point for where an order ships and a LineString for how it got there. The selector at the top picks which path is drawn, and says what kind of geometry lives there.

Narrow it to a single document id — which is what the Geometry link on a browse row does — and only that shape is read and drawn. The filter reaches the query, so scoping a large type does not scan it end to end to render one feature.

Large types are capped and the cap is stated (281 drawn of 500 scanned) rather than silently applied.

It reads the document, not the sidecar

It reads from the document body rather than the {table}_spatial sidecar. The sidecar holds only bounding boxes for index pruning and its shape differs per provider, while the GeoJSON in Data is the actual value and is identical everywhere.

So this works on every provider, including the ones with no spatial support at all — and it shows you what your documents say, not what an index believes about them.

Parsing goes through the library’s own GeometryJsonConverter, so the tool inherits the real OGC model rather than reimplementing it. That is also where the valid column comes from: it is OGC validity, not “did it parse”.

See Spatial for the library side — mapping geometry, the spatial sidecar, and the queries the index actually accelerates.