Published: 2026-07-11 • Updated: 2026-07-15

Spatial Support: Map Geometry & Geography Columns on Every SQL Engine

A geometry column is one of the least legible things in a result grid. You run a query, and the cell for a geography or SDO_GEOMETRY value is a wall of hex or an opaque blob — useful to the database, useless to you at a glance. Jam SQL Studio 1.4.15 adds spatial support across all five relational engines: geometry and geography columns are decoded and rendered as interactive maps — in the results grid, a peek popover, a Query Editor Map view, a Table Explorer map pane with spatial filters, and a dedicated Spatial Explorer workspace that stacks layers. It works the same whether the value came from PostGIS, MySQL, SQL Server, Oracle, or SQLite.

One decode path, five wire formats

Every engine stores spatial data differently on the wire. Jam SQL Studio decodes each one to GeoJSON and renders the result identically, so the map surfaces don't care which database the value came from:

• PostgreSQL / PostGIS — EWKB (hex), with the SRID carried in the EWKB flag.
• MySQL — the 4-byte SRID prefix followed by WKB.
• SQL Server — the CLR user-defined type (MS-SSCLRT) for geometry / geography, parsed including curve segments.
• Oracle — SDO_GEOMETRY, interpreting SDO_ELEM_INFO for arcs, circles, and compound elements.
• SQLite — the SpatiaLite blob and the GeoPackage header envelope are stripped, then the inner WKB is decoded.

Kusto has no spatial types, so its spatial capability is off and none of these surfaces appear for a Kusto connection — a property of the engine, not a gap in the tooling.

It starts in the grid

You don't have to go looking for the map. The first place spatial support shows up is the result grid itself — in both grids, the Query Editor's and the Table Explorer's. A spatial cell gets a small glyph and a one-line summary instead of raw bytes:

POLYGON · 5 pts · SRID 4326

That summary is produced by a cheap, header-only read that identifies the geometry type, point count, and SRID without decoding the full shape — so the grid stays fast even when a column is dense with geometry. Click the peek button and a popover opens with a fit-to-data mini map, Copy WKT / Copy GeoJSON, and, on very large geometries, a "Load full geometry" step so you decide when to pay for the full decode.

Query Editor → Map

Run a query that returns geometry and a Map tab joins the Results and Messages tabs. It renders every feature in the result set, with a Color by control to shade features by a column and a live feature count. It's the fastest way to sanity-check the output of a spatial query — you see the shapes, not the hex.

Table Explorer → map pane with spatial filters

Open a table with a geometry column in the Table Explorer and a map pane sits alongside the grid. Selection is two-way: click a row and its feature highlights on the map; click a feature and the grid scrolls to and selects its row. From there you can filter spatially with three chip types:

• Bounding box — "Filter by map view" turns the current viewport into a bbox predicate. Available on every engine (SQLite needs SpatiaLite loaded).
• Distance — features within a radius of a point, on PostgreSQL, SQL Server, MySQL and Oracle. SQLite supports the bounding-box filter only.
• Drawn area — click Draw area and trace a polygon straight on the map (click to drop points, click the first point or double-click to close, Esc to cancel); rows whose geometry falls inside the shape are kept. Offered on native geometry/geography columns with a known SRID (MySQL and Oracle require SRID 4326).

Each chip emits engine-correct SQL — the spatial predicate is written in the dialect of whichever engine you're connected to, so the filter runs on the server, not by pulling every row to the client. Chips only offer the sub-operators an engine and its SRID can actually run; the rest are disabled with a tooltip.

Spatial Explorer: stack layers from different queries

Sometimes one result set isn't the whole picture. The Spatial Explorer workspace lets you stack multiple layers — each backed by a query or a table — on a single map. Every layer gets its own:

• Color, drawn from a fixed layer palette so adjacent layers stay distinguishable.
• Label column, to annotate features from a data column.
• Feature cap, to keep a huge layer from swamping the canvas.
• Visibility and order, so you can toggle and restack layers as you compare them.

Put your parcels under your service areas under your point-of-interest markers and read them together.

Curves render, Copy stays curved

Curved geometry — CircularString, CompoundCurve, CurvePolygon, and their multi-part cousins — is genuinely awkward to display, because a map renders straight line segments, not arcs. Jam SQL Studio linearizes the arcs client-side (densifies them into segments) purely for display, and shows an "arc approximated for display" hint on the peek so you know what you're looking at.

