OSM Vector Tiles vs Features API (Overpass Alternative)

The short answer: OpenStreetMap vector tiles are for drawing a map. A features API, such as Overpass or the MapLark OSM Features API, is for querying it. Tiles give you simplified, pre-built shapes with a fixed handful of fields. A features API gives you every OSM object that matches your tag and area filter, with all its tags and its full, unclipped geometry, ready for analysis.

What is the difference between OSM vector tiles and a features API?

OpenStreetMap is the largest free, editable map of the world. Its tag model (key=value on node, way, and relation objects) is the lingua franca of open geospatial tooling. Most apps get that data through vector tiles, and for rendering a basemap that is the right call. But tiles and a feature query API solve different problems, and it helps to be precise about where each one wins.

Vector tiles vs the OSM Features API at a glance

Can you query OSM tags from vector tiles?

Mostly no. Vector tile schemas like OpenMapTiles are much smaller than raw OSM data, and they are built for one job: fast, cheap basemap rendering at any zoom level. That is a good trade-off for drawing a map, but it has real costs if you need to reason about what is on it.

• Clipped geometries: building polygons crossing a tile boundary are chopped into pieces, making exact circumference or area calculations inaccurate.
• Generalization: shapes are simplified depending on the zoom level, removing precise vertex data.
• Attribute stripping: general basemap tiles drop specific descriptive tags like amenity=ice_cream to keep tile sizes small.

OpenMapTiles specifically: POIs without their tags

OpenMapTiles does include point-of-interest layers, so cafes, shops, and amenities show up as points on the map. But the schema only ships the handful of fields it decided to carry: a name, a coarse class and subclass, sometimes a brand. Tags like opening_hours, outdoor_seating, wheelchair, or building:levels are not in the tile at all.

That is not a client-side filtering problem you can work around. The attribute was dropped when the tileset was built, so there is no way to ask "which cafes are open after 3pm" from tile data. The information is not there.

When are vector tiles the right tool?

None of this makes vector tiles bad. They are small, pre-generalized per zoom level, and built for fast, cheap basemap rendering in the browser while panning and zooming a large area. If the map itself needs to render fast rather than be queried, tiles are the right call. For a free basemap CDN, OpenFreeMap works well.

Tiles are also the right choice when the data is yours. If you are rendering your own geospatial dataset, like a Strava-style activity heatmap or a GPS-track density layer, tiling it for smooth client-side rendering is a good idea. That is a rendering problem, not a query problem.

When do you need a features API instead of tiles?

Use the OSM Features API when the query needs a tag the tile schema does not carry, or a geometry precise enough to compute on:

• Filtering cafes by opening_hours or outdoor_seating, attributes tiles drop entirely.
• Finding EV charging stations by connector type (socket:type2) within 500 m of a point.
• Pulling exact building footprints for solar or shadow-casting math, where a generalized zoom-level shape would give the wrong answer. See how to get building heights from OpenStreetMap.
• Routing analysis over highway=cycleway LineStrings, where you need the real vertex path, not a simplified line.
• Any bulk, precise set: every cafe in this viewport, or all charging stations within 500 m, instead of one rendered pin at a time.

Here is the cafe question from above as a single request. It returns GeoJSON for every cafe in the bounding box that is tagged with outdoor seating, whether it is mapped as a point or as a building outline (type=node,way with way_shape=polygon):

curl -G "https://api.maplark.com/v3/osm_features" \
  -H "Authorization: Bearer <your-api-key>" \
  --data-urlencode "bbox=18.05,59.32,18.10,59.34" \
  --data-urlencode "type=node,way" \
  --data-urlencode "way_shape=polygon" \
  --data-urlencode "tags=amenity=cafe,outdoor_seating=yes"

The tags parameter takes boolean expressions with AND, OR, NOT, grouping, and regex. See the tags query language for the full syntax.

Is the MapLark OSM Features API an Overpass alternative?

