29:null 2a:["$","title",null,{"children":"03. Urban Data Management | autarkjs | Observable"}] 2f:T436,

In autk-db, a workspace is an isolated database context used to organize geospatial tables. Tables created in one workspace are not visible in another, which makes workspaces useful for handling multiple cities or independent analysis scenarios without name conflicts. When the database is initialized, autk-db automatically creates a default workspace named "autk".

Geometries stored in a workspace use the coordinate reference system EPSG:3395, also known as World Mercator. This means that spatial data loaded from different sources is stored in a consistent projected coordinate system inside the workspace.

As we have previsoully seen, right after initialization, the only available workspace should be the default "autk" workspace. To inspect the current database state, we can check which one is active.

30:[{"id":"d4384f5752b7b5c5cd3f25a8eb0c11c339d9cdabad9288dcf1dbba0c70ab83fea3f1e4076ceeb24c5700c3ea216bb76f4bb0f85cd39af76a38c44e597dbcbe8e","href":"https://static.observableusercontent.com/files/d4384f5752b7b5c5cd3f25a8eb0c11c339d9cdabad9288dcf1dbba0c70ab83fea3f1e4076ceeb24c5700c3ea216bb76f4bb0f85cd39af76a38c44e597dbcbe8e","name":"elevation.tif","type":"image/tiff","lastModified":1783973794820.169,"size":56325},{"id":"bcfd8153c39fb065819d3da0eb7c0ce5cf12fb02f82326ef462865244bdb24726172509dcf5d9ee7dfbaa662c97713a08f70ede398a32715c986436aca8cff67","href":"https://static.observableusercontent.com/files/bcfd8153c39fb065819d3da0eb7c0ce5cf12fb02f82326ef462865244bdb24726172509dcf5d9ee7dfbaa662c97713a08f70ede398a32715c986436aca8cff67","name":"image.png","type":"image/png","lastModified":1783540465830.599,"size":171152},{"id":"95107652ddd89fd9412f3bba8643a9a038a9c817ed1c4bd0f7ac2690d3ddbaa779c7e82e9317ab3c6be9f37b6197946989308e8f3d0f0c2f42f20c3b60293699","href":"https://static.observableusercontent.com/files/95107652ddd89fd9412f3bba8643a9a038a9c817ed1c4bd0f7ac2690d3ddbaa779c7e82e9317ab3c6be9f37b6197946989308e8f3d0f0c2f42f20c3b60293699","name":"mnt.geojson","type":"application/geo+json","lastModified":1783606680488.742,"size":308614},{"id":"51cdee68b4acebe48bab6e997f5791f43ab94123bc7a0917e06f3dfd6b7c9bc4aafdd2bb20e02976e144ea5ea1cef778d4ab3260feb17cf33a0f02c16adb2544","href":"https://static.observableusercontent.com/files/51cdee68b4acebe48bab6e997f5791f43ab94123bc7a0917e06f3dfd6b7c9bc4aafdd2bb20e02976e144ea5ea1cef778d4ab3260feb17cf33a0f02c16adb2544","name":"mnt.csv","type":"text/csv","lastModified":1783618642861.393,"size":90879}] 2d:{"id":"11c567a880a91172","slug":"03-urban-data-management","title":"03. Urban Data Management","thumbnail":"ee289c879ed43120b10cc38d14d6266822919ff29c8b769f2b29985310d26558","access_level":"public","create_time":"$D2026-07-08T18:06:46.211Z","update_time":"$D2026-09-21T18:01:21.627Z","view_time":null,"first_public_time":"$D2026-09-26T13:36:18.421Z","has_unpublished_edits":null,"fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"da0708b4e2e72fbf","login":"autarkjs","name":"autarkjs","avatar_url":"https://avatars-next.observableusercontent.com/3e39bfb8c362b4cd667de182cfadb92766615a4805b8e6bf35cf1aca1f963943","tier":"pro_2024"},"version":469,"publish_version":469,"role":null,"authored":false,"authors":[{"type":"individual","id":"9c9fd3702a791124","login":"mlage","name":"Marcos Lage","avatar_url":"https://avatars-next.observableusercontent.com/5a7bd22b657c0e1224801f5729eac05c2b33a163251a927aa4ea576bdcf55e46","tier":null}],"members":[{"type":"team","id":"da0708b4e2e72fbf","login":"autarkjs","name":"autarkjs","avatar_url":"https://avatars-next.observableusercontent.com/3e39bfb8c362b4cd667de182cfadb92766615a4805b8e6bf35cf1aca1f963943","tier":"pro_2024","role":"editor"},{"type":"individual","id":"9c9fd3702a791124","login":"mlage","name":"Marcos Lage","avatar_url":"https://avatars-next.observableusercontent.com/5a7bd22b657c0e1224801f5729eac05c2b33a163251a927aa4ea576bdcf55e46","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":true,"trashed":false,"lapsed":null,"subscribed":null,"forks":0,"collection":{"id":"993a74142b1b1344","slug":"urban-computing-with-autark","title":"Urban Analytics with Autark","owner":{"id":"da0708b4e2e72fbf","login":"autarkjs","name":"autarkjs"}},"type":"notebook","body":{"title":"03. Urban Data Management","cells":[{"id":0,"value":"# 03. Urban Data Management\n","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":12,"value":"## About\n\n

\n This notebook was produced for the Urban Data Analytics with Autark tutorial, presented at SIBGRAPI 2026 by:\n

\n\n- João Lucas Rulff da Costa (FGV, [jlrulff@gmail.com](mailto:jlrulff@gmail.com))\n- Lucas Alexandre (UFF, [lucasalexandre@id.uff.br](mailto:lucasalexandre@id.uff.br))\n- Talisson Souza (UFF, [talissonsouza@id.uff.br](mailto:talissonsouza@id.uff.br))\n- Gustavo Moreira (UIC, [gmorei3@uic.edu](mailto:gmorei3@uic.edu))\n- Daniel Oliveira (UFF, [danielcmo@ic.uff.br](mailto:danielcmo@ic.uff.br))\n- Harish Doraiswamy (MSR, [harish.doraiswamy@microsoft.com](mailto:harish.doraiswamy@microsoft.com))\n- Fabio Miranda (UIC, [fabiom@uic.edu](mailto:fabiom@uic.edu))\n- Claudio Silva (NYU, [csilva@nyu.edu](mailto:csilva@nyu.edu))\n- Marcos Lage (UFF, [mlage@ic.uff.br](mailto:mlage@ic.uff.br))\n\n","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":14,"value":"## Table of contents\n\n\n\n

Introduction

Autark DB (`autk-db`)
Initializing a database
Workspaces

Loading data

OpenStreetMap data
GeoJSON data
CSV with WKT data
GeoTIFF data

Analytical Queries
Spatial Queries

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":29,"value":"## 1. Introduction","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":41,"value":"

\n Spatial databases are designed to store, index, and query geographic data in both vector and raster formats, enabling their analysis. They are necessary because conventional databases do not efficiently support\n spatial relationships and operations that are central to urban analytics.\n

\n

\n\n

\n By combining geometry-aware data types with spatial indexes and query languages, spatial databases make it possible to manage geospatial datasets efficiently. Well-known examples of spatial database systems are PostgreSQL with\n PostGIS, SpatiaLite, and DuckDB with its spatial extension.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":56,"value":"### 1.1. Autark DB (autk-db)","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":50,"value":"

\n

\n

\n\n

\n In this tutorial, we will use Autark DB (autk-db), the spatial database module from the Autark toolkit, which runs\n directly in the browser, eliminating the need for client-server architectures and enabling rapid prototyping of urban analytics software.\n

\n

\n\n

\n Powered by DuckDB, autk-db allows users to load, query, and transform geospatial data directly in the browser, with support for formats such as CSV, JSON, GeoJSON, and GeoTIFF obtained from open data portals (e.g.,\n NYC Open Data) and geographic data services (e.g., OpenStreetMap).\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":84,"value":"### 1.2. Initializing a database","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":100,"value":"

\n To initialize an autk-db instance in the notebook, first import the Autark package from esm.sh, a web service that delivers npm packages as browser-ready JavaScript\n modules. Then, access the AutkDb class and instantiate a new database object await db.init(), which prepares DuckDB and loads the spatial capabilities required by autk-db.\n

\n

\n\n

\n The initialized object is then returned so it can be reused in subsequent notebook cells.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":87,"value":"db = {\n const autk = await import(\"https://esm.sh/@urban-toolkit/autk?bundle\");\n const AutkDb = autk.db.AutkDb;\n\n const db = new AutkDb();\n await db.init();\n \n return db;\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":107,"value":"

\nTo test the database, we can call db.getWorkspaces(), which lists the workspaces currently managed by the database instance.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":93,"value":"db.getWorkspaces()","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":139,"value":"### 1.3. Workspaces","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":147,"value":"$2f","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":161,"value":" db.getCurrentWorkspace()","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":163,"value":"

\n The method setWorkspace() changes the current workspace. If the workspace does not already exist, autk-db creates it automatically. This is particularly useful for organizing data from multiple cities, since each city\n can be assigned its own workspace.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":167,"value":"{\n await db.setWorkspace(\"nyc\")\n return db.getWorkspaces()\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":178,"value":"db.getCurrentWorkspace()","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":31,"value":"## 2. Loading data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":112,"value":"### 2.1. OpenStreetMap data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":114,"value":"

\n OpenStreetMap data can be loaded into autk-db. The library provides the loadOsm() method that can fetch data from the Overpass API or parse previously downloaded OSM extracts, storing\n the extracted layers as named tables.\n

\n

\n\n

\n autk-db provides a simple query interface to specify the geographic area of interest and the layers to extract. Since each layer is stored in its own table,\n the data can later be queried, transformed, and retrieved as GeoJSON for visualization or analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":124,"value":"osm = {\n await db.setWorkspace(\"nyc\")\n \n const res = await db.loadOsm({\n queryArea: {\n geocodeArea: 'New York',\n areas: ['Battery Park City']\n },\n autoLoadLayers: {\n layers: ['surface', 'parks', 'water']\n }\n });\n\n return (typeof res === 'string') ? false : res;\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":127,"value":"### 2.2. GeoJSON data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":182,"value":"

\n GeoJSON data can be loaded into autk-db with the method loadGeojson(). This method stores a GeoJSON FeatureCollection as a named table inside DuckDB. The parameter\n outputTableName defines the name of the created table.\n

\n

\n\n

\n The GeoJSON can be provided either as a file URL or as an in-memory JavaScript object. Once loaded, the resulting table can be queried, transformed, or retrieved again as GeoJSON for visualization and analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":188,"value":"geojson = { \n await db.setWorkspace(\"nyc\")\n if(!osm) { return; }\n\n const mnt = await FileAttachment(\"mnt.geojson\").json();\n const table = await db.loadGeojson({\n geojsonObject: mnt,\n outputTableName: \"neighs_json\"\n });\n\n return table;\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":201,"value":"

\n After loading a dataset, we can retrieve it with getLayer(). This method reads a named table from the current workspace and returns it as GeoJSON.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":205,"value":"{\n await db.setWorkspace(\"nyc\")\n if(!geojson) { return; }\n\n return db.getLayer(\"neighs_json\") \n}\n","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":143,"value":"### 2.3. CSV with WKT data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":226,"value":"

\n CSV data can be loaded into autk-db with the method loadCsv(). This method stores a CSV file as a named table inside DuckDB. When the file contains geometries encoded as WKT, we must\n inform the geometry column through geometryColumns.\n

\n

\n\n

\n In the example below, the column wkt is used to create the spatial layer during import. Once loaded, the resulting table can be queried, transformed, or retrieved again as GeoJSON for visualization and analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":230,"value":"csv = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n \n \n const text = await FileAttachment(\"mnt.csv\").text()\n const data = d3.csvParseRows(text);\n \n const table = await db.loadCsv({\n csvObject: data,\n outputTableName: \"neighs_wkt\",\n geometryColumns: { wktColumnName: 'wkt' }\n }); \n \n return table;\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":278,"value":"

\n After loading a dataset, we can retrieve it with getLayer(). This method reads a named table from the current workspace and returns it as GeoJSON.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":280,"value":"{\n await db.setWorkspace(\"nyc\")\n if(!csv) { return; }\n \n return db.getLayer(\"neighs_wkt\") \n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":145,"value":"### 2.4. GeoTIFF data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":349,"value":"

\n GeoTIFF data can be loaded into autk-db with the method loadGeoTiff(). This method stores the raster as a named table inside DuckDB. When the file is already uploaded to Observable, we can read it\n through FileAttachment() and pass its contents as an ArrayBuffer.\n

\n

\n\n

\n In the example below, the file elevation.tif is imported as a raster table named terrain. Once loaded, the resulting table can be inspected directly or retrieved again with getRaster() for\n visualization and analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":345,"value":"rasterTable = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n \n const geotiffBuffer = await FileAttachment(\"elevation.tif\").arrayBuffer();\n \n const table = await db.loadGeoTiff({\n geotiffArrayBuffer: geotiffBuffer,\n outputTableName: \"terrain\"\n });\n \n return table;\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":353,"value":"

\n After loading a raster dataset, we can retrieve it with getRaster(). This method reads a named raster table from the current workspace and returns it as a raster FeatureCollection, which can then be used for\n rendering or further analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":356,"value":"{\n await db.setWorkspace(\"nyc\");\n if(!rasterTable) { return; }\n \n return db.getRaster(\"terrain\");\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":35,"value":"## 3. Analytical queries","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":368,"value":"

\n In autk-db, analytical queries can be written with the method rawQuery(), which executes SQL directly on the tables stored in the current workspace. Since the data is managed by DuckDB in the browser,\n this makes it possible to express familiar analytical patterns such as filtering, grouping, and aggregation without leaving the notebook.\n

\n

\n\n

\n These operations can be used to build OLAP-style analysis workflows, in which datasets are summarized across dimensions and measures. In the examples below, we query the park layer loaded earlier to show how records\n can be filtered and aggregated inside autk-db.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":370,"value":"### 3.1. Filtering data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":373,"value":"

\nAfter data is loaded, filter queries can be used to select only the records that satisfy a given condition. In the example below, we query the osm_parks table and keep only park features whose area is greater than a threshold, returning a small set of descriptive attributes for inspection.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":381,"value":"sqlFilter = \n`\nSELECT\n json_extract_string(properties, '$.name') AS name,\n json_extract_string(properties, '$.leisure') AS leisure,\n json_extract_string(properties, '$.landuse') AS landuse,\n ROUND(ST_Area(geometry)) AS area_m2\nFROM table_osm_parks\nWHERE geometry IS NOT NULL\n AND ST_Area(geometry) > 1000\nORDER BY area_m2 DESC\nLIMIT 10\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":375,"value":"filteredParks = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n\n return db.rawQuery({\n query: sqlFilter,\n output: {\n type: \"CREATE_TABLE\",\n tableName: \"large_parks\",\n source: \"user\",\n tableType: \"polygon\"\n }\n });\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":387,"value":"

\n The method rawQuery() supports different output modes through the output parameter.\n

\n

\n\n

\n When output.type is set to RETURN_OBJECT, the query result is returned directly to the notebook as an array of JavaScript objects, which is useful for inspection, summaries, and intermediate analytical\n results.\n

\n

\n\n

\n When output.type is set to CREATE_TABLE, the result of the query is stored as a new table in the current workspace. In this case, the parameter tableName defines the name of the created table.\n Optional metadata such as source and tableType can also be provided, which is useful when the query result should be treated as a new dataset for later analysis, retrieval, or visualization.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":389,"value":"### 3.2. Grouping data","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":397,"value":"

\nGroup-by queries are useful when we want to summarize data by categories and compute aggregates for each group. In the example below, we use the attributes already available in table_osm_parks to count features and sum their areas by category.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":400,"value":"sqlGroup = \n`\nSELECT\n COALESCE(\n json_extract_string(properties, '$.leisure'),\n json_extract_string(properties, '$.landuse'),\n 'unknown'\n ) AS category,\n COUNT(*) AS feature_count,\n ROUND(SUM(ST_Area(geometry))) AS total_area_m2\nFROM table_osm_parks\nWHERE geometry IS NOT NULL\nGROUP BY category\nORDER BY total_area_m2 DESC\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":394,"value":"groupedParks = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n\n return db.rawQuery({\n query: sqlGroup,\n output: { type: \"RETURN_OBJECT\" }\n });\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":39,"value":"## 4. Spatial queries","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":416,"value":"### 4.1. Spatial Join","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":405,"value":"

\n In autk-db, spatial queries can be written with the method spatialQuery(), which performs a spatial join between two tables already stored in the current workspace. The method takes a root\n table and a join table, and enriches the root table with information derived from the spatial relationship between their geometries.\n

\n

\n\n

\n This makes it possible to answer questions such as how many nearby features surround each polygon, or how values from one layer can be aggregated into another. In the example below, we use the previously loaded\n table_osm_surface and table_osm_parks tables to count nearby park features around each surface geometry.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":407,"value":"spatialJoin = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n\n return db.spatialQuery({\n tableRootName: \"table_osm_surface\",\n tableJoinName: \"table_osm_parks\",\n groupBy: [\n {\n column: \"*\",\n aggregateFn: \"count\",\n normalize: true\n }\n ]\n });\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":409,"value":"

\nAfter the spatial query is run, the root table is updated in place. We can retrieve it with getLayer() to inspect the enriched geometries and properties.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":411,"value":"{\n await db.setWorkspace(\"nyc\");\n if(!spatialJoin) { return; }\n\n return db.getLayer(\"table_osm_surface\");\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":418,"value":"### 4.2. Heatmaps","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":420,"value":"

\n Besides spatial joins, autk-db can also build heatmaps with the method buildHeatmap(). This method creates a regular grid over the workspace extent and aggregates values from a source table into its\n cells using a spatial proximity rule.\n

\n

\n\n

\n In the example below, we use the park layer already loaded in the notebook to create a raster heatmap. Each grid cell stores the number of nearby park features, producing a compact representation that can later be retrieved as raster\n data for visualization and analysis.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":424,"value":"parksHeatmap = {\n await db.setWorkspace(\"nyc\");\n if(!osm) { return; }\n\n return db.buildHeatmap({\n tableJoinName: \"table_osm_parks\",\n near: { distance: 200 },\n outputTableName: \"parks_heatmap\",\n groupBy: [\n {\n column: \"*\",\n aggregateFn: \"count\",\n normalize: true\n }\n ],\n grid: {\n rows: 40,\n columns: 40\n }\n });\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":426,"value":"

\nAfter a heatmap is created, we can retrieve it with getRaster(), which returns it as a raster FeatureCollection.\n

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":430,"value":"{\n await db.setWorkspace(\"nyc\");\n if(!parksHeatmap) { return; }\n\n return db.getRaster(\"parks_heatmap\");\n}","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"}],"files":"$W30","stdlib":"2","titling":"auto"}} 2e:"$2d:body"