The invariant that matters: Copy WKT keeps the shape curved. The linearization is a display concern only — a CIRCULARSTRING you copy out is still a CIRCULARSTRING, never a flattened LINESTRING. Curves are supported on PostgreSQL, SQL Server, Oracle, and SQLite for root-level curve shapes (SQL Server and Oracle don't model a curve nested inside a collection); MySQL has no curve types, so it's not applicable there.

Basemap on by default, privacy respected

Out of the box, geometry renders over an OpenFreeMap basemap (Liberty style) so features have geographic context. Because that fetches map tiles over the network, the first time a basemap loads you get a one-time, dismissible privacy notice explaining that tiles come from openfreemap.org and how to turn them off. Attribution is shown only while the basemap is active.

Prefer no network? Turn the basemap off in Settings → Spatial and the map draws a planar graticule instead — a projection-free grid that renders entirely offline. That same planar fallback is what you get automatically when you're offline or when a geometry's SRID can't be resolved, so a map always renders something honest rather than failing.

To resolve a SRID, Jam walks a ladder: built-in projections (WGS 84, Web Mercator) and a small bundled EPSG definition table resolve instantly; a SRID in neither is looked up in the connection's own spatial_ref_sys table; anything still unresolved falls back to the planar fit — labeled as such so you're never misled about whether you're looking at a real projection.

Declare a plain column as coordinates

Not every location lives in a geometry type. Plenty of tables store coordinates as plain text or as separate lat / lng number columns. You can declare such a column as spatial in the per-database MetaInfo — the same user-metadata layer that holds loose foreign keys, JSON column declarations, and enum declarations. Four shapes are supported:

• WKT text (POINT(-73.98 40.75)).
• GeoJSON text.
• A single lat/lng text column.
• A lat + lng pair — two separate columns combined into a point.

Once declared, that column participates in the same grid summaries, peek maps, and map panes as a native geometry column. The declaration sits on top of the schema; the DDL is untouched, and like the rest of MetaInfo it's exportable so a teammate gets the same coordinate columns on their machine.

Cross-engine parity

The map surfaces are identical across engines — the same grid glyph, peek, Map view, map pane, and Spatial Explorer. What differs is what each engine itself supports:

One SQLite caveat worth calling out: spatial columns are detected in Table Explorer and the peek map, but a raw Query Editor SELECT doesn't yet carry the column-source metadata SQLite needs to auto-detect geometry — so browse SQLite spatial data through Table Explorer, or declare the column, rather than a bare SELECT.

The small things around the map

A handful of quieter tools make the map pull its weight in day-to-day SQL work:

• Ghost-paste a copied WKT or GeoJSON string as a temporary layer, to eyeball geometry from anywhere against your data.
• Coordinate probe and a measure tool for reading positions and distances off the canvas.
• Sanity nudges — e.g. when your points look like they have latitude and longitude swapped, a quiet chip offers a one-click axis swap rather than leaving you to debug why everything landed in the ocean.
• Two-cell geometry compare, a temporal replay slider for time-stamped features, and a spatial-index coach that reads execution plans and suggests a spatial index when a predicate is scanning.

What this is — and isn't

Spatial support is for visualizing, filtering, and exporting the geometry that already lives in your database. It decodes it, maps it, filters by it (including a polygon you draw on the map), and copies it back out as WKT or GeoJSON. The one thing you draw — the filter area — is a query input, not stored data: Jam SQL Studio is deliberately not a geometry editor, so it never writes shapes back to a table or lets you author new stored geometry. And it isn't a replacement for a full GIS package like QGIS — it's a SQL client that happens to understand geometry, so you can stay in one tool when your spatial question is really a SQL question. When you need cartographic editing or heavy geoprocessing, reach for the GIS tool; when you need to see what your query returned and get it out clean, this is right where you're already working.

FAQ

Which databases support spatial columns in Jam SQL Studio?

All five relational engines: PostgreSQL/PostGIS, MySQL, SQL Server, Oracle (SDO_GEOMETRY), and SQLite (SpatiaLite and GeoPackage). Each engine's on-the-wire format is decoded to GeoJSON and rendered on a map. Kusto has no spatial types, so the spatial surfaces don't appear for Kusto connections.

Does Jam SQL Studio let me draw or edit geometry on the map?

No. Spatial support is for visualizing and exporting geometry that already lives in your database — it renders features on a map and copies them out as WKT or GeoJSON. It does not draw new shapes or write edited geometry back. It's a SQL client that maps your data, not a GIS editor.

Are curved geometries like CircularString and CurvePolygon supported?

Yes, on the engines that have them (PostgreSQL, SQL Server, Oracle, SQLite). Arcs are linearized client-side into line segments so they render on the map, but Copy WKT keeps the shape curved — a CircularString stays a CircularString, not the flattened display version. SQL Server and Oracle support root-level curve shapes (not a curve nested inside a collection). MySQL has no curve types, so this is not applicable there.

Does the map send my data anywhere?

Your geometry is decoded and rendered locally. The only network request is for basemap tiles from OpenFreeMap, and it's introduced by a one-time dismissible privacy notice. Turn the basemap off in Settings → Spatial and the map falls back to a planar graticule that renders with no network at all — which is also what happens offline or when a SRID can't be resolved.

Can I map a plain latitude/longitude column that isn't a geometry type?

Yes. Declare any column as spatial in the per-database MetaInfo: WKT text, GeoJSON text, a single lat/lng text column, or a pair of separate latitude and longitude columns. Once declared, that column participates in the same map surfaces as a native geometry column. The declaration lives on top of the schema and doesn't change the DDL.