Skip to content
GuidesBlogPlaygroundDashboard

Plaza: The Geospatial Layer for AI

Every AI agent that interacts with the physical world needs geospatial data. Most of them are calling Google Maps or Mapbox — APIs built for rendering web maps, not for tool use by language models. Those APIs are expensive, require stitching multiple providers together, and return inconsistent response formats across endpoints.

Plaza is a single geospatial data API with billions of features — the full OpenStreetMap planet, curated open datasets, and custom user data. Geocoding, routing, search, isochrones, distance matrices, elevation, map matching, route optimization, and — critically — arbitrary spatial queries via PlazaQL. One base URL, one auth mechanism, GeoJSON everywhere.

The real power: PlazaQL as a graph query language

Section titled “The real power: PlazaQL as a graph query language”

Think about what people actually ask AI assistants:

  • “I need to get to the office, but I need to stop by the pharmacy on the way”
  • “Find me a coffee shop with wifi near a subway station in Manhattan”
  • “Where can I charge my EV between here and Portland?”
  • “What parks are within a 15-minute walk?”

These sound simple, but with traditional APIs they’re multi-step nightmares. “Stop by the pharmacy on the way” means: geocode the origin, geocode the destination, find pharmacies, figure out which ones are near the route, re-route through the best one. That’s 4-5 API calls across potentially different providers.

With Plaza, each of these is a single query.

The real power is PlazaQL. It lets an agent query billions of features like a graph database. Things that would take multiple API calls with any other provider become a single query:

“I need to stop by a pharmacy on the way to work”:

$r = route(origin: point(40.748, -73.993), destination: point(40.755, -73.970));
$$ = search(node, amenity: "pharmacy").around(distance: 200, geometry: $r).sort(distance($r));

One query: compute the route, find pharmacies within 200m of it, sort by distance. With Google Maps this is 3 separate API calls across 2 different services.

“Find coffee shops with wifi near subway stations in Manhattan”:

$manhattan = boundary(name: "Manhattan", admin_level: "7");
$subway = search(node, railway: "subway_entrance").within(geometry: $manhattan);
$$ = search(node, amenity: "cafe", internet_access: "wlan").around(distance: 200, geometry: $subway);

Resolve Manhattan’s boundary, find subway entrances inside it, then find cafes with wifi within 200m of those entrances. A multi-hop spatial query in a single POST.

“Where can I charge my EV between here and Portland?”:

$r = route(origin: point(45.52, -122.68), destination: point(47.61, -122.33));
$$ = search(node, amenity: "charging_station").around(distance: 5000, geometry: $r).sort(distance($r));

“What parks are within a 15-minute walk?”:

$$ = search(node, leisure: "park").around(distance: 1200, geometry: point(40.748, -73.993));

One POST to https://plaza.fyi/api/v1/query, GeoJSON back. LLMs are good at generating PlazaQL from natural language — give the agent one tool that accepts a query string and it can answer almost any spatial question.

When a user asks “What’s within a 15-minute walk?”, an isochrone gives you the exact reachable area as a polygon:

Terminal window
curl -X POST https://plaza.fyi/api/v1/isochrone \
-H "Content-Type: application/json" \
-d '{"center": {"type": "Point", "coordinates": [-73.993, 40.748]}, "time": 900, "mode": "walking"}'

The agent gets back a GeoJSON polygon it can use to filter results, display on a map, or feed into the next query. Combine it with PlazaQL to find specific things within that reachable area.

The difference between “18 fixed endpoints” and “a query language over a planet-scale graph” is the difference between an agent that can answer pre-defined questions and one that can reason about physical space.

An agent with Plaza can:

  • Compose multi-hop spatial queries — “Find cafes near subway stations in Manhattan” becomes a single query using variables and area resolution
  • Search along routesroute() computes a route, then .around(distance: 200, geometry: $r) finds things near it — no separate API calls
  • Filter by arbitrary attributes — OSM has millions of tags: cuisine=sushi, wheelchair=yes, opening_hours, height, building:levels
  • Use named areas as boundaries — Query by city, country, neighborhood, or any administrative boundary without knowing coordinates
  • Transform results inline.buffer(), .sort(distance($r)), .limit() process geometry server-side before returning

Plaza ships an MCP server that gives any compatible agent geospatial reasoning instantly. One command to install, and your agent can geocode, route, search, and run PlazaQL queries.

Claude Code:

Terminal window
claude mcp add plaza --env PLAZA_API_KEY="pk_live_YOUR_KEY" -- npx -y @plazafyi/mcp

Cursor: one-click install · VS Code: one-click install

That’s it. Your agent now has access to geocoding, routing, isochrones, place search, and a full PlazaQL query engine. It works with Claude, GPT, or any MCP-compatible model.

Under the hood, the server uses a “Code Mode” scheme — your agent writes code against the Plaza TypeScript SDK, which runs in an isolated sandbox. This means it can chain operations, transform data, and compose complex queries deterministically. It’s not just calling REST endpoints; it’s writing and executing spatial logic.

Plaza covers the spatial data layer — geometry, topology, routing, search. It doesn’t have real-time traffic, Street View imagery, or business reviews. If your agent needs to know whether a restaurant is currently busy, you’ll need another provider for that.

Grab an API key from plaza.fyi/dashboard (free tier, no credit card) and point your agent at the MCP server. It takes about 30 seconds.

SDKs: TypeScript · Python · Go · MCP Server