map3d: a React Three Fiber city model built on OpenStreetMap data

What the app does, in the author's own three checked boxes

The README is short, and its roadmap is the most informative part of it. Three items are checked: create 3D buildings, create roads, export GLB. Four are not: building texture, height customization, material, heightmap. That is an unusually honest split between what runs and what is intended.

The About section states the project is a 3D building mapping service implemented with React Three Fiber, that it allows exporting as a GLB file, and that all features are free to use. It then names the intended extensions: digital twin, drone surveying and GPS markers. The phrase that matters is 'based on this project', which puts those three squarely in the category of things someone would build on top rather than features that exist here.

The repository description line says the same thing more tersely: generate a city 3D map with R3F, including building and road information. Building and road are the two data layers, and they are the two the checked boxes confirm.

One contributor is credited, Hyeong Jun Huh, with a link to a GitHub profile under the DipokalLab handle, which is worth noting because a single-contributor project has a very different bus factor from a foundation project with the same star count.

The README's own warning about OpenStreetMap heights

There is a callout block in the README marked IMPORTANT, and it is the single most consequential sentence in the project: this project cannot guarantee the accuracy of the data. The stated cause is that it uses OpenStreetMap data, where some height values may be missing or incorrectly recorded. The stated remedy is not shipped yet: an option will be added in the future to allow users to manually correct the data.

That combination, a known data problem plus an unbuilt fix, tells you how to use this project. The geometry is trustworthy enough to look at and to prototype against. The vertical dimension is not, unless you verify it yourself. Building footprints and road networks from OpenStreetMap are good; `height=3` tags on a residential shed are not.

For the applications the README lists, the distinction matters differently. A drone surveying workflow needs accurate heights to plan a flight. A digital twin demo needs them to look credible. A GPS marker visualisation can live without them. If your use case is in the first two groups, the missing height-correction option is the thing to wait for.

This is also where a reader should place the licensing question. The project is MIT licensed, but MIT covers this code, not the OpenStreetMap data, which carries its own attribution requirements and its own quality record.

The dependency list tells you it is a 2D map that grew a 3D layer

`package.json` is the most informative file in the repository, and it is a single page of JSON with no build tooling surprises. The scripts are the standard Vite four: `dev`, `build`, `lint` and `preview`.

npm install
npm run dev
npm run build
npm run lint
npm run preview

Those five commands cover the whole Vite script set, with build running the TypeScript project build before the bundle step. The dependency list is where the shape of the application shows. On the 3D side there is `three` at 0.173, `@react-three/fiber` at 9.0, `@react-three/drei` at 10.0 and `@types/three`. On the 2D map side there is `leaflet` at 1.9.4 and `react-leaflet` at 5.0, with matching types.

That pairing is the interesting design decision. A city mapping tool needs a map interface, and Leaflet is the cheapest credible one. So the app is almost certainly a Leaflet basemap with a 3D layer anchored to geographic coordinates, which is a common and practical pattern for this kind of viewer. It also means you get Leaflet's projection and tile handling for free rather than reimplementing them.

The rest is ordinary modern React infrastructure: `react` and `react-dom` at 19.0, `zustand` at 5.0 for state, `axios` for data fetching, `@emotion/react` and `lucide-react` for styling and icons, and one dependency that stands out. `deventds2` at 0.1.10 is a digitised vector tile library, which is a plausible source for map geometry beyond what plain OSM data gives you. Nothing in the README mentions it, so treat that as an inference from the dependency list rather than a documented choice.

A library-flavoured TypeScript setup, with three tsconfig files

The tree carries the three-file TypeScript arrangement that current Vite templates ship with: `tsconfig.json` at the root, `tsconfig.app.json` for application code and `tsconfig.node.json` for the build tooling. There is `vite.config.ts`, `index.html`, `src/` and `public/`.

The build script deserves a second look because it is `tsc -b && vite build`, which runs the TypeScript project build before Vite bundles anything. That means type errors fail the build rather than surfacing in the browser, which is the correct arrangement for a codebase that leans on TypeScript as documentation.

The dev dependencies match that intent closely. `typescript` is pinned at about 5.7, `typescript-eslint` at 8.22 alongside `@eslint/js`, `globals`, `eslint-plugin-react-hooks` and `eslint-plugin-react-refresh`. `vite` is at 6.1 with `@vitejs/plugin-react` at 4.3, and `vite-plugin-dts` at 4.5 is present, so the project can emit TypeScript declarations for its modules.

There is no test framework in `package.json`, no test script and no test directory in the tree. For an application whose job is visual output, that is a defensible choice, but it does mean there is no automated check on the geometry pipeline. Verification here is manual, by looking at the render.

No releases, no changelog, one deployed demo

The releases list is empty. There is no tag, no version history and no CHANGELOG.md in the file tree, which is consistent with the version field in `package.json` still sitting at 0.0.0. Combined with `private: true` in the same file, the reading is that this repository is meant to be run from source rather than consumed as a package.

What is published instead is a deployed site, linked from the README as Visit Website at map.fleet.im, which the material also records as the homepage. There is also a demo link presented as a video attachment. So the distribution model is a live site plus a repository, not an artifact stream.

The project has 2435 stars, 392 forks, 5 open issues and is not archived. The repository was last pushed on 2026-05-13, roughly five months before this snapshot. That is recent enough to treat the project as alive, but with no releases it means there is no supported version to pin to and no upgrade path documented.

For a reader deciding whether to fork it, the practical test is the roadmap. If you need textures, materials or correctable heights, you are forking and extending. If you need buildings, roads and a GLB, you are probably fine.

What the GLB export changes about how you use this

GLB export is the checked feature that pushes this beyond a viewer, and it is the reason to care about the project even if you never deploy it. A viewer produces pixels. A GLB produces geometry you can open in Blender, import into a game engine, feed to a rendering pipeline or hand to a colleague.

That export target also shapes what the data quality caveat means downstream. A GLB carries the geometry and whatever materials were applied at export time, so an inaccurate height travels with the file. If you export and then correct in Blender, the correction is a modelling step you own, which is a reasonable workflow and not what the README's planned correction option would have been.

Worth noting is what the dependency list does not contain. There is no GLTF exporter package, no `three-stdlib`, no `@gltf-transform` tooling. The `GLTFExporter` ships inside `three` itself, so its absence from the dependency list is unremarkable, but it does mean the export path is hand-written in `src/` rather than delegated to a library.

The repository does not publish the source file that performs the export, so the details of how buildings are merged, how roads are represented and what units are assumed are things you would learn by reading `src/` or by asking the contributor. That is the main gap between what the README describes and what the repository demonstrates.

Editorial conclusion

map3d is worth looking at if you need a browser-based 3D city model derived from OpenStreetMap and want it as a GLB file for a downstream tool. The stack is current and legible, React 19, Three 0.173, react-leaflet for the 2D layer, zustand for state, Vite 6 with TypeScript 5.7, and the exported artifact is a file other tools can read. The limits are stated plainly in the README: height values from OpenStreetMap may be missing or wrong, manual correction is a future option, and textures, materials and heightmaps are all unchecked roadmap items. There are no releases and no changelog, the deployed site lives at map.fleet.im, and the repository was last pushed on 2026-05-13, so treat the default branch as the only version.

Frequently asked questions

Official sources

1. cartesiancs/map3d on GitHub
2. Issues
3. License: MIT
4. Project website
5. README