OpenStreetMap's New Vector Tiles

Original Article ↗ Hacker News Discussion ↗

OpenStreetMap’s move toward vector tiles is seen as a major step for sharper, more customizable maps, better internationalization, and potentially lower hosting costs, though the official service is still in technical preview. Commenters highlight both the new possibilities—such as client-side styling, language switching, and easier self‑hosting—and current gaps, including bugs with scripts like Arabic, limited style detail compared to the long‑standing raster tiles, and performance concerns on low‑end devices. There is broad interest in tools for rendering, printing, and converting vector tiles, but also recognition that vector maps shift complexity from centralized servers to a more fragmented toolchain on clients.

Format and Rendering

  • Several commenters initially conflate the new tiles with SVG; others clarify they are Mapbox Vector Tiles (MVT) over protobuf, typically rendered via WebGL.
  • The demo exposes a major bug in Arabic and other RTL script rendering (wrong direction, unconnected glyphs, likely font/shaping issues).
  • Thread consensus: the underlying tile data is fine (Unicode strings); problems are in the client-side rendering stack and style configuration.

Tooling and Use Cases

  • Developers complain there’s still no simple, cross‑platform “vector tile → PNG/SVG” library for server‑side or native rendering.
  • QGIS is repeatedly cited as having strong MVT support (including printing), but it’s a heavy dependency and may not match MapLibre/Mapbox styling exactly.
  • Vector tiles are seen as a poor fit for offline navigation/search apps like OSM-focused mobile clients, which use their own optimized data formats.

Internationalization and Labels

  • Vector tiles enable dynamic language switching, but:
    • OSM mostly stores local names plus exonyms, not full translations.
    • The current “shortbread” schema only includes limited multilingual data.
  • Label layout depends on text size/shape; switching languages can cause overlaps or disappearances, and commenters expect imperfect behavior.

Hosting, Cost, and Performance

  • Vector tiles are praised as easier and cheaper to self‑host: essentially static files, good HTTP caching, gzip pre-done.
  • For openstreetmap.org itself, tiles must be minutely updated for mapper feedback, so they’re generated on the fly and then cached.
  • Sponsorship (e.g., CDN and cloud compute) heavily subsidizes the current raster service; vector tiles reduce compute but do not remove infrastructure needs.
  • On low‑end devices, vector tiles impose more local CPU/GPU/memory load than simple 256×256 rasters; a full switch away from rasters is seen as distant.

Map Detail and Style Quality

  • Multiple commenters find current vector styles significantly less detailed and informative than classic OSM raster tiles (fewer POIs, weaker symbology, less visual richness).
  • They attribute this partly to schema limits and partly to current style design; some hope open styles and editors (e.g., Maputnik) will eventually close the gap.

Availability and Maturity

  • The new stack is labelled a technical preview/soft launch, with a public demo URL.
  • Bugs (like Arabic rendering and style/detail issues) are being reported and tracked; focus so far has been on the real‑time vector tile pipeline rather than polished cartography.