A Guide to Mapping and Location APIs

The Jobs a Mapping API Can Do

An API (application programming interface) is a way for one program to ask another for something. A mapping API answers geographic questions: what does this area look like, what is near here, how long will it take to get there. Almost every such question falls into one of five jobs.

Base Maps and Map Display

The base map is the background picture: streets, water, parks, and labels. It is delivered as tiles, small squares that an app requests only for the area and zoom level currently on screen. Tiles come in two flavors:

• Raster tiles are finished images drawn on a server. They are simple to display, but the look is fixed and cannot be restyled by the app.
• Vector tiles contain the shapes and labels as data, and the device draws them. That allows smooth zooming, rotation, and restyling (a dark mode, for instance), at the price of more work for the device.

A map SDK (software development kit) is the library that fetches the tiles, draws them, responds to pinching and dragging, and lets a developer add markers and lines on top. Commercial providers publish their own SDKs, and open-source libraries such as Leaflet, OpenLayers, and MapLibre can display tiles from many sources. In plain words, the app sends an area and a zoom level and gets back the pieces needed to draw it. A hiking app with contour lines and a food-delivery app with a clean street map are doing the same job with differently styled tiles.

Places and Points-of-Interest Search

A point of interest (POI) is a named place someone might want to visit: a café, a pharmacy, a museum, a playground. Places services usually offer three kinds of request:

• Nearby search: a location, a distance, and a category go in; a list of matching places comes out.
• Text search: a phrase a person would type goes in; a ranked list of likely matches comes out.
• Place details: an identifier for one specific place goes in; its address, phone number, opening hours, and sometimes ratings or photos come out.

A traveler looking for a café near a hotel is relying on a nearby search followed by place details. How good the answers are depends on how complete and current the underlying place data is, which varies by provider and by region.

Routing and Directions

A routing service finds a path through a road network. The inputs are a start, a destination, optional stops in between, and a way of traveling (car, bicycle, on foot, truck). The outputs are a line to draw on the map, a total distance, an estimated travel time, and usually step-by-step instructions.

Two related tools answer bigger questions with the same road data:

• Distance matrix: travel times and distances between many starting points and many destinations in a single request, returned as a table. A delivery company might use one to find which van is closest, by road, to each customer.
• Isochrone: the area that can be reached from a point within a set time, returned as a shape. It shows, for example, which neighborhoods are within a 15-minute walk of an apartment.

Geocoding and Reverse Geocoding

Geocoding turns text into coordinates: a street address or place name goes in, and a latitude and longitude come out. It is what places a pin on the map after someone types an address into a delivery form. Reverse geocoding goes the other way: coordinates go in, and a human-readable address or place name comes out. A photo app that labels pictures with the town where they were taken is reverse geocoding.

Addresses are messy: people abbreviate, misspell, and leave parts out, and formats differ between countries. A geocoder therefore often returns several candidate matches, with a hint about how precise each one is (an exact building, a street, or only a city).

Raw Map Data Access

The four jobs above are finished services: ask a question, get a ready-made answer. Sometimes a developer wants the underlying data instead: the road lines, building outlines, and other mapped features, each with its descriptive attributes. That data can be downloaded in bulk and loaded into a database, or requested from a query service that returns only the matching features.

A city planner counting the public drinking fountains in a district and a game studio building a virtual city from real building footprints are both working with raw map data. The input is a region and a description of the features wanted; the output is a set of points, lines, and shapes with their attributes. This route is the most flexible and also the most work, because nothing arrives ranked, summarized, or drawn.

Who Provides Them

The names below come up again and again in mapping projects. Each is described only by what it is known for.

The table mixes different kinds of thing. OpenStreetMap and Overture are data: collections of mapped features that anyone can download. Overpass, Nominatim, and the routing engines are software that turns open data into answers, and somebody has to run that software on a server. The commercial providers sell a service: data, software, and servers bundled into one product.

The line between the two worlds is not sharp. Commercial maps can incorporate open data alongside proprietary data, and companies sell hosted versions of open-source tools. It helps to treat open versus commercial as two separate questions: who owns the data, and who operates the servers?

Open Data vs. Commercial Services: The Trade-Offs

Neither approach is better in general. Each has strengths that weigh differently from project to project.

Coverage and Freshness

Commercial providers invest heavily in collecting data and tend to offer consistent place details such as opening hours and phone numbers. Open data depends on its contributors: it can be remarkably detailed where the community is active and thinner where it is not, and anyone who spots a mistake can correct it. Either kind can be the stronger one in a particular town, so the reliable test is to check the places that matter.

Cost Model

Commercial services are typically priced by usage, so cost rises and falls with the number of maps shown and requests made. Open data carries no license fee, but using it is not free: servers, storage, regular data updates, and maintenance time all cost money, even when traffic is low.

Self-Hosting

Open-source engines can run on a team's own servers. That brings control over the data, the update schedule, and user privacy, and it makes the team responsible for keeping everything running, updated, and fast. A commercial service takes that operational work away, in exchange for depending on the provider's pricing and product decisions.

Terms of Use

Open licenses grant broad freedom to use, copy, and adapt the data, with conditions attached. Commercial terms are contracts, and they can limit things such as how long results may be stored or how they may be combined with content from other sources.

Licensing and Attribution Basics

OpenStreetMap data is published under the Open Database License (ODbL). Anyone may use it, including commercially, provided they give credit. The credit reads "© OpenStreetMap contributors" and is normally shown in a corner of the map. The license also has a share-alike condition: a database derived from OpenStreetMap data that is distributed publicly must be offered under the same license. The details are set out on the OpenStreetMap copyright page.

Commercial providers each have their own terms. These commonly cover how the map must be displayed, whether and for how long results may be cached, and which logos or attribution lines must remain visible. Terms differ between providers and change over time, so always read the current version.

A Sidebar on Coordinate Order

One small detail trips up nearly everyone who works with map data. In everyday use, people say latitude first and longitude second. GeoJSON, a widely used format for geographic data defined in RFC 7946, writes them the other way around: longitude first, then latitude, in the same spirit as x before y on a graph.

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-74.0445, 40.6892]
  },
  "properties": {
    "name": "Statue of Liberty"
  }
}

Swap the two numbers and the pin moves from New York Harbor to Antarctica. APIs and libraries follow different conventions, so it is worth checking the documentation each time.

How to Choose: Questions to Ask

There is no single right answer, only a fit between a project and a set of trade-offs. Five questions help:

1. What job needs doing? A store locator may need only map display and geocoding; a delivery planner leans on routing.
2. What coverage is needed? Name the regions that matter, then test each candidate with real addresses and places that someone on the team knows well.
3. What is the budget? Estimate how many requests the expected audience will trigger, and compare usage fees against the cost of servers and staff time.
4. What do the terms allow? Check whether results can be stored, whether they can be shown on any map or only the provider's own, what attribution is required, and whether offline use is permitted.
5. What happens at scale? Ask what changes if usage grows tenfold: the bill, the limits, the hardware, and how hard it would be to switch.