# Overture Maps for Romania: divisions, places and buildings > The open map of Romania, clipped out of the Overture Maps Foundation’s public GeoParquet release: all 19,485 administrative entities (the country, its 42 counties/județe, its 3,179 municipalities/UATs and its 14,414 localities) with their territory polygons and border lines, 327,091 points of interest, and 12,474,972 building footprints. Geometry is published as WKT in WGS 84 alongside a bounding box and a Hilbert spatial key, so a map-window question reads only the part of the country it asks about. Overture conflates OpenStreetMap, machine-detected building footprints from Microsoft and Google, Esri Community Maps and commercial place providers; every row carries its own provenance and its own licence in the `sources` column. Three of Overture’s six themes are included — divisions, places and buildings. Addresses are absent because, measured, the theme contains no Romanian rows at all; transportation and base are deferred for the reasons given in the README. REFERENCED LIVE, NOT COPIED: all five tables are published as views over Overture’s own GeoParquet release on its public AWS Open Data bucket, so no row is stored in this directory’s lake and every query reads Overture directly. That means the data is always exactly the release the published view points at — a newer Overture release becomes visible the moment this connector is re-run — and it means there is no history here beyond that one release, no row counts or column statistics of this platform’s own making, and a query needs network access to s3://overturemaps-us-west-2 (public, no credentials) plus DuckDB’s `spatial` extension loaded locally, for reading the source as much as for turning `geometry_wkt` back into a geometry. - Dataset id: `overture-maps-ro` - Update cadence: monthly - Upstream source: https://docs.overturemaps.org/getting-data/ - Tags: romania, geospatial, openstreetmap, overture, buildings, places, poi, administrative-divisions, boundaries, basemap - Current version: ingest `01M1NPWYYD0QR1MHKNF6QFQ2VV`, snapshot 2026-09-04, generated 2026-09-04T08:00:02.944Z ## Licence and attribution - Licence: Open Database License v1.0 (divisions and buildings) and Community Data License Agreement – Permissive 2.0 (places) (`ODbL-1.0`) - Licence text: https://docs.overturemaps.org/attribution/ - Required attribution: © OpenStreetMap contributors, Overture Maps Foundation (overturemaps.org). The divisions, division_areas, division_boundaries and buildings tables are available under the Open Database License (ODbL) v1.0. The places table is available under CDLA-Permissive-2.0. - Notes: LICENSING IS PER THEME, AND THIS DATASET SHIPS TWO OF THEM. Overture states the terms theme by theme at https://docs.overturemaps.org/attribution/, and they are not the same. (1) The DIVISIONS theme — the tables divisions, division_areas and division_boundaries — is ODbL-1.0, because it is built on OpenStreetMap, with contributions from geoBoundaries, Esri Community Maps and LINZ under CC-BY-4.0. Required credit: "© OpenStreetMap contributors". (2) The BUILDINGS theme is ODbL-1.0 for the same reason, and it is the most genuinely mixed of the three: it conflates OpenStreetMap (ODbL-1.0) with Microsoft Global ML Building Footprints (ODbL-1.0), Google Open Buildings (CC-BY-4.0), Esri Community Maps (CC-BY-4.0), the USGS 3D Elevation Program and several national mapping agencies. The licence that governs an individual row is in that row: sources[].license, lifted out as primary_source_license. (3) The PLACES theme is CDLA-Permissive-2.0, from Meta, Microsoft, PinMeTo, Krick, RenderSEO, DAC and BrightQuery, with Foursquare data under Apache-2.0 and AllThePlaces under CC0-1.0. Required credit: "Available under CDLA Permissive 2.0". ODbL IS SHARE-ALIKE. A derived database built on the divisions or buildings tables must itself be offered under ODbL, and any public use of it must attribute OpenStreetMap. The places table carries no such obligation, so keep the two apart if that matters to you — joining them makes the result ODbL. WHAT WE PUBLISH AND WHAT WE DO NOT. This is a derived work: Overture’s own columns for three of six themes, clipped to Romania, with geometry converted from GeoParquet to WKT and with area, length, centroid and Hilbert-key columns computed here. Nothing is aggregated away and no row is filtered on quality. One column is deliberately dropped: places.emails. Overture publishes it as a business contact channel, but in Romania a great many places are sole traders (PFA, II) whose registered address is an individual’s personal mailbox, and an email address is the field most likely to be a natural person’s rather than a business’s. Websites, telephone numbers and social profiles are kept, being channels a business publishes in order to be contacted. A reuser who needs the emails can read them from the Overture bucket directly. ACCURACY. Overture is a conflation of contributed and machine-detected data, not a cadastre and not a public register. Places carry a confidence score and should be counted with a stated threshold; building attributes are absent far more often than they are wrong; population on a division row is an OpenStreetMap contribution with no date, not a census figure. Corrections belong upstream — primary_source_record_id identifies the record to fix in OpenStreetMap or in whichever provider supplied it. Reproduce the attribution line verbatim anywhere you republish this data. ## Manifest - Start here for how this directory works: https://data.bunnytech.app/llms.txt - This dataset: https://data-directory.fsn1.your-objectstorage.com/public/overture-maps-ro/manifest.json - All datasets: https://data-directory.fsn1.your-objectstorage.com/public/index.json - Human page: https://data.bunnytech.app/datasets/overture-maps-ro The manifest is the contract: file URLs, row counts, column types, min/max statistics and example queries all live there. Re-read it to discover a new version. ## Fastest path — Parquet exports Immutable, physically sorted snapshot exports. No catalog fetch, best row-group pruning, safe to cache forever. Register one view per table: ```sql INSTALL httpfs; LOAD httpfs; -- divisions: queried live at the source, never copied here — no parquet export. -- division_areas: queried live at the source, never copied here — no parquet export. -- division_boundaries: queried live at the source, never copied here — no parquet export. -- places: queried live at the source, never copied here — no parquet export. -- buildings: queried live at the source, never copied here — no parquet export. ``` Example queries: -- Every commune in Cluj county, with its area: The administrative register on its own. Overture calls a Romanian UAT a "county", so subtype = 'county' selects the comune, orașe and municipii; region is the ISO 3166-2 code of the județ. These are still the leading `sortBy` columns, but sortBy is advisory on a federated table (nothing here is physically sorted by this platform) — at 19,485 divisions rows, one query is one Overture object list read straight off S3, not a pruned scan. ```sql INSTALL spatial; LOAD spatial; CREATE OR REPLACE SECRET "overture_maps_us_west_2" (TYPE s3, SCOPE 's3://overturemaps-us-west-2', PROVIDER 'config', REGION 'us-west-2'); ATTACH IF NOT EXISTS ':memory:' AS "overture_maps_ro"; CREATE SCHEMA IF NOT EXISTS "overture_maps_ro"."main"; CREATE OR REPLACE VIEW "overture_maps_ro"."main"."divisions" AS SELECT d.id AS division_id, '2026-08-19.0' AS release, d.subtype AS subtype, d.class AS class, d.names."primary" AS name, lower(strip_accents(d.names."primary")) AS name_lc, CASE WHEN d.names.common IS NULL THEN NULL ELSE to_json(d.names.common) END AS names_common, d.admin_level AS admin_level, d.country AS country, d.region AS region, d.parent_division_id AS parent_division_id, list_filter(d.hierarchies[1], lambda h: h.subtype = 'region')[1].name AS region_name, list_filter(d.hierarchies[1], lambda h: h.subtype = 'region')[1].division_id AS region_division_id, list_filter(d.hierarchies[1], lambda h: h.subtype = 'county')[1].name AS county_name, list_filter(d.hierarchies[1], lambda h: h.subtype = 'county')[1].division_id AS county_division_id, to_json(d.hierarchies) AS hierarchies, d.population AS population, d.wikidata AS wikidata, to_json(d.capital_division_ids) AS capital_division_ids, ST_X(d.geometry) AS longitude, ST_Y(d.geometry) AS latitude, ST_Hilbert((d.bbox.xmin + d.bbox.xmax) / 2, (d.bbox.ymin + d.bbox.ymax) / 2, {'min_x': 20.2, 'min_y': 43.5, 'max_x': 30.1, 'max_y': 48.3}::BOX_2D)::BIGINT AS spatial_key, d.bbox.xmin AS bbox_min_longitude, d.bbox.xmax AS bbox_max_longitude, d.bbox.ymin AS bbox_min_latitude, d.bbox.ymax AS bbox_max_latitude, d.version AS version, to_json(list_transform(d.sources, lambda s: { 'property': s.property, 'dataset': s.dataset, 'license': s.license, 'record_id': s.record_id, 'update_time': s.update_time })) AS sources, d.sources[1].dataset AS primary_source_dataset, d.sources[1].license AS primary_source_license, d.sources[1].record_id AS primary_source_record_id, TRY_CAST(d.sources[1].update_time AS TIMESTAMPTZ) AS source_updated_at, DATE '2026-09-04' AS snapshot_date, TIMESTAMPTZ '2026-09-04T07:59:57.901Z' AS ingested_at FROM read_parquet('s3://overturemaps-us-west-2/release/2026-08-19.0/theme=divisions/type=division/*.parquet', union_by_name = true) AS d WHERE d.country = 'RO'; CREATE OR REPLACE VIEW "overture_maps_ro"."main"."division_areas" AS SELECT a.id AS area_id, '2026-08-19.0' AS release, a.division_id AS division_id, a.subtype AS subtype, a.class AS class, a.names."primary" AS name, lower(strip_accents(a.names."primary")) AS name_lc, a.admin_level AS admin_level, a.country AS country, a.region AS region, a.is_land AS is_land, a.is_territorial AS is_territorial, ST_AsText(a.geometry) AS geometry_wkt, ST_GeometryType(a.geometry) AS geometry_type, ST_NPoints(a.geometry) AS geometry_point_count, ST_Area_Spheroid(a.geometry) / 1000000.0 AS area_sq_km, ST_X(ST_Centroid(a.geometry)) AS centroid_longitude, ST_Y(ST_Centroid(a.geometry)) AS centroid_latitude, ST_Hilbert((a.bbox.xmin + a.bbox.xmax) / 2, (a.bbox.ymin + a.bbox.ymax) / 2, {'min_x': 20.2, 'min_y': 43.5, 'max_x': 30.1, 'max_y': 48.3}::BOX_2D)::BIGINT AS spatial_key, a.bbox.xmin AS bbox_min_longitude, a.bbox.xmax AS bbox_max_longitude, a.bbox.ymin AS bbox_min_latitude, a.bbox.ymax AS bbox_max_latitude, a.version AS version, to_json(list_transform(a.sources, lambda s: { 'property': s.property, 'dataset': s.dataset, 'license': s.license, 'record_id': s.record_id, 'update_time': s.update_time })) AS sources, a.sources[1].dataset AS primary_source_dataset, a.sources[1].license AS primary_source_license, a.sources[1].record_id AS primary_source_record_id, TRY_CAST(a.sources[1].update_time AS TIMESTAMPTZ) AS source_updated_at, DATE '2026-09-04' AS snapshot_date, TIMESTAMPTZ '2026-09-04T07:59:57.901Z' AS ingested_at FROM read_parquet('s3://overturemaps-us-west-2/release/2026-08-19.0/theme=divisions/type=division_area/*.parquet', union_by_name = true) AS a WHERE a.country = 'RO'; SELECT d.name, a.area_sq_km, d.population FROM overture_maps_ro.main.divisions d JOIN overture_maps_ro.main.division_areas a ON a.division_id = d.division_id AND a.release = d.release WHERE d.release = '2026-08-19.0' AND d.subtype = 'county' AND d.region = 'RO-CJ' ORDER BY a.area_sq_km DESC; ``` -- Pharmacies per county, counted at a stated confidence: The threshold is part of the answer, not a detail: dropping it roughly doubles the count. address_region is the provider’s claim about the address, which is good enough for a county roll-up and far cheaper than a spatial join. ```sql INSTALL spatial; LOAD spatial; CREATE OR REPLACE SECRET "overture_maps_us_west_2" (TYPE s3, SCOPE 's3://overturemaps-us-west-2', PROVIDER 'config', REGION 'us-west-2'); ATTACH IF NOT EXISTS ':memory:' AS "overture_maps_ro"; CREATE SCHEMA IF NOT EXISTS "overture_maps_ro"."main"; CREATE OR REPLACE VIEW "overture_maps_ro"."main"."places" AS WITH ro AS ( SELECT ST_Union_Agg(geometry) AS geom FROM read_parquet('s3://overturemaps-us-west-2/release/2026-08-19.0/theme=divisions/type=division_area/*.parquet', union_by_name = true) WHERE country = 'RO' AND subtype = 'country' ) SELECT p.id AS place_id, '2026-08-19.0' AS release, p.names."primary" AS name, lower(strip_accents(p.names."primary")) AS name_lc, CASE WHEN p.names.common IS NULL THEN NULL ELSE to_json(p.names.common) END AS names_common, p.categories."primary" AS category, to_json(p.categories.alternate) AS categories_alternate, p.basic_category AS basic_category, p.taxonomy."primary" AS taxonomy_category, to_json(p.taxonomy.hierarchy) AS taxonomy_hierarchy, p.confidence AS confidence, p.operating_status AS operating_status, p.brand."names"."primary" AS brand_name, p.brand.wikidata AS brand_wikidata, p.addresses[1].freeform AS address_freeform, p.addresses[1].locality AS address_locality, p.addresses[1].postcode AS address_postcode, p.addresses[1].region AS address_region, p.addresses[1].country AS address_country, to_json(p.websites) AS websites, to_json(p.phones) AS phones, to_json(p.socials) AS socials, ST_X(p.geometry) AS longitude, ST_Y(p.geometry) AS latitude, ST_Hilbert((p.bbox.xmin + p.bbox.xmax) / 2, (p.bbox.ymin + p.bbox.ymax) / 2, {'min_x': 20.2, 'min_y': 43.5, 'max_x': 30.1, 'max_y': 48.3}::BOX_2D)::BIGINT AS spatial_key, p.bbox.xmin AS bbox_min_longitude, p.bbox.xmax AS bbox_max_longitude, p.bbox.ymin AS bbox_min_latitude, p.bbox.ymax AS bbox_max_latitude, p.version AS version, to_json(list_transform(p.sources, lambda s: { 'property': s.property, 'dataset': s.dataset, 'license': s.license, 'record_id': s.record_id, 'update_time': s.update_time })) AS sources, p.sources[1].dataset AS primary_source_dataset, p.sources[1].license AS primary_source_license, p.sources[1].record_id AS primary_source_record_id, TRY_CAST(p.sources[1].update_time AS TIMESTAMPTZ) AS source_updated_at, DATE '2026-09-04' AS snapshot_date, TIMESTAMPTZ '2026-09-04T07:59:57.901Z' AS ingested_at FROM read_parquet('s3://overturemaps-us-west-2/release/2026-08-19.0/theme=places/type=place/*.parquet', union_by_name = true) AS p, ro WHERE p.bbox.xmin >= 20.2 AND p.bbox.xmax <= 30.1 AND p.bbox.ymin >= 43.5 AND p.bbox.ymax <= 48.3 AND ST_Intersects(p.geometry, ro.geom); SELECT address_region, count(*) AS pharmacies FROM overture_maps_ro.main.places WHERE release = '2026-08-19.0' AND category = 'pharmacy' AND confidence >= 0.5 GROUP BY 1 ORDER BY 2 DESC; ``` ## Live lake — DuckLake catalog with time travel Every table in this dataset is queried live at its source, so nothing was copied into a DuckLake and the catalog published beside it holds no tables. Use the setup printed with the example queries above, or the `view.sql` of the table you want from `manifest.json` — that is the query, in full, against the upstream source. ## Wholesale — S3 access For bulk downloads, read the bucket prefix directly over S3 with httpfs: ```sql INSTALL httpfs; LOAD httpfs; CREATE SECRET hetzner ( TYPE s3, ENDPOINT 'fsn1.your-objectstorage.com', URL_STYLE 'path', KEY_ID '', SECRET '' ); SELECT * FROM read_parquet('s3://data-directory/public/overture-maps-ro/v/01M1NPWYYD0QR1MHKNF6QFQ2VV/**/*.parquet'); ``` ## Schema ### divisions One row per Romanian administrative entity, as a labelled point: the country, its 42 regions (județele plus municipiul București), its 3,179 counties — which in Romania are the UATs, the comune, orașe and municipii — its 14,414 localities (sate and localități componente) and the neighbourhood subtypes below them. 19,485 rows in release 2026-08-19.0. Overture’s subtype names are American, so read `region` as județ and `county` as comună/oraș/municipiu; `region_name` and `county_name` flatten the hierarchy so neither reading requires a self-join. The polygon of each entity is in `division_areas`, joined on `division_id`. - 0 rows · 0 B · write mode `snapshot_history` - Physically sorted by: `release`, `subtype`, `region`, `name_lc`, `division_id` - Primary key: `release`, `division_id` - Text search columns: `name` - Files: 0 Columns: - `division_id` VARCHAR NOT NULL — Overture GERS id — the Global Entity Reference System UUID that identifies this division. It is stable across releases for the same real-world entity, which is what makes comparing two releases, and joining to anybody else’s Overture-derived data, possible at all. Joins to division_areas.division_id and to divisions.parent_division_id. - `release` VARCHAR NOT NULL — The Overture release this row was read from, e.g. "2026-08-19.0" — a release date plus a within-day revision number. This table is FEDERATED (materialize: "view" in index.ts), so the value is a CONSTANT: every row carries the one release the published view currently points at, not a history of releases this platform has ever read. Re-running this connector at a different release REPLACES that constant for every row rather than adding a second release alongside it — there is no way to see two releases through this column at once. Overture cuts a release roughly monthly and keeps only the two most recent in the bucket; this column names whichever one the view was last built against. - `subtype` VARCHAR — The level of the entity in Overture’s worldwide vocabulary: country, region, county, locality, macrohood, neighborhood or microhood. Mapped onto Romania: region = județ (42 of them, București included), county = UAT, i.e. comună, oraș or municipiu (3,179), locality = sat or localitate componentă (14,414), and the three -hood subtypes are informal quarters inside a town (1,849 together). - `class` VARCHAR — A finer label where Overture has one, and only for localities in Romania: village (13,531 rows), hamlet (546), town (227) or city (104). NULL for every other subtype and for six localities Overture left unclassified. - `name` VARCHAR — The primary name, in the language Overture treats as local — Romanian throughout Romania, with diacritics: "Cluj-Napoca", "Târgu Mureș", "Mehedinți". - `name_lc` VARCHAR — The primary name, lower-cased and stripped of diacritics ("targu mures"). It exists so a search finds "Târgu Mureș" when the reader typed "targu mures": matching on lower(name) is a function of the column and defeats parquet statistics, while a prefix range on this materialised companion does not. - `names_common` JSON — The entity’s name in other languages, as a JSON object keyed by language code — for Romania mostly Hungarian (6,285 entities), Ukrainian (12,245), Russian, German and Serbian, which is the minority-language geography of Transylvania, Banat, Bucovina and the Banat Serbian villages written down. NULL where Overture holds no translation. - `admin_level` INTEGER — The OpenStreetMap admin_level the entity was imported at: 0 for the country, 1 for a județ, 2 for a UAT. NULL for localities and the neighbourhood subtypes, which are places rather than administrative units and carry no level. - `country` VARCHAR — ISO 3166-1 alpha-2 code of the country the entity belongs to. Always "RO" here — this is the column the whole table is selected on, kept so the filter is visible in the published data rather than only in the connector. - `region` VARCHAR — ISO 3166-2 code of the județ the entity sits in, e.g. "RO-CJ" for Cluj, "RO-B" for București. Present on all but the country row itself. This is the join key most Romanian statistical datasets use, which is why it is worth having as a plain string. - `parent_division_id` VARCHAR — The GERS id of the entity one level up — a locality’s UAT, a UAT’s județ, a județ’s country. NULL only for the country row. Walking this column upwards reproduces `hierarchies`. - `region_name` VARCHAR — The name of the județ this entity belongs to, taken from the first chain in `hierarchies` — "Mehedinți", "Cluj". Flattened out of the nested structure because "everything in județul X" is the single most common question asked of Romanian administrative data, and it should not need a recursive join. - `region_division_id` VARCHAR — GERS id of the județ named by region_name. - `county_name` VARCHAR — The name of the UAT — the comună, oraș or municipiu — this entity belongs to, from the same hierarchy chain. For a locality this is its commune; for a UAT row it is its own name. - `county_division_id` VARCHAR — GERS id of the UAT named by county_name. - `hierarchies` JSON — Every ancestry chain Overture records for this entity, as nested JSON: a list of chains, each a list of {division_id, subtype, name} running from the country down to the entity itself. Usually one chain; more than one where an entity is claimed by two parents. Kept whole because the flattened region_name/county_name columns cannot represent a second chain. - `population` INTEGER [people] — Population as OpenStreetMap records it for this entity, present on 13,645 of the 19,485 Romanian rows. It is a contributed figure, not a census result: it is undated, unevenly maintained, and for a UAT row it frequently describes the seat rather than the whole commune. Use it for ordering and orientation, and use INS census data for anything that has to be right. - `wikidata` VARCHAR — Wikidata entity id, e.g. "Q100126", present on 14,467 Romanian rows. The bridge to Wikipedia, to Wikidata’s own SIRUTA codes and to every other dataset keyed on Wikidata. - `capital_division_ids` JSON — GERS ids of the entities that are this one’s seat — for a județ, its reședință de județ; for a UAT, its centre. A JSON array because an entity can have more than one declared seat. Present on 3,216 Romanian rows. - `longitude` DOUBLE [degrees] — Longitude of the label point Overture places for this entity (WGS 84). It is a representative point for putting a name on a map, not a centroid of the territory — for that, use division_areas.centroid_longitude. - `latitude` DOUBLE [degrees] — Latitude of the label point (WGS 84). See longitude. - `spatial_key` BIGINT — Hilbert curve index of the bounding box’s centre, computed over the fixed Romanian extent 20.2–30.1 °E by 43.5–48.3 °N. A space-filling curve numbers a two-dimensional area so that neighbouring numbers are neighbouring places. ADVISORY on this FEDERATED table: it is computed by the published view at query time, not by a physical sort this platform ever performed, so filtering or sorting on it buys no pruning of its own — use it as an ORDER BY or window key in your own query, not as a reason a filter on it will be fast. Deterministic and comparable between releases because the extent is a constant, never recomputed from the data. Not a geographic coordinate, and means nothing outside this dataset. - `bbox_min_longitude` DOUBLE [degrees] — West edge of the feature’s axis-aligned bounding box, in WGS 84 degrees, copied from Overture’s own `bbox` struct. For a point feature all four edges equal its coordinates. Filtering the four bbox columns is the cheap way to ask a map-window question, and the table’s spatial sort order is what makes it prune. - `bbox_max_longitude` DOUBLE [degrees] — East edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_min_latitude` DOUBLE [degrees] — South edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_max_latitude` DOUBLE [degrees] — North edge of the feature’s bounding box, in WGS 84 degrees. - `version` INTEGER — Overture’s own revision counter for this feature, incremented whenever the feature changes between releases. Comparing it across two releases is the cheap way to find what moved. - `sources` JSON — Overture’s `sources` list, whole: one entry per upstream contribution, with `property` (the field it supplied, empty string meaning the whole feature), `dataset` (OpenStreetMap, Esri Community Maps, Microsoft ML Buildings, …), `license` (the SPDX id THAT contribution carries — the buildings theme genuinely mixes ODbL-1.0 and CC-BY-4.0 row by row), `record_id` (the id in the upstream dataset) and `update_time`. Kept in full because it is what a reuser needs to attribute the row correctly. - `primary_source_dataset` VARCHAR — The `dataset` of the first entry in `sources`, lifted out as a scalar so "which rows come from OpenStreetMap" is a plain equality filter rather than a JSON scan. For Romanian divisions this is OpenStreetMap for 32,115 contributions and Esri Community Maps for 377. - `primary_source_license` VARCHAR — The SPDX licence id of the first entry in `sources` — the licence that actually governs this row, which is not always the theme’s headline licence. Check it before republishing a subset. - `primary_source_record_id` VARCHAR — The identifier this feature carries in its upstream dataset, e.g. "n461880920@6" for an OpenStreetMap node at version 6. It is how a row is traced back to the source that produced it, and how a correction is reported upstream rather than here. - `source_updated_at` TIMESTAMPTZ — When the upstream record behind the first `sources` entry last changed, as the source stated it. Overture requires `update_time` to carry an explicit offset (`Z` or `+HH:MM`); TRY_CAST parses whichever one the source used and this column stores the resulting absolute instant, which DuckDB always reads back out in UTC. NULL when the source published no timestamp or published one this connector could not parse — the raw string is still in `sources`. This is the age of the FACT; `snapshot_date` is the age of our copy of it. - `snapshot_date` DATE NOT NULL — The UTC calendar day the run that PUBLISHED THIS VIEW happened — not the age of the data. This table is FEDERATED, so, like `release`, this is one constant for every row: the rows themselves are read from Overture live, at the moment a reader queries them, not copied on this day. An Overture release is cut once a month and the facts inside it are older still — use `source_updated_at` for that. - `ingested_at` TIMESTAMP NOT NULL — The UTC instant at which the run that PUBLISHED THIS VIEW started. One constant for every row, for the same reason as `snapshot_date`: nothing here was ever copied at this instant, only the view definition was. ### division_areas One row per territory polygon of a Romanian division — 7,275 in release 2026-08-19.0: the country twice (its land territory and its Black Sea maritime zone), 42 regions (județe), 3,179 counties (UATs), 3,503 localities and 549 neighbourhood-level areas. This is the table to join when you need a shape rather than a label: `geometry_wkt` is the polygon in WGS 84 and `ST_GeomFromText` turns it back into a geometry. It is also the table this connector clips itself against — Romania’s outline here is the outline every place and building in the dataset was selected with. - 0 rows · 0 B · write mode `snapshot_history` - Physically sorted by: `release`, `subtype`, `region`, `name_lc`, `area_id` - Primary key: `release`, `area_id` - Text search columns: `name` - Files: 0 Columns: - `area_id` VARCHAR NOT NULL — GERS id of the area feature itself. Distinct from division_id: one division can have more than one area, which is exactly how Romania has both a land polygon and a maritime one. - `release` VARCHAR NOT NULL — The Overture release this row was read from, e.g. "2026-08-19.0" — a release date plus a within-day revision number. This table is FEDERATED (materialize: "view" in index.ts), so the value is a CONSTANT: every row carries the one release the published view currently points at, not a history of releases this platform has ever read. Re-running this connector at a different release REPLACES that constant for every row rather than adding a second release alongside it — there is no way to see two releases through this column at once. Overture cuts a release roughly monthly and keeps only the two most recent in the bucket; this column names whichever one the view was last built against. - `division_id` VARCHAR — GERS id of the division whose territory this is. Joins to divisions.division_id. - `subtype` VARCHAR — The level of the division this area belongs to, in Overture’s vocabulary: country, region (județ), county (UAT), locality, macrohood, neighborhood or microhood. - `class` VARCHAR — "land" for a land territory, "maritime" for a maritime zone. Only Romania itself has a maritime row here; every other Romanian area is land. Filtering on class = 'land' is how you avoid drawing the Black Sea EEZ as if it were the country. - `name` VARCHAR — The division’s primary name, repeated here so the polygon is readable without a join. - `name_lc` VARCHAR — The primary name, lower-cased and stripped of diacritics, for accent-insensitive search. - `admin_level` INTEGER — The OpenStreetMap admin_level of the division, where it has one. - `country` VARCHAR — ISO 3166-1 alpha-2 code. Always "RO" — the selection column. - `region` VARCHAR — ISO 3166-2 code of the județ the area lies in, e.g. "RO-CJ". - `is_land` BOOLEAN — True when the polygon covers land. Overture sets it per area, so a coastal UAT whose area includes water can be told apart from an inland one. - `is_territorial` BOOLEAN — True when the polygon is a territorial-waters or EEZ claim rather than land territory. - `geometry_wkt` TEXT — The territory as WKT in WGS 84 (EPSG:4326) — POLYGON or MULTIPOLYGON. This is the shape itself, not a link to it: ST_GeomFromText(geometry_wkt) gives a real geometry to intersect, buffer, simplify or render. Romanian areas average about 6,400 characters; the country outline is far larger. - `geometry_type` VARCHAR — What ST_GeometryType says about the shape: POLYGON for 7,235 Romanian areas, MULTIPOLYGON for the 40 whose territory comes in more than one piece (exclaves, islands, the Danube Delta’s fragmented communes). - `geometry_point_count` INTEGER — How many vertices the polygon has. A cheap proxy for how detailed — and how expensive to draw — a shape is, and the column to filter on when picking a simplification threshold. - `area_sq_km` DOUBLE [km²] — Area of the polygon in square kilometres, computed on the WGS 84 spheroid (ST_Area_Spheroid), so it is a true area and not degrees squared. Overture does not publish it; it is derived here because "how big is this commune" is otherwise a spatial function every reader has to remember to spell correctly. - `centroid_longitude` DOUBLE [degrees] — Longitude of the polygon’s centroid (WGS 84). The geometric centre of the territory, which is not the same point as divisions.longitude — that one is where a map label looks best. - `centroid_latitude` DOUBLE [degrees] — Latitude of the polygon’s centroid (WGS 84). - `spatial_key` BIGINT — Hilbert curve index of the bounding box’s centre, computed over the fixed Romanian extent 20.2–30.1 °E by 43.5–48.3 °N. A space-filling curve numbers a two-dimensional area so that neighbouring numbers are neighbouring places. ADVISORY on this FEDERATED table: it is computed by the published view at query time, not by a physical sort this platform ever performed, so filtering or sorting on it buys no pruning of its own — use it as an ORDER BY or window key in your own query, not as a reason a filter on it will be fast. Deterministic and comparable between releases because the extent is a constant, never recomputed from the data. Not a geographic coordinate, and means nothing outside this dataset. - `bbox_min_longitude` DOUBLE [degrees] — West edge of the feature’s axis-aligned bounding box, in WGS 84 degrees, copied from Overture’s own `bbox` struct. For a point feature all four edges equal its coordinates. Filtering the four bbox columns is the cheap way to ask a map-window question, and the table’s spatial sort order is what makes it prune. - `bbox_max_longitude` DOUBLE [degrees] — East edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_min_latitude` DOUBLE [degrees] — South edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_max_latitude` DOUBLE [degrees] — North edge of the feature’s bounding box, in WGS 84 degrees. - `version` INTEGER — Overture’s own revision counter for this feature, incremented whenever the feature changes between releases. Comparing it across two releases is the cheap way to find what moved. - `sources` JSON — Overture’s `sources` list, whole: one entry per upstream contribution, with `property` (the field it supplied, empty string meaning the whole feature), `dataset` (OpenStreetMap, Esri Community Maps, Microsoft ML Buildings, …), `license` (the SPDX id THAT contribution carries — the buildings theme genuinely mixes ODbL-1.0 and CC-BY-4.0 row by row), `record_id` (the id in the upstream dataset) and `update_time`. Kept in full because it is what a reuser needs to attribute the row correctly. - `primary_source_dataset` VARCHAR — The `dataset` of the first entry in `sources`, lifted out as a scalar so "which rows come from OpenStreetMap" is a plain equality filter rather than a JSON scan. For Romanian divisions this is OpenStreetMap for 32,115 contributions and Esri Community Maps for 377. - `primary_source_license` VARCHAR — The SPDX licence id of the first entry in `sources` — the licence that actually governs this row, which is not always the theme’s headline licence. Check it before republishing a subset. - `primary_source_record_id` VARCHAR — The identifier this feature carries in its upstream dataset, e.g. "n461880920@6" for an OpenStreetMap node at version 6. It is how a row is traced back to the source that produced it, and how a correction is reported upstream rather than here. - `source_updated_at` TIMESTAMPTZ — When the upstream record behind the first `sources` entry last changed, as the source stated it. Overture requires `update_time` to carry an explicit offset (`Z` or `+HH:MM`); TRY_CAST parses whichever one the source used and this column stores the resulting absolute instant, which DuckDB always reads back out in UTC. NULL when the source published no timestamp or published one this connector could not parse — the raw string is still in `sources`. This is the age of the FACT; `snapshot_date` is the age of our copy of it. - `snapshot_date` DATE NOT NULL — The UTC calendar day the run that PUBLISHED THIS VIEW happened — not the age of the data. This table is FEDERATED, so, like `release`, this is one constant for every row: the rows themselves are read from Overture live, at the moment a reader queries them, not copied on this day. An Overture release is cut once a month and the facts inside it are older still — use `source_updated_at` for that. - `ingested_at` TIMESTAMP NOT NULL — The UTC instant at which the run that PUBLISHED THIS VIEW started. One constant for every row, for the same reason as `snapshot_date`: nothing here was ever copied at this instant, only the view definition was. ### division_boundaries One row per border line — 8,043 in release 2026-08-19.0. A boundary is the line itself, shared by the divisions on both sides of it rather than duplicated per division, which is why `division_ids` is a list. This is the table for drawing borders without the double-drawn seams you get from outlining polygons, and for asking which stretches of Romania’s border are disputed, maritime or purely administrative. - 0 rows · 0 B · write mode `snapshot_history` - Physically sorted by: `release`, `subtype`, `region`, `spatial_key`, `boundary_id` - Primary key: `release`, `boundary_id` - Files: 0 Columns: - `boundary_id` VARCHAR NOT NULL — GERS id of the boundary line. - `release` VARCHAR NOT NULL — The Overture release this row was read from, e.g. "2026-08-19.0" — a release date plus a within-day revision number. This table is FEDERATED (materialize: "view" in index.ts), so the value is a CONSTANT: every row carries the one release the published view currently points at, not a history of releases this platform has ever read. Re-running this connector at a different release REPLACES that constant for every row rather than adding a second release alongside it — there is no way to see two releases through this column at once. Overture cuts a release roughly monthly and keeps only the two most recent in the bucket; this column names whichever one the view was last built against. - `division_ids` JSON — GERS ids of the divisions this line separates, as a JSON array — normally the two on either side. Joins to divisions.division_id, and it is a list because a border belongs to both its neighbours equally. - `subtype` VARCHAR — The level of the divisions the line separates: country, region (județ), county (UAT), locality or a neighbourhood subtype. - `class` VARCHAR — A finer label where Overture has one for the boundary. - `admin_level` INTEGER — The OpenStreetMap admin_level of the boundary, where it has one. - `country` VARCHAR — ISO 3166-1 alpha-2 code. Always "RO" — the selection column. - `region` VARCHAR — ISO 3166-2 code of the județ the line lies in or along. - `is_disputed` BOOLEAN — True where the two sides do not agree on where the line runs. None of Romania’s boundaries were flagged in release 2026-08-19.0; the column matters because a renderer must not present a disputed line as settled. - `is_land` BOOLEAN — True where the line runs over land rather than water. - `is_territorial` BOOLEAN — True where the line is a territorial-waters or EEZ limit rather than a land border. - `geometry_wkt` TEXT — The border line as WKT in WGS 84 (EPSG:4326) — LINESTRING for 7,968 Romanian boundaries, MULTILINESTRING for the 75 that come in disconnected pieces. ST_GeomFromText turns it back into a geometry. - `geometry_type` VARCHAR — LINESTRING or MULTILINESTRING, as ST_GeometryType reports it. - `geometry_point_count` INTEGER — How many vertices the line has. - `length_km` DOUBLE [km] — Length of the line in kilometres, measured on the WGS 84 spheroid (ST_Length_Spheroid). Derived here rather than published by Overture, so "how long is the Romanian–Bulgarian border" is a SUM rather than a spatial function. - `spatial_key` BIGINT — Hilbert curve index of the bounding box’s centre, computed over the fixed Romanian extent 20.2–30.1 °E by 43.5–48.3 °N. A space-filling curve numbers a two-dimensional area so that neighbouring numbers are neighbouring places. ADVISORY on this FEDERATED table: it is computed by the published view at query time, not by a physical sort this platform ever performed, so filtering or sorting on it buys no pruning of its own — use it as an ORDER BY or window key in your own query, not as a reason a filter on it will be fast. Deterministic and comparable between releases because the extent is a constant, never recomputed from the data. Not a geographic coordinate, and means nothing outside this dataset. - `bbox_min_longitude` DOUBLE [degrees] — West edge of the feature’s axis-aligned bounding box, in WGS 84 degrees, copied from Overture’s own `bbox` struct. For a point feature all four edges equal its coordinates. Filtering the four bbox columns is the cheap way to ask a map-window question, and the table’s spatial sort order is what makes it prune. - `bbox_max_longitude` DOUBLE [degrees] — East edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_min_latitude` DOUBLE [degrees] — South edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_max_latitude` DOUBLE [degrees] — North edge of the feature’s bounding box, in WGS 84 degrees. - `version` INTEGER — Overture’s own revision counter for this feature, incremented whenever the feature changes between releases. Comparing it across two releases is the cheap way to find what moved. - `sources` JSON — Overture’s `sources` list, whole: one entry per upstream contribution, with `property` (the field it supplied, empty string meaning the whole feature), `dataset` (OpenStreetMap, Esri Community Maps, Microsoft ML Buildings, …), `license` (the SPDX id THAT contribution carries — the buildings theme genuinely mixes ODbL-1.0 and CC-BY-4.0 row by row), `record_id` (the id in the upstream dataset) and `update_time`. Kept in full because it is what a reuser needs to attribute the row correctly. - `primary_source_dataset` VARCHAR — The `dataset` of the first entry in `sources`, lifted out as a scalar so "which rows come from OpenStreetMap" is a plain equality filter rather than a JSON scan. For Romanian divisions this is OpenStreetMap for 32,115 contributions and Esri Community Maps for 377. - `primary_source_license` VARCHAR — The SPDX licence id of the first entry in `sources` — the licence that actually governs this row, which is not always the theme’s headline licence. Check it before republishing a subset. - `primary_source_record_id` VARCHAR — The identifier this feature carries in its upstream dataset, e.g. "n461880920@6" for an OpenStreetMap node at version 6. It is how a row is traced back to the source that produced it, and how a correction is reported upstream rather than here. - `source_updated_at` TIMESTAMPTZ — When the upstream record behind the first `sources` entry last changed, as the source stated it. Overture requires `update_time` to carry an explicit offset (`Z` or `+HH:MM`); TRY_CAST parses whichever one the source used and this column stores the resulting absolute instant, which DuckDB always reads back out in UTC. NULL when the source published no timestamp or published one this connector could not parse — the raw string is still in `sources`. This is the age of the FACT; `snapshot_date` is the age of our copy of it. - `snapshot_date` DATE NOT NULL — The UTC calendar day the run that PUBLISHED THIS VIEW happened — not the age of the data. This table is FEDERATED, so, like `release`, this is one constant for every row: the rows themselves are read from Overture live, at the moment a reader queries them, not copied on this day. An Overture release is cut once a month and the facts inside it are older still — use `source_updated_at` for that. - `ingested_at` TIMESTAMP NOT NULL — The UTC instant at which the run that PUBLISHED THIS VIEW started. One constant for every row, for the same reason as `snapshot_date`: nothing here was ever copied at this instant, only the view definition was. ### places One row per point of interest inside Romania — 327,091 in release 2026-08-19.0: shops, restaurants, pharmacies, schools, clinics, offices, hotels, fuel stations, landmarks. Overture conflates them from commercial and open contributors and publishes a `confidence` score per place, so this table is best read as "what several providers believe is here", not as a register. Selected geometrically: bounding-box prefilter, then a point-in-polygon test against Romania’s own Overture outline. - 0 rows · 0 B · write mode `snapshot_history` - Physically sorted by: `release`, `spatial_key`, `place_id` - Primary key: `release`, `place_id` - Text search columns: `name` - Files: 0 Columns: - `place_id` VARCHAR NOT NULL — Overture GERS id of the place — a UUID stable across releases for the same real-world POI, which is what makes "what opened and closed between two releases" a join rather than a fuzzy match. - `release` VARCHAR NOT NULL — The Overture release this row was read from, e.g. "2026-08-19.0" — a release date plus a within-day revision number. This table is FEDERATED (materialize: "view" in index.ts), so the value is a CONSTANT: every row carries the one release the published view currently points at, not a history of releases this platform has ever read. Re-running this connector at a different release REPLACES that constant for every row rather than adding a second release alongside it — there is no way to see two releases through this column at once. Overture cuts a release roughly monthly and keeps only the two most recent in the bucket; this column names whichever one the view was last built against. - `name` VARCHAR — The place’s primary name as its providers give it, e.g. "Farmacia Tei". - `name_lc` VARCHAR — The primary name, lower-cased and stripped of diacritics, so a search for "farmacia tei" finds "Farmacia Tei" and a search for "bacau" finds "Bacău". Search this column, display `name`. - `names_common` JSON — The place’s name in other languages, as a JSON object keyed by language code. NULL for the great majority of Romanian places, which carry only one name. - `category` VARCHAR — Overture’s primary category for the place, a dotted path from its own category taxonomy such as "pharmacy", "restaurant", "beauty_salon". This is the field almost every analysis of this table groups by. - `categories_alternate` JSON — Further categories the providers also assigned, as a JSON array. A pharmacy inside a supermarket carries both. - `basic_category` VARCHAR — A coarse bucket above `category` — the level to group by when the full taxonomy is too fine to chart. - `taxonomy_category` VARCHAR — The primary category expressed in Overture’s newer, versioned taxonomy, which is gradually replacing the flat `category` string. Kept alongside rather than instead of it, so a query written against either keeps working. - `taxonomy_hierarchy` JSON — The full ancestry of `taxonomy_category`, root first, as a JSON array — the path that lets you roll pharmacies up into health without hard-coding the tree. - `confidence` DOUBLE — How sure Overture is that this place exists and is described correctly, from 0 to 1. It is a conflation score, not a data-quality guarantee: a low value usually means only one provider reported the place. Filter on it before counting anything — the answer to "how many restaurants are there in Bucharest" changes a great deal with the threshold, and stating the threshold is part of stating the answer. - `operating_status` VARCHAR — Whether the providers believe the place is still trading. NULL where none of them said. - `brand_name` VARCHAR — The brand or chain the place belongs to, where it belongs to one — "Lidl", "Kaufland", "Farmacia Tei". This is what makes "every Profi in Moldova" a single equality filter. - `brand_wikidata` VARCHAR — Wikidata entity id of the brand, where Overture knows one. - `address_freeform` VARCHAR — The street address as the provider wrote it, in one unparsed string — "Str. Memorandumului 28". Overture does not normalise it, so it is exactly as messy as its source. - `address_locality` VARCHAR — Town or city named in the address. - `address_postcode` VARCHAR — Postal code as the provider gave it. - `address_region` VARCHAR — Region named in the address, usually the ISO 3166-2 județ code. It is the provider’s claim about the address, not a spatial fact — join to `divisions` through a spatial lookup if you need the authoritative județ. - `address_country` VARCHAR — Country named in the address. Almost always "RO" here, but it is the address’s claim, not the selection criterion: this table is selected by geometry, and the two disagreed on 15 of the 327,091 rows in release 2026-08-19.0. - `websites` JSON — The place’s websites, as a JSON array of URLs. - `phones` JSON — The place’s public telephone numbers, as a JSON array of strings. - `socials` JSON — The place’s social-media profile URLs, as a JSON array. - `longitude` DOUBLE [degrees] — Longitude of the place (WGS 84). Places are always points. - `latitude` DOUBLE [degrees] — Latitude of the place (WGS 84). - `spatial_key` BIGINT — Hilbert curve index of the bounding box’s centre, computed over the fixed Romanian extent 20.2–30.1 °E by 43.5–48.3 °N. A space-filling curve numbers a two-dimensional area so that neighbouring numbers are neighbouring places. ADVISORY on this FEDERATED table: it is computed by the published view at query time, not by a physical sort this platform ever performed, so filtering or sorting on it buys no pruning of its own — use it as an ORDER BY or window key in your own query, not as a reason a filter on it will be fast. Deterministic and comparable between releases because the extent is a constant, never recomputed from the data. Not a geographic coordinate, and means nothing outside this dataset. - `bbox_min_longitude` DOUBLE [degrees] — West edge of the feature’s axis-aligned bounding box, in WGS 84 degrees, copied from Overture’s own `bbox` struct. For a point feature all four edges equal its coordinates. Filtering the four bbox columns is the cheap way to ask a map-window question, and the table’s spatial sort order is what makes it prune. - `bbox_max_longitude` DOUBLE [degrees] — East edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_min_latitude` DOUBLE [degrees] — South edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_max_latitude` DOUBLE [degrees] — North edge of the feature’s bounding box, in WGS 84 degrees. - `version` INTEGER — Overture’s own revision counter for this feature, incremented whenever the feature changes between releases. Comparing it across two releases is the cheap way to find what moved. - `sources` JSON — Overture’s `sources` list, whole: one entry per upstream contribution, with `property` (the field it supplied, empty string meaning the whole feature), `dataset` (OpenStreetMap, Esri Community Maps, Microsoft ML Buildings, …), `license` (the SPDX id THAT contribution carries — the buildings theme genuinely mixes ODbL-1.0 and CC-BY-4.0 row by row), `record_id` (the id in the upstream dataset) and `update_time`. Kept in full because it is what a reuser needs to attribute the row correctly. - `primary_source_dataset` VARCHAR — The `dataset` of the first entry in `sources`, lifted out as a scalar so "which rows come from OpenStreetMap" is a plain equality filter rather than a JSON scan. For Romanian divisions this is OpenStreetMap for 32,115 contributions and Esri Community Maps for 377. - `primary_source_license` VARCHAR — The SPDX licence id of the first entry in `sources` — the licence that actually governs this row, which is not always the theme’s headline licence. Check it before republishing a subset. - `primary_source_record_id` VARCHAR — The identifier this feature carries in its upstream dataset, e.g. "n461880920@6" for an OpenStreetMap node at version 6. It is how a row is traced back to the source that produced it, and how a correction is reported upstream rather than here. - `source_updated_at` TIMESTAMPTZ — When the upstream record behind the first `sources` entry last changed, as the source stated it. Overture requires `update_time` to carry an explicit offset (`Z` or `+HH:MM`); TRY_CAST parses whichever one the source used and this column stores the resulting absolute instant, which DuckDB always reads back out in UTC. NULL when the source published no timestamp or published one this connector could not parse — the raw string is still in `sources`. This is the age of the FACT; `snapshot_date` is the age of our copy of it. - `snapshot_date` DATE NOT NULL — The UTC calendar day the run that PUBLISHED THIS VIEW happened — not the age of the data. This table is FEDERATED, so, like `release`, this is one constant for every row: the rows themselves are read from Overture live, at the moment a reader queries them, not copied on this day. An Overture release is cut once a month and the facts inside it are older still — use `source_updated_at` for that. - `ingested_at` TIMESTAMP NOT NULL — The UTC instant at which the run that PUBLISHED THIS VIEW started. One constant for every row, for the same reason as `snapshot_date`: nothing here was ever copied at this instant, only the view definition was. ### buildings One row per building footprint in Romania — 12,474,972 in release 2026-08-19.0, which makes this by a wide margin the largest table here. The footprint itself is in `geometry_wkt`; height, storey counts and roof and facade attributes are present where some contributor supplied them, which for machine-detected footprints is rarely. Rows come from OpenStreetMap, Microsoft’s and Google’s machine-learned footprints, Esri Community Maps and national mapping agencies, conflated by Overture — and those contributions carry DIFFERENT licences, row by row, which is what `primary_source_license` is for. Selected by testing whether the centre of each footprint’s bounding box falls inside Romania. - 0 rows · 0 B · write mode `snapshot_history` - Physically sorted by: `release`, `spatial_key`, `building_id` - Primary key: `release`, `building_id` - Text search columns: `name` - Files: 0 Columns: - `building_id` VARCHAR NOT NULL — Overture GERS id of the building — stable across releases for the same footprint, so comparing two releases finds what was built, demolished or re-traced. - `release` VARCHAR NOT NULL — The Overture release this row was read from, e.g. "2026-08-19.0" — a release date plus a within-day revision number. This table is FEDERATED (materialize: "view" in index.ts), so the value is a CONSTANT: every row carries the one release the published view currently points at, not a history of releases this platform has ever read. Re-running this connector at a different release REPLACES that constant for every row rather than adding a second release alongside it — there is no way to see two releases through this column at once. Overture cuts a release roughly monthly and keeps only the two most recent in the bucket; this column names whichever one the view was last built against. - `name` VARCHAR — The building’s name where it has one — "Casa Poporului", "Cluj Arena". The overwhelming majority of Romanian footprints are unnamed. - `name_lc` VARCHAR — The name, lower-cased and stripped of diacritics, for accent-insensitive search. - `subtype` VARCHAR — What the building is for, in Overture’s vocabulary: residential, commercial, industrial, education, medical, religious, transportation, agricultural, civic, service, military, entertainment. NULL for the many footprints that were traced from imagery and never classified. - `class` VARCHAR — A finer type inside `subtype` — house, apartments, garage, church, school, barn and so on, carried over from the OpenStreetMap building tag where there was one. - `height` DOUBLE [m] — Height of the building from ground to its highest point, in metres, where a contributor supplied or estimated it. Do not read a NULL as "low": it means nobody measured. - `min_height` DOUBLE [m] — Height of the bottom of the building above ground, in metres — non-zero only for parts that float, such as a walkway over a street. - `roof_height` DOUBLE [m] — Height from ground to the top of the roof, in metres. Where both this and `height` are present the difference describes the roof itself. - `num_floors` INTEGER — Number of storeys above ground, where a contributor stated it. - `num_floors_underground` INTEGER — Number of storeys below ground, where stated. - `min_floor` INTEGER — The lowest storey this footprint occupies, for buildings modelled floor by floor. - `level` INTEGER — The z-order level of the footprint, used to draw overlapping structures in the right order — a bridge over a building. - `is_underground` BOOLEAN — True when the whole structure is below ground. - `has_parts` BOOLEAN — True when Overture also publishes building_part rows refining this footprint into differently shaped or differently tall sections. Those parts are NOT in this dataset — see the dataset description for why. - `facade_material` VARCHAR — What the walls are made of, where recorded — brick, concrete, wood, glass, plaster. - `facade_color` VARCHAR — Colour of the walls, where recorded. - `roof_material` VARCHAR — What the roof is made of, where recorded — roof_tiles, metal, concrete, thatch. - `roof_shape` VARCHAR — The roof’s shape, where recorded — flat, gabled, hipped, pyramidal, dome. - `roof_color` VARCHAR — Colour of the roof, where recorded. - `roof_direction` DOUBLE [degrees] — Compass bearing of the roof ridge, in degrees clockwise from north. - `roof_orientation` VARCHAR — "along" or "across": whether the ridge runs along the building’s long axis or across it. The pair of this and roof_direction is what a 3-D renderer needs. - `geometry_wkt` TEXT — The footprint as WKT in WGS 84 (EPSG:4326), normally a POLYGON. This is the outline itself, not a reference to it: ST_GeomFromText(geometry_wkt) gives a real geometry to intersect, measure or render. Romanian footprints average about 167 characters, which is what makes 12.5 million of them affordable to publish. - `geometry_type` VARCHAR — POLYGON or MULTIPOLYGON, as ST_GeometryType reports it. - `geometry_point_count` INTEGER — How many vertices the footprint has. Four or five for a machine-detected rectangle, dozens for a hand-traced historic building — which makes this a serviceable proxy for how carefully a footprint was drawn. - `footprint_sq_m` DOUBLE [m²] — Ground area covered by the footprint, in square metres, computed on the WGS 84 spheroid (ST_Area_Spheroid). Derived here rather than published by Overture. It is the footprint, not the floor area: multiply by num_floors for a crude built-area estimate, and only where num_floors is not NULL. - `centroid_longitude` DOUBLE [degrees] — Longitude of the footprint’s centroid (WGS 84) — the point to use when a building has to be drawn as a dot or joined to a point dataset. - `centroid_latitude` DOUBLE [degrees] — Latitude of the footprint’s centroid (WGS 84). - `spatial_key` BIGINT — Hilbert curve index of the bounding box’s centre, computed over the fixed Romanian extent 20.2–30.1 °E by 43.5–48.3 °N. A space-filling curve numbers a two-dimensional area so that neighbouring numbers are neighbouring places. ADVISORY on this FEDERATED table: it is computed by the published view at query time, not by a physical sort this platform ever performed, so filtering or sorting on it buys no pruning of its own — use it as an ORDER BY or window key in your own query, not as a reason a filter on it will be fast. Deterministic and comparable between releases because the extent is a constant, never recomputed from the data. Not a geographic coordinate, and means nothing outside this dataset. - `bbox_min_longitude` DOUBLE [degrees] — West edge of the feature’s axis-aligned bounding box, in WGS 84 degrees, copied from Overture’s own `bbox` struct. For a point feature all four edges equal its coordinates. Filtering the four bbox columns is the cheap way to ask a map-window question, and the table’s spatial sort order is what makes it prune. - `bbox_max_longitude` DOUBLE [degrees] — East edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_min_latitude` DOUBLE [degrees] — South edge of the feature’s bounding box, in WGS 84 degrees. - `bbox_max_latitude` DOUBLE [degrees] — North edge of the feature’s bounding box, in WGS 84 degrees. - `version` INTEGER — Overture’s own revision counter for this feature, incremented whenever the feature changes between releases. Comparing it across two releases is the cheap way to find what moved. - `sources` JSON — Overture’s `sources` list, whole: one entry per upstream contribution, with `property` (the field it supplied, empty string meaning the whole feature), `dataset` (OpenStreetMap, Esri Community Maps, Microsoft ML Buildings, …), `license` (the SPDX id THAT contribution carries — the buildings theme genuinely mixes ODbL-1.0 and CC-BY-4.0 row by row), `record_id` (the id in the upstream dataset) and `update_time`. Kept in full because it is what a reuser needs to attribute the row correctly. - `primary_source_dataset` VARCHAR — The `dataset` of the first entry in `sources`, lifted out as a scalar so "which rows come from OpenStreetMap" is a plain equality filter rather than a JSON scan. For Romanian divisions this is OpenStreetMap for 32,115 contributions and Esri Community Maps for 377. - `primary_source_license` VARCHAR — The SPDX licence id of the first entry in `sources` — the licence that actually governs this row, which is not always the theme’s headline licence. Check it before republishing a subset. - `primary_source_record_id` VARCHAR — The identifier this feature carries in its upstream dataset, e.g. "n461880920@6" for an OpenStreetMap node at version 6. It is how a row is traced back to the source that produced it, and how a correction is reported upstream rather than here. - `source_updated_at` TIMESTAMPTZ — When the upstream record behind the first `sources` entry last changed, as the source stated it. Overture requires `update_time` to carry an explicit offset (`Z` or `+HH:MM`); TRY_CAST parses whichever one the source used and this column stores the resulting absolute instant, which DuckDB always reads back out in UTC. NULL when the source published no timestamp or published one this connector could not parse — the raw string is still in `sources`. This is the age of the FACT; `snapshot_date` is the age of our copy of it. - `snapshot_date` DATE NOT NULL — The UTC calendar day the run that PUBLISHED THIS VIEW happened — not the age of the data. This table is FEDERATED, so, like `release`, this is one constant for every row: the rows themselves are read from Overture live, at the moment a reader queries them, not copied on this day. An Overture release is cut once a month and the facts inside it are older still — use `source_updated_at` for that. - `ingested_at` TIMESTAMP NOT NULL — The UTC instant at which the run that PUBLISHED THIS VIEW started. One constant for every row, for the same reason as `snapshot_date`: nothing here was ever copied at this instant, only the view definition was. ## Performance notes - There are no indexes in a lakehouse. The physical sort order plus Parquet row-group min/max statistics ARE the index. Predicates on the leading sort columns prune whole row groups; everything else is a full column scan. - `divisions` prunes on `release` → `subtype` → `region` → `name_lc` → `division_id`. - `division_areas` prunes on `release` → `subtype` → `region` → `name_lc` → `area_id`. - `division_boundaries` prunes on `release` → `subtype` → `region` → `spatial_key` → `boundary_id`. - `places` prunes on `release` → `spatial_key` → `place_id`. - `buildings` prunes on `release` → `spatial_key` → `building_id`. - `ILIKE '%needle%'` cannot prune: it decompresses that whole column. Prefer prefix predicates on the lowercased search companion columns where they exist. - Every file URL under `/v//` is immutable. Cache it as aggressively as you like. - Files are never rewritten in place — a new ingest writes a new version path. Re-read the manifest to pick up updates rather than polling the file URLs. - Pull only the columns you need. Parquet is columnar and the reader range-GETs what it reads. ## Do not - Do not scrape https://data.bunnytech.app HTML. Every number on those pages comes from the manifest above. - Do not hit the upstream source (https://docs.overturemaps.org/getting-data/) in bulk. This mirror exists so you do not have to. - Do not read DuckLake internal data files with a plain Parquet reader. They come with positional delete files, and ignoring those silently returns deleted rows. Use the ducklake extension, or use the published exports above. - Do not republish without the attribution line, and do not imply endorsement.