How is the Features API different from Vector Tiles?

Many applications need facts about the real world: building heights, road networks, park areas, and amenity locations. OpenStreetMap is the largest free, editable map of the world, and its tag model (key=value on node, way, and relation objects) is the lingua franca of open geospatial tooling. Most apps get that map 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 is worth being precise about where each one wins.

Standard vector tiles have limitations

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 genuinely good trade-off for drawing a map, but it comes with 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 vector 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 do 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/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 simply is not there.

Vector tiles are still the right tool for a lot of jobs

None of this makes vector tiles bad. They are small, pre-generalized per zoom level, and built for exactly one job: 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.

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, and vector tiles are built to solve exactly that.

When to reach for MapLark 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.
• 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.

Compared to OpenMapTiles (and similar platforms)

Use OpenMapTiles to see the map and MapBox to find a place: basemap tiles plus search/geocoding that return a ranked place card (name, pin, bbox, hierarchy). For a free basemap CDN, OpenFreeMap works well. 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?" OpenMapTiles does not ship that Overpass-style query surface. 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.

The practical middle path

A typical map stack already has someone drawing tiles and answering "where is this place?" MapLark is the layer above that: OSM objects, tags, and full geometries for apps that need to reason about the map.

• 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 + OSM tags), so Overpass knowledge and AI training transfer.
• No format conversion. Get GeoJSON, FlatGeobuf, GeoParquet, CSV, or TSV directly from the API.