Digital Terrain Model of Belo Horizonte, Brazil — 1 m Cloud-Optimized GeoTIFF (interpolated from municipal DTM point tiles)

# Digital Terrain Model of Belo Horizonte, Brazil — 1 m Cloud-Optimized GeoTIFF Seamless 1 m digital terrain model (DTM) of the municipality of Belo Horizonte, Minas Gerais, Brazil, produced by merging and interpolating 346 tiles of scattered elevation points (`MDT_*.xyz`) into a single Cloud-Optimized GeoTIFF. ## Files | File | Description | SHA-256 | |---|---|---| | `MDT_BH_1m_cog.tif` | 1 m DTM, Cloud-Optimized GeoTIFF (747 MB) | `d6418c68ee8d9230606c9ecad73fecea785a4d30fe4655c12282217f4a8053db` | ## Source data - **Provider:** Prefeitura de Belo Horizonte (PBH) / Prodabel — BHGeo cartographic archive (acervo cartográfico): <https://prefeitura.pbh.gov.br/bhgeo/acervo-cartografico> - **Survey method:** airborne laser scanning (LiDAR, "mapeamento a laser") carried out by PBH; the MDT point cloud is the bare-earth (terrain) product. - **Acquisition year:** <!-- TODO: 2007 or 2015 — BHGeo distributes both vintages ("Nuvem de Pontos 2007" / "Nuvem de Pontos 2015"); state which one was used. --> - **Distribution:** point-cloud files organised by the municipal grid articulation (346 quadricules), downloaded from the BHGeo archive. - **License of source data:** <!-- TODO: BHGeo does not state explicit terms on the archive page; confirm terms of use with PBH/Prodabel before choosing the Zenodo license. --> - 346 tiles named `MDT_CCRR.xyz` (plain text, whitespace-separated `x y z`, one point per line), totalling 126,396,793 scattered elevation points (~5.3 GB of text). - Coordinates: SIRGAS 2000 / UTM zone 23S (EPSG:31983), metres; elevations in metres (orthometric). - Tiling scheme (verified against the data): tile `CCRR` covers a 1200 m × 1000 m rectangle with `x ∈ [(CC+456)·1200, (CC+457)·1200]` and `y ∈ [7 746 000 + RR·1000, 7 746 000 + (RR+1)·1000]`, spanning columns 42–60 and rows 35–67. - Point density varies between roughly 0.06 and 0.43 points/m² (mean spacing ≈ 1.5–4 m). - Quality notes: some files use CRLF line endings and trailing whitespace; three tiles (`MDT_4853`, `MDT_5353`, `MDT_5552`) each contain a single point slightly (>1 m) outside their nominal tile rectangle. All points were kept. ## Processing methodology Processing was fully scripted (Python + GDAL); no manual editing was performed. 1. **Parsing and validation.** Each `.xyz` file was parsed with a whitespace-tolerant reader (pandas `read_csv`, `sep=r"\s+"`). Non-finite rows would have been dropped (none were found). Every file's point cloud was checked against its filename-derived tile rectangle (±1 m tolerance) and for plausible elevation ranges. 2. **Interpolation — per-tile TIN.** For each tile, a Delaunay triangulation (TIN) was built from the tile's own points plus all points within a 30 m buffer taken from the 8 neighbouring tiles, ensuring seamless interpolation across tile boundaries. Elevations were linearly interpolated within triangles (`scipy.interpolate.LinearNDInterpolator`) onto a 1 m grid aligned to integer metre coordinates (cell centres at half-metre coordinates). Cells outside the convex hull of the available points were set to nodata — no extrapolation was performed, so the raster footprint follows the actual point coverage (≈46.5 % of the bounding rectangle, matching the municipal boundary). 3. **Mosaicking.** The 346 interpolated tiles were combined into a virtual mosaic (`gdalbuildvrt`); tiles are edge-aligned on the common 1 m grid and do not overlap. 4. **COG generation.** The mosaic was written with GDAL's COG driver: ``` gdal_translate -of COG \ -co COMPRESS=DEFLATE -co PREDICTOR=YES \ -co NUM_THREADS=ALL_CPUS -co BIGTIFF=IF_SAFER \ -co OVERVIEW_RESAMPLING=AVERAGE \ mosaic.vrt MDT_BH_1m_cog.tif ``` The output passes GDAL's official COG validator (`validate_cloud_optimized_geotiff.py`). ### Software Python 3.13.9, GDAL 3.12.0, rasterio 1.4.3, scipy 1.16.3, numpy 2.3.5, pandas 2.3.3, on macOS (Darwin 25.5). ## Raster metadata | Property | Value | |---|---| | CRS | EPSG:31983 — SIRGAS 2000 / UTM zone 23S | | Extent (E) | 597 600 – 620 400 m | | Extent (N) | 7 781 000 – 7 814 000 m | | Size | 22 800 × 33 000 pixels | | Resolution | 1 m × 1 m | | Data type | Float32, single band (elevation, m) | | NoData | −9999 | | Compression | DEFLATE, floating-point predictor | | Layout | COG: 512 × 512 internal tiles, 7 overview levels (average resampling) | | Elevation range | 673.8 – 1504.3 m (mean 895.2 m, σ 133.3 m) | | Valid-data coverage | ≈46.5 % of the bounding rectangle | ## Known limitations - Accuracy is bounded by the source points: in low-density areas (~0.06 pts/m²) the 1 m grid is dominated by linear interpolation over triangles with edges of several metres; the 1 m resolution there is oversampled relative to the information content. - Linear TIN interpolation produces planar facets; slope/aspect derivatives will show faceting artefacts in sparse areas. - This is a terrain model (bare earth), not a surface model — buildings and vegetation are excluded to the extent they were excluded from the source points. - No independent vertical-accuracy assessment was performed as part of this processing; refer to the source survey's accuracy specification.