GeoLabSpatial SQL Workbench
Worked example

Filter GeoJSON with SQL

This example uses the built-in roads GeoJSON. A normal WHERE clause selects two primary roads, while retaining the native geometry column allows the filtered LineStrings to remain visible on the map.

Input
roads.geojson
Geometry
LineString
Filter
class = 'primary'
Expected rows
2

1. Load the GeoJSON

Use Load 3-file demo or add public/demo/roads.geojson directly. GeoLab imports it through ST_Read and exposes a roads relation with id, name, class, and geometry columns.

2. Apply an attribute filter

Keep primary roads and their geometrysql
SELECT
  id,
  name,
  class,
  geometry
FROM roads
WHERE class = 'primary'
ORDER BY id;

3. Expected output

idnameclass
1Market Wayprimary
2River Roadprimary

NoteBecause geometry remains in the SELECT list, the result renders as two LineStrings. Removing geometry would produce the same two attribute rows in the table preview but no map layer.

4. Extend the query deliberately

  • Use spatial predicates when a second relation supplies comparison geometry.
  • Use DuckDB Spatial measurement functions only after confirming the coordinate system and units.
  • Keep geometry in the final projection when the result should remain spatial in GeoLab.

Sources and scope

These links document the product behavior summarized above. GeoLab-specific claims are limited to the current public v0.1.0 implementation.

  1. GeoLab roads fixtureThe exact four-feature input and expected primary rows.
  2. GeoLab GeoJSON importST_Read import and geometry normalization.
  3. DuckDB Spatial functionsOfficial reference for geometry constructors, predicates, and measurements.