Two tools that both output 3D geometry can still belong to different stages of the pipeline. halfmaps is an extractor: it converts OpenStreetMap features and Mapzen terrain into a styled city mesh and exports it to the modeling tool of your choice. GenAnywhere is an authoring environment: it constructs and revises the designed intervention. One is upstream of design; the other is design.
This is the engineering view of where each belongs, and where the handoff tends to break.
TL;DR
| Concern | halfmaps | GenAnywhere |
|---|---|---|
| Input | OSM features + Mapzen terrain | Authored design content |
| Output | Styled city mesh | Shaped place / proposal |
| Formats | GLB, glTF, OBJ, STL, 3MF, DXF | Working environment, iterative |
| Revision model | Restyle and re-export | Edit in place, preserve approved state |
| Best stage | Site context | Design development |
| Pricing | $15 per area (unlimited re-exports); $49/mo Creator | Per designer, value scales with iteration |
Rule zero: context is extracted, design is authored. Do not blur the two, and do not let either tool pretend to be the other.
halfmaps: The Extraction Layer
halfmaps runs in the browser (the app is called Vectiler) and builds geometry from open data. Buildings are extruded from footprints, with heights derived from available attributes. Roads, water, and terrain are generated as separate surfaces. Style controls govern how each category is represented, and a live 3D preview shows the result before export.
The export list is the integration surface:
- GLB / glTF — real-time engines, web viewers, Blender, most DCC tools.
- OBJ — universal mesh interchange, easy to clean up.
- STL / 3MF — fabrication and 3D printing.
- DXF — CAD-side workflows, Rhino and similar.
Pricing is per area rather than per seat: $15 buys one area with unlimited re-exports, and $49 per month covers the Creator plan. There is no free tier beyond the example maps, which is worth budgeting for before a workshop.
What the extraction layer is good at
- Deterministic context. The same area and settings produce the same base mesh, which makes option comparisons defensible.
- District-scale coverage. You get neighbors, not just the parcel — essential for shadow, view, and street-wall studies.
- Neutral representation. The mesh describes existing conditions without proposing anything, so it does not bias a review.
- Fast iteration on extent. Re-export a larger or smaller area without remodeling.
Its hard limits
OSM is a description, not a survey. Height accuracy varies, footprints may be simplified, and complex roofs or façade articulation are out of scope. There is no authored material system, no interior, no designed public realm. And critically, there is no revision semantics for a proposal: you cannot lock approved geometry and change one element. Restyling is not designing.
GenAnywhere: The Authoring Layer
GenAnywhere begins where extraction ends. The design is constructed rather than derived, and the workflow is built around change: reshape massing, adjust the street relationship, test character options, and keep every approved element fixed while the contested ones move.
This is a different data model, not a different renderer. The unit of work is an edit against an authored state, which is why a review can conclude inside the meeting instead of scheduling a follow-up. In pipeline terms, GenAnywhere supplies the non-parametric layer that map data cannot: intent.
The Handoff
The seam between an extracted context and an authored design is where most time is lost. Four checks prevent it:
- Units and scale. Confirm the exporter's units against your scene before the first overlay. A single mismatch poisons every downstream measurement.
- Origin and orientation. Map exports arrive in a projected coordinate frame. Record the transform you applied so the design can be re-registered against a newer export.
- Extent discipline. Export the study area plus a believable margin, not the whole municipality. Mesh size is a tax on every later operation.
- Representation parity. Style the context at the same level of abstraction as the design. A richly styled base against a schematic proposal (or the reverse) biases judgment toward finish, not quality.
Treat the exported context as a versioned dependency. When the map data updates, you want to know which design decisions were tested against which base.
Revision Semantics Compared
- Map change (extent, style, updated OSM data) → re-export from halfmaps, re-register, re-run the checks.
- Design change (massing, enclosure, character) → edit in GenAnywhere; approved state persists.
- Decision record → store the design state and the context version together. Models age; the reasons behind them are the actual deliverable.
The failure pattern is predictable: a team tries to encode design changes as map restyles, or tries to author context in the design tool. Both produce rework that looks like a modeling problem but is really a pipeline-boundary problem.
Where Each Layer Is Simply Correct
- halfmaps: existing-conditions models, feasibility context, shadow and view studies, competition bases, printable site models, quick environment for render tests.
- GenAnywhere: proposal development, street-wall and public-realm studies, iterative review, any deliverable where the design itself is the product.
Verdict
Use halfmaps to build the world honestly and cheaply. Use GenAnywhere to design what goes into it, and to keep designing after the first review. The pipeline that works treats context as an extracted, versioned input and design as an authored, revisable output. Keeping those two contracts separate is the difference between a model that informs decisions and a model that merely illustrates them.
Top comments (0)