Starting Point

Buildings in a 3D map can appear to be finished visual objects. Underneath, they are geographic features: polygons with attributes such as height and minimum height that determine what is drawn.

I was interested in whether an OpenStreetMap-based 3D city could also become its own editing environment. Instead of exporting a building into conventional 3D software, the map itself could provide the spatial context for changing it.

What I Wanted to Try

What would a 3D editor look like if it began as an extension of a map rather than as an empty modeling space?

I wanted to select OSM-derived buildings, change the geometry or attributes that controlled their 3D form, and see the result immediately in the actual city. Keeping streets, neighboring buildings, and geographic position visible seemed potentially more intuitive for this task than editing an isolated object in conventional 3D software.

What I Built

I built a small browser-based editor using MapLibre GL JS, TypeScript, Turf, and a JSON editor. It reads OSM-derived building features from an OpenMapTiles source and renders them as fill extrusions.

Clicking a building copies the selected feature into a separate highlighted layer and opens its ID, properties, and polygon coordinates in the editor. Changes to properties such as render_height and render_min_height are written back to the selected GeoJSON source and reflected in the 3D view.

The prototype also contains early drawing interactions for points and polygons. These were experiments toward creating and changing map features directly in the same geographic environment.

What I Found Interesting

The immediate feedback was more important than the JSON editor itself. A change to building data became visible in the city without leaving the map, so the object could be judged in relation to streets, neighboring structures, scale, and location. The map was no longer only a display of geographic data; it was beginning to act as a spatial editing surface.

This suggested that the problem may not be how to add 3D editing controls to a map, but how to preserve geographic meaning while a 3D form is being changed. Conventional modeling software is powerful because it abstracts an object away from its surroundings. An OSM-oriented editor may need the opposite: constraints, provenance, neighboring context, and a clear account of how an edit will become shared geographic data.

The raw JSON interface was only a quick way to test that relationship. A more appropriate interface would translate between direct manipulation of a visible building and valid OSM-compatible geometry and attributes, while showing the consequences of the edit in place.

What It Does Not Do Yet

This is an unfinished personal prototype rather than a reliable OpenStreetMap editor. Changes remain in the browser and are not validated or written back to OSM or another external data source.

The early renderer only allowed a limited set of building properties. The floating Kyoto Tower shown in the example came from working within those constraints and was used to make the effect of a property change obvious. It should be read as a test case, not as the intended behavior of the editor.

The map can also select overlapping rendered features, and the experimental drawing tools do not yet provide a complete editing workflow. There is no history, conflict handling, provenance, or explanation of how a local edit might affect other maps and users.

What I Would Try Next

• Replace raw JSON editing with direct controls for height, footprint, and position
• Show the original and edited representations together
• Validate changes against common building-tag conventions
• Explain which source attributes control each visible part of a building
• Explore how an edit could be reviewed before becoming shared map data

View source on GitHub