Yes, for most application queries. The Overpass API is the community-run query service for OpenStreetMap, and it answers the same kind of question as a features API: "give me the OSM objects that match these tags in this area." The MapLark OSM Features API covers that ground in an Overpass-style way:

• Same data model: the same OSM tags and the same node, way, and relation objects you already know.
• Plain REST instead of Overpass QL: filter with URL parameters and a tags expression, no query language to learn.
• Application-ready output: GeoJSON, FlatGeobuf, GeoParquet, CSV, or TSV directly, with no format conversion.
• Managed infrastructure: dedicated PostGIS over planet-scale data instead of shared community servers.

One honest limit: Overpass QL itself is not supported yet. If you have existing Overpass QL queries, contact us about the early preview. To see how it was built and how it compares, read Building the New OSM Features API: A Planet-Scale Overpass Alternative.

How do vector tiles, geocoding, and the Features API fit together?

Use OpenMapTiles to see the map and a geocoder to find a place: basemap tiles plus search that returns a ranked place card (name, pin, bounding box, hierarchy). Use MapLark when the app must reason about the map: footprints, networks, POIs by tag, areas, anything that needs real coordinates and OSM semantics.

Geocoding answers "where is this place?" The OSM Features API answers "what OSM objects match these tags here, with which shapes and semantics?" In a real app the two sit on different layers: geocode the site, then pull the OSM features you need from MapLark and run length, area, shadow, or coverage math in your own code. For a worked example, see free maps for developers: draw pins with OpenFreeMap, compute with MapLark.

A typical map stack looks like this:

• Basemap tiles from MapTiler or Mapbox (paid, and often expensive at scale), or OpenFreeMap for a free CDN.
• Your own data (tracks, heatmaps, custom layers) tiled for smooth rendering, the same way a basemap is.
• Place search and geocoding from those same vendors (or Nominatim-style services).
• MapLark for geospatial intelligence: calculate on building polygons, park areas, or road lengths.
• Open standards first (GeoJSON and OSM tags), so Overpass knowledge and AI training transfer.
• AI agents can use the same data through the OpenStreetMap MCP server instead of guessing streets and hours.

Frequently asked questions

What is the difference between vector tiles and a features API?

Vector tiles are pre-built, simplified map data for drawing a basemap quickly. A features API such as Overpass or the MapLark OSM Features API runs a query against OpenStreetMap data and returns the matching objects with all their tags and full geometry, so you can filter and compute on them.

Can I get OSM tags like opening_hours or outdoor_seating from vector tiles?

Not from a general basemap tileset. OpenMapTiles keeps a name and a coarse class and subclass for points of interest, and drops tags such as opening_hours, outdoor_seating, wheelchair and building:levels when the tiles are built. To filter on those tags, query the OSM data directly with a features API.

Is the MapLark OSM Features API an Overpass alternative?

Yes, for most application queries. It uses the same OSM tag semantics and node, way and relation model as Overpass, but you call it with plain REST parameters and a tags expression instead of Overpass QL, and it runs on managed PostGIS rather than shared community servers. Overpass QL itself is not supported yet.

Why are building areas from vector tiles inaccurate?

Tile builders clip polygons at tile boundaries and simplify shapes per zoom level. A building that crosses a tile edge arrives in pieces, and vertices are removed at lower zooms, so area and perimeter calculations on tile geometry give wrong answers. A features API returns the whole, unclipped polygon.

Should I use vector tiles and a features API together?

Usually yes. Use tiles (for example from OpenFreeMap, MapTiler or Mapbox) to draw the map, a geocoder to find places, and a features API to pull the OSM objects your code needs to analyse.

What formats does the MapLark OSM Features API return?

GeoJSON by default, plus FlatGeobuf, GeoParquet, CSV and TSV, so there is no format conversion step.

Is there a free plan?

Yes. MapLark has a free forever plan. Sign up for an API key and start querying OSM.