API Map Rendering

Geo Infrastructure

Open Street Map Tile Server and API

Raster Tiles and Vector Tiles

A map is not a picture. It is a machine.

The map on your website looks like a single, seamless surface.

Behind it sits a small production line that turns one of the largest open datasets in the world into something a browser can draw in a fraction of a second.

Understanding that line is worth a few minutes, because one decision inside it — raster tiles or vector tiles — shapes what your map can do, what it costs to run, and how it will look on the devices your customers actually use.

Design Map Depiction

Here you can see how the map is displayed with different styles. You can change the colors, fonts, and other visual elements to match your brand or design preferences. The map can be customized to show different types of information, such as roads, buildings, and points of interest.

Map styler will load when visible …

How does an OSM map server work?

The production line, step by step

The raw material: OpenStreetMap

OpenStreetMap is a global geodatabase built and maintained by a community of millions of contributors. Every road, building footprint, address point, river and forest is stored as geometry plus a set of attributes — highway=residential, building=yes, maxspeed=30. The full planet file is roughly {80 GB} of compressed raw data, and it changes continuously: a new roundabout in your town can appear in the global dataset within minutes of being mapped.

The import: from raw data to a spatial database

Raw OSM data is not something you can query at map speed. It is imported into a spatial database — typically PostgreSQL with the PostGIS extension — where geometries are reprojected, indexed and organised so that a query like "give me every road of class primary inside this rectangle" answers in milliseconds instead of minutes. This import is the heavy part of running a map server: it takes hours of CPU time and a well-tuned database. Afterwards, minutely or daily change files keep the database current without a full reimport.

The grid: why maps are cut into tiles

Nobody renders a whole country on demand. Instead, the world is projected into Web Mercator and cut into a pyramid of square tiles. Zoom level 0 is a single tile showing the entire planet. Each further level splits every tile into four, so level 1 has 4 tiles, level 2 has 16, and by level 14 — roughly neighbourhood scale — there are over 268 million. Every tile has a simple address, z/x/y, which is why a map request looks like /tiles/14/8593/5471.png. This grid is the reason web maps feel instant. Your browser only ever asks for the handful of tiles that are currently on screen, and the server — or a cache in front of it — only ever has to deliver those.

The rendering: where raster and vector part ways

At this point the pipeline forks, and the rest of this text is about that fork.

Caching and delivery

Whichever path you take, finished tiles are cached — on disk, in a tile store, on a CDN edge — so that the second visitor asking for the centre of Berlin gets a file, not a computation. A well-run map server serves the overwhelming majority of its traffic from cache. That is what makes the difference between a map that feels native and one that feels like a website from 2008.

The client

Finally a JavaScript library in the browser — Leaflet and OpenLayers for raster, MapLibre GL JS for vector — arranges the tiles, handles panning and zooming, and puts your own data on top: branches, delivery areas, routes, sensors.f

What is the difference between raster and vector maps?

Advantages and disadvantages of each approach

Strengths of Raster Tiles

Universal compatibility. A raster tile is an image. It works in every browser, every framework, every ancient corporate desktop, inside a PDF, inside an email, inside a printed brochure. Nothing to negotiate.
Predictable client load. The device draws pictures. A ten-year-old tablet or a low-end phone renders the map exactly as fast as a workstation.
Exactly what you designed. Cartography is finalised on the server. What you approve in review is what every user sees, pixel for pixel.
The natural format for imagery. Aerial photography, satellite scenes, hillshading and other continuous surfaces are raster by nature — there is no vector equivalent. strategy
No monitoring setup
Trivially cacheable. Any HTTP cache or CDN on earth knows what to do with a PNG. support included

Limitations of Raster Tiles

Storage grows explosively. Pre-rendering a country to high zoom levels produces millions of files and hundreds of gigabytes; a full planet cache reaches the terabyte range.
Restyling means re-rendering. Changing a road colour or the label font invalidates the entire cache. A new corporate design is a compute job measured in hours or days, not a config change.
One style per tileset. A light theme, a dark theme and a print theme are three separate renders, three separate caches, three times the storage.
Fixed zoom steps. Between levels the browser scales the image, so intermediate zooms look soft. Rotation and tilt are not possible — labels would rotate with the picture.
Labels are baked in. No switching languages at runtime, no hiding labels, no letting the user toggle street names.
No access to the underlying data. The browser sees pixels. Knowing which building the cursor is over requires a second request to a separate service.

Strengths of Vector Tiles

One dataset, unlimited designs. Light mode, dark mode, a high-contrast accessible variant, a muted backdrop for your own data layers — all from the same tiles, switchable instantly, with no re-rendering and no additional storage.
Smooth, continuous zoom, rotation and tilt. Because the map is drawn live, it scales fluidly between zoom levels and can be rotated or pitched into a 3D view with extruded buildings. This is the interaction quality users now expect from their phone.
Crisp on every screen. Vectors are resolution-independent. The same tile is razor-sharp on a 4K monitor and on a high-DPI phone — no two variants needed.
Substantially smaller. Vector tiles are typically a fraction of the size of the equivalent raster coverage, which means less storage, less bandwidth and faster first paint on mobile networks.
The data is right there. Hover a building and read its address; click a road and read its classification; filter the map to show only cycle-friendly streets. No extra query, no extra service.
Labels stay upright and stay flexible. Rotate the map and labels remain readable. Switch a site to English, French or Polish and the map switches with it, if the tiles carry the name variants.

Limitations of Vector Tiles

The client does the work. Rendering needs WebGL and a reasonably modern browser. Very old devices, locked-down corporate environments or browsers with hardware acceleration disabled will struggle or fall back.
Higher CPU and battery use on the end device than displaying a static image — noticeable on weak hardware and dense styles.
A more demanding toolchain. Style definitions, glyph sets for fonts and sprite sheets for icons all have to be produced and hosted. Cartographic fine-tuning is a specialist skill.
Not a print format. Brochures, PDFs, reports and emails need an image. Vector maps have to be rendered to raster for that — an extra step, usually server-side.
Schema dependency. Which attributes end up in the tiles is decided when they are generated. Adding a field later means regenerating the tileset.