Forem: Alfiya Tarasenko

Confused between Routing APIs and Route Optimization APIs? This guide breaks down the difference with clear examples, a side-by-side comparison, and when to use each in real applications.

Alfiya Tarasenko — Mon, 20 Apr 2026 12:12:12 +0000

Alfiya Tarasenko for Geoapify Maps API

Apr 20

What Is the Difference Between a Routing API and a Route Optimization API?

#api #maps #routing #appdev

Comments

4 min read

What Is the Difference Between a Routing API and a Route Optimization API?

Alfiya Tarasenko — Mon, 20 Apr 2026 12:11:30 +0000

If you're building a map-based or logistics application, you’ll likely come across two terms that sound very similar: Routing API and Route Optimization API.

At first glance, they may seem interchangeable. Both deal with routes, distances, and travel time. But in practice, they solve very different problems.

In simple terms

A routing API calculates the path between given points and returns the actual route (geometry, distance, time)
A route optimization API determines the most efficient order of stops, without necessarily returning full route geometry

For example, a routing service like the Geoapify Routing API helps you build directions from point A to point B, from B to C, and so on — following a predefined order.

In contrast, the Geoapify Route Optimization API is designed to organize multiple stops — even across multiple vehicles — into the most efficient routes.

In this article, we’ll break down the difference step by step, compare how each API works, and show when to use one over the other.

What is a Routing API?

A routing API is used to calculate the path between locations in a predefined order.

You provide a list of waypoints, and the API returns the route that connects them — including distance, estimated travel time, and often turn-by-turn instructions.

Key characteristics

Works with a fixed sequence of points (A → B → C)
Returns full route geometry (coordinates for map display)
Provides distance and travel time
Can include turn-by-turn navigation instructions
Supports different travel modes (driving, walking, cycling, etc.)
Allows avoiding specific route parts (tolls, highways, ferries, etc.)
Can provide additional details like road type, surface, and other route attributes

Example use cases

Showing directions from a user’s location to a destination
Displaying a route on a map
Building navigation features in apps

Try it yourself

You can test routing requests in the. Geoapify API Playground: enter a few waypoints and see how the API builds a route step by step.

What is a Route Optimization API?

A route optimization API is designed to find the most efficient way to visit multiple locations.

Instead of following a predefined order, you provide a list of stops, and the API determines the best sequence to minimize travel time, distance, or overall cost.

Key characteristics

Works with an unordered set of locations
Optimizes the sequence of stops
Supports multiple vehicles and route assignments
Focuses on efficiency (time, distance, cost)
Can handle constraints like time windows, capacities, or working hours
Does not necessarily return full route geometry (focus is on planning)

Example use cases

Delivery route planning
Field service scheduling
Logistics and fleet management
Last-mile delivery optimization

Try it yourself

You can experiment with route optimization in the Geoapify API Playground: generate a task, visualize it on the map, solve it, and check the optimized result.

Routing API vs Route Optimization API

The difference between these two APIs is easiest to understand when viewed side by side:

Feature	Routing API	Route Optimization API
Main goal	Calculate a route between points	Find the most efficient order of stops
Input	Ordered waypoints (A → B → C)	Unordered locations (optionally with multiple vehicles)
Output	Route geometry, distance, time	Optimized sequence + route assignments
Focus	Navigation	Planning & efficiency
Usage	Route planning and live navigation	Route planning
Multi-vehicle support	❌ No	✅ Yes
Constraints (time windows, capacity, shifts)	❌ No	✅ Yes

Key takeaway

Routing API → connects points in a given order
Route Optimization API → determines the best order of points

In short: routing builds routes, optimization plans them.

When to Use Each API

Choosing between a Routing API and a Route Optimization API depends on the problem you’re solving.

Use a Routing API if:

You need directions between points
The order of stops is already known
You want to display routes on a map
You are building navigation features (including live navigation)

Example:

Show directions from a user’s location to a destination, or follow a predefined route A → B → C.

Use a Route Optimization API if:

You have multiple stops and the order is not fixed
You want to minimize travel time, distance, or cost
You need to plan routes for multiple vehicles
You have constraints like time windows or capacity

Example:

Plan delivery routes for 20 addresses across several drivers.

Use both together (common in real apps)

In many applications, these APIs are combined:

Route Optimization API → determines the best order of stops
Routing API → builds the actual routes between those stops

In practice, you often need to use a Routing API after optimization to generate routes between the optimized waypoints, visualize them on a map, or provide navigation instructions.

This approach gives you both efficiency and detailed route information.

Conclusion

Routing APIs and Route Optimization APIs may sound similar, but they solve fundamentally different problems.

Routing API → calculates how to get from one point to another
Route Optimization API → decides the best order to visit multiple points

If your app needs directions or navigation, a Routing API is the right choice.

If you’re planning deliveries, field service routes, or logistics workflows, you’ll need a Route Optimization API.

In many real-world applications, the best solution is to use both:

Optimization to plan the route
Routing to build and display it

Understanding this difference helps you choose the right tool, avoid unnecessary complexity, and build more efficient applications.

Try it yourself

Want to see the difference in action?

Routing API → https://apidocs.geoapify.com/playground/routing/
Route Optimization API → https://apidocs.geoapify.com/playground/route-planner/

Create a simple route and then try optimizing multiple stops — the difference becomes immediately clear.

Why does reverse geocoding return a slightly different address than where you click? This article explains why it happens, how distance is calculated, and how to handle it in your app — with a live demo.

Alfiya Tarasenko — Wed, 15 Apr 2026 12:26:19 +0000

Alfiya Tarasenko for Geoapify Maps API

Apr 15

Why Reverse Geocoding Doesn’t Return the Exact Clicked Location

#reverse #geocoding #gis #api

Comments

4 min read

Why Reverse Geocoding Doesn’t Return the Exact Clicked Location

Alfiya Tarasenko — Wed, 15 Apr 2026 00:42:58 +0000

When you click on a map and request an address for that exact point, you might expect a perfect match.

But in practice, the returned address can differ slightly from the location you clicked — sometimes by just a few meters, sometimes more.

If you’ve noticed this behavior in your app, you’re not dealing with a bug. It’s a natural result of how reverse geocoding works.

In this article, we’ll explore why the address you get doesn’t always exactly match the clicked map point, and what this means when building map-based applications.

This example uses a simple map demo powered by the Geoapify Reverse Geocoding API , so you can see this behavior in action.

👉 CodePen demo / code sample

What Reverse Geocoding Actually Returns

Reverse geocoding doesn’t return the exact point you clicked.

Instead, it returns the closest known addressable location in the dataset. That’s a key difference.

Coordinates represent a continuous space — every point on the map has a latitude and longitude.

Addresses, on the other hand, are discrete. They only exist where real-world objects are defined:

buildings
entrances
parcels
points of interest

So when you click somewhere on the map, the system has to answer a different question:

“What is the nearest meaningful address to this point?”

Not:

“What exists exactly at this coordinate?”

What this means in practice

Clicking on a road → returns a nearby building or street address
Clicking inside a park → returns the nearest street or POI
Clicking near a building → returns the building’s registered address point

Even if the difference is just a few meters, it’s expected behavior.

How Far Is the Returned Location from the Clicked Point?

Once you understand that reverse geocoding returns the nearest address, the next logical question is:

How far is the returned result from the original point?

There isn’t just one answer — because there are two different ways to measure distance.

1. Distance to the Returned Object (Geometry Distance)

When the returned result represents a building or boundary, the distance is calculated between:

your clicked point
and the geometry (polygon) of that object

This leads to an important detail:

👉 If your point is inside the building polygon, the distance can be 0,

even if the returned coordinate (for example, the entrance) is several meters away:

{
  "results": [
    {
      "country": "Germany",
      "city": "Nuremberg",
      "postcode": "90425",
      "street": "Pretzfelder Straße",
      "housenumber": "15",
      "lon": 11.064715,
      "lat": 49.4718661,
      "result_type": "building",
      "formatted": "Pretzfelder Straße 15, 90425 Nuremberg, Germany",
      "distance": 0
    }
  ],
  "query": {
    "lat": 49.47177742331178,
    "lon": 11.064803253993091
  }
}

Example:

You click inside a large building
The address is tied to the entrance
The API may report distance = 0 (because you are inside the building)
But visually, the returned point is offset

2. Real Distance Between Coordinates

This is the actual distance between:

the clicked point
and the returned coordinate

This is what you usually need if you want to measure the visible offset.

Option 1: Haversine Formula

You can calculate the distance between two coordinates using the Haversine formula:

d = 2r * arcsin(√(sin²((lat2 - lat1) / 2) + cos(lat1) * cos(lat2) * sin²((lon2 - lon1) / 2)))

Where:

lat1, lon1 = clicked point
lat2, lon2 = returned location
r = Earth radius (≈ 6371 km)

Option 2: Using Turf.js

If you're working in JavaScript, you can use a geospatial library like Turf.js to calculate distances easily.

@turf/distance handles geographic calculations for you and returns accurate results in different units, so you don’t need to implement the formula manually.

import distance from '@turf/distance';

const from = [lon1, lat1];
const to = [lon2, lat2];

const dist = distance(from, to, { units: 'meters' });

Option 3: Using Geoapify Geometry API

You can also calculate distances using the Geoapify Geometry Operations API.

This API lets you calculate distances between geometries — including points, lines, and polygons — without implementing the logic yourself.

Example request:

POST https://api.geoapify.com/v1/geometry/operation?apiKey=YOUR_API_KEY

{
  "operation": "distance",
  "point1": {"type": "Point", "coordinates": [lon1, lat1]},
  "point2": {"type": "Point", "coordinates": [lon2, lat2]},
  "params": {
    "units": "kilometers"
  }
}

This approach is useful when you want:

server-side calculations
consistent results across services
support for complex geometries (not just points)

It can also be integrated into AI agents or automated workflows, where distance calculations are part of a larger decision-making process (for example, validating locations or triggering actions based on proximity).

Code Sample: Try It on a Map

Seeing this in action makes the behavior much easier to understand.

Try clicking on different locations in this interactive demo:

👉 CodePen demo / code sample

What to test:

Click directly on a building
Click on a road
Click inside a park or open area
Click near building edges or entrances

You’ll notice that:

the returned address doesn’t always match the exact clicked point
the marker may appear slightly shifted
results depend on nearby addressable objects

This makes it easier to see how reverse geocoding behaves in real-world scenarios.

How to Handle This in Your App

To avoid confusion when working with reverse geocoding:

Don’t expect exact matches — results are approximate
Show both clicked and returned locations if needed
Use distance thresholds for validation
Prefer geometry checks (e.g., inside building) for higher accuracy
Communicate clearly that the address is the nearest one

These small adjustments can significantly improve user experience.

Is There a Free UK Postcode Lookup API?

Alfiya Tarasenko — Sat, 11 Apr 2026 21:42:33 +0000

At first glance, the answer seems like yes. There are several APIs that let you search postcodes and return location or address data — for example, the Geoapify Postcode API.

But if you try a few of them, you’ll notice something: results can differ. Some APIs return more complete data, others return partial results — or nothing at all for the same postcode.

Even well-known providers can be inconsistent. The reason isn’t the API. It’s the data.

In the UK, the most complete postcode and address dataset is owned by Royal Mail and distributed under license. Free alternatives exist, but they are never fully complete or fully up to date.

What is a postcode in the UK?

UK postcodes are part of the addressing system used by Royal Mail.

In practice, postcodes are linked to specific geographic points where real addresses are grouped. Each postcode represents a set of properties assigned to that location.

Unlike unique identifiers, a single postcode usually corresponds to multiple addresses — sometimes just a few buildings, sometimes dozens.

Example of postcode locations in London. Each point represents a postcode linked to a group of addresses. Source: ONS Postcode Directory (Live)

Postcodes were designed for mail delivery, not precise mapping. That’s why they are often represented as points (centroids) rather than exact building locations.

⚠️ Even when postcode locations are available, it’s not always clear which postcode a specific building belongs to. A postcode represents a group of addresses, not a single precise location.

Who owns UK postcode data?

The most complete postcode and address dataset in the UK is maintained by Royal Mail as part of the Postcode Address File (PAF). It contains the full mapping between postcodes and individual addresses.

However, it is not open data.

Access to Royal Mail data is licensed, which means it cannot be freely used, shared, or redistributed. Most developers don’t access it directly, but through official distributors and resellers such as Ideal Postcodes, Postcoder, or Loqate.

This creates several practical challenges:

Higher cost compared to open alternatives
Licensing restrictions (storage, caching, redistribution)
Limited flexibility for building public or large-scale services

As a result, this data is often unavailable to developers who need free, open, or permissively licensed solutions — forcing them to rely on alternative datasets.

Are there free UK postcode lookup solutions?

Yes — there are several free and open solutions available. However, they differ in coverage, structure, and use cases.

Open data sources

Here are the main open datasets used for UK postcode lookup:

Name	Link	Description
ONS Postcode Directory (ONSPD)	Dataset link	The most complete open dataset. Provides postcode coordinates and administrative areas, but no full addresses.
GeoNames	Dataset link	Global dataset with partial UK postcode coverage. Simpler and less detailed.
OpenStreetMap	Website	Crowdsourced dataset where postcodes are often assigned directly to buildings or areas. Coverage and accuracy vary.

These datasets are free and open, but they do not provide full postcode → address mapping.

Postcode lookup APIs based on open data

To make these datasets easier to use, you can rely on APIs built on top of open data.

One example is the Geoapify Postcode API.

It allows you to:

Search by postcode
Get coordinates and address information
Use a simple HTTP API

Geoapify combines multiple open data sources (such as OpenStreetMap and GeoNames) to provide practical postcode lookup functionality.

Here’s a request example:

curl "https://api.geoapify.com/v1/postcode/search?postcode=TW2%207LS&countrycode=gb&geometry=original&apiKey=YOUR_API_KEY"

And response example:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "postcode": "TW2 7LS",
        "lon": -0.3583,
        "lat": 51.4513,
        "datasource": {
          "sourcename": "geonames",
          "attribution": "GeoNames",
          "license": "CC BY 4.0",
          "url": "https://www.geonames.org/datasources/"
        },
        "country": "United Kingdom",
        "country_code": "gb",
        "state": "England",
        "city": "Greater London",
        "district": "London Borough of Richmond upon Thames",
        "formatted": "London, TW2 7LS, United Kingdom"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [-0.3583, 51.4513]
      }
    }
  ]
}

⚠️ Results are based on open data sources and may differ from official Royal Mail data.

Free vs Official UK Postcode Data: Which One to Use?

The right choice depends on your use case and requirements.

Comparison

	Proprietary data (Royal Mail PAF)	Open data solutions
Coverage	Most complete	High but incomplete
Addresses	Full address list	Limited or none
Accuracy	Highest	Good, but varies
Cost	Paid	Free
Licensing	Restricted	Open / permissive
Best for	Validation, delivery, checkout	Maps, search, analytics

When to use proprietary data

Use Royal Mail-based solutions (via licensed providers) if you need:

Accurate address validation
Checkout or form autofill
Delivery and logistics systems
Guaranteed coverage

When to use open solutions

Use open data and APIs (like Geoapify) if you need:

Postcode → location lookup
Mapping and visualization
General search functionality
Free or open-source-friendly solutions

Conclusion

So, is there a free UK postcode lookup API?

Yes — but with limitations.

Free and open solutions can work well for many use cases, especially for mapping, search, and general applications. But they rely on datasets that are not fully complete.

If you need accurate, address-level data, you’ll need access to Royal Mail’s licensed dataset.

In the end, UK postcode accuracy is not a technical problem — it’s a data ownership problem.

If you want to try a free solution yourself, explore the Geoapify Postcode API Playground and test postcode lookup in practice.

Google Maps isn’t your only option for place search 👀 I compared 5 Places APIs (Google, Geoapify, Foursquare, HERE, TomTom) with real examples, pricing, and trade-offs

Alfiya Tarasenko — Wed, 08 Apr 2026 12:38:40 +0000

Alfiya Tarasenko for Geoapify Maps API

Apr 8

Google Places API Alternatives: Which POI API Should You Use in 2026?

#webdev #javascript #api #programming

Comments

11 min read

Google Places API Alternatives: Which POI API Should You Use in 2026?

Alfiya Tarasenko — Wed, 08 Apr 2026 12:37:13 +0000

If your app needs to search for places — cafes, restaurants, shops, or any other points of interest — chances are you’ve looked at the Google Maps Platform first.

It’s a powerful solution, but it’s not always the best fit. Pricing, usage limits, licensing restrictions, or simply the need for more flexibility often push developers to look for alternatives.

What we’ll explore

In this article, we’ll take a practical look at Places APIs — focusing on one common use case:

Finding places by category. For example: cafes or restaurants near a location

We’ll compare how place search works across several popular providers and when each one makes the most sense to use:

Google Maps Platform — Places API
Geoapify — Places API
Foursquare — Places API
HERE Technologies — Geocoding & Search API
TomTom — Search API (POI search)
What to choose?

Use Case: Find Restaurants in Miami Beach

To keep this comparison practical, let’s use one specific scenario:

Find restaurants near this point in Miami Beach:

Latitude: 25.777415
Longitude: -80.132432

This is a good test case because every provider in this article supports location-based place search, but they expose it in different ways.

Key differences to keep in mind

Request structure: Some APIs use simple query parameters (location, radius, category), while others require more structured requests or additional configuration.
Search capabilities: APIs vary in how they support filtering, ranking, and biasing results.
Data sources: Some providers rely on proprietary datasets, while others are based on open data sources like OpenStreetMap.
Result format: The structure and level of detail in responses can differ significantly.

Even for a simple task like finding nearby restaurants, the choice of API can lead to very different results and developer experience.

Google Maps Platform — Places API

📘 Docs · 🔎 Playground · 💰 Pricing · ⚖️ Terms

The Google Maps Platform Places API is one of the most widely used solutions for working with points of interest.

It provides rich and detailed place data — including ratings, reviews, opening hours, and more — and is often the default choice for developers building location-based features.

Example request

POST https://places.googleapis.com/v1/places:searchNearby
Content-Type: application/json
X-Goog-Api-Key: YOUR_API_KEY
X-Goog-FieldMask: places.displayName,places.location,places.rating,places.reviews,places.photos

{
  "includedPrimaryTypes": ["restaurant"],
  "maxResultCount": 10,
  "locationRestriction": {
    "circle": {
      "center": {
        "latitude": 25.777415,
        "longitude": -80.132432
      },
      "radius": 1000
    }
  }
}

This request searches for restaurants near the given coordinates in Miami Beach within a 1 km radius and returns a limited set of fields.

Example response

{
  "places": [
    {
      "id": "sample-place-id-001",
      "displayName": {
        "text": "Sample Restaurant"
      },
      "formattedAddress": "100 Example St, Miami Beach, FL 33139, USA",
      "location": {
        "latitude": 25.778102,
        "longitude": -80.131245
      },
      "rating": 4.4,
      "userRatingCount": 1842,
      "websiteUri": "https://www.example.com",
      "nationalPhoneNumber": "(305) 555-0142",
      "regularOpeningHours": {
        "openNow": true,
        "weekdayDescriptions": [
          "Monday: 11:00 AM – 10:00 PM"
        ]
      },
      "primaryType": "restaurant",
      "primaryTypeDisplayName": {
        "text": "Restaurant"
      }
    }
  ]
}

The response can include much more than basic place information. In addition to name, location, and rating, the API can return reviews, photos, contact details, opening hours, and various attributes describing the place.

Reviews are returned directly in the response, while photos are provided as references that can be used to request actual images via a separate endpoint.

The exact data you receive depends on the fields specified in the X-Goog-FieldMask.

Pros

Rich place data — includes ratings, reviews, photos, opening hours, and many additional attributes
Flexible field selection — control response size and content via X-Goog-FieldMask
Large dataset — backed by a widely used platform with high user contribution and coverage

Cons

Pricing can scale quickly — depends on number of requests and fields requested, so cost estimation is important
Strict licensing terms — usage is limited by Google Maps Platform Terms, including requirements on how data is displayed, where it can be used, and integration with Google services
Data usage limitations — place data often cannot be stored long-term or used outside Google services
More complex requests — requires POST requests and field masks instead of simple query parameters

Geoapify — Places API

📘 Docs · 🔎 Playground · 💰 Pricing · ⚖️ Terms

Geoapify Places API provides access to POI data based on open data sources such as OpenStreetMap.

It focuses on simplicity and flexibility, offering a straightforward way to search for places by category, location, and additional filters.

Example request

GET https://api.geoapify.com/v2/places?categories=catering.restaurant&filter=circle:-80.132432,25.777415,1000&limit=10&apiKey=YOUR_API_KEY

This request searches for restaurants near the given coordinates in Miami Beach within a 1 km radius.

The API uses a simple GET request with query parameters, making it easy to test and integrate.

Example response

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "name": "Bella Cuba",
        "formatted": "Bella Cuba, 1659 Washington Avenue, Miami Beach, FL 33139, United States of America",
        "lat": 25.7909549,
        "lon": -80.1316981,
        "categories": [
          "catering",
          "catering.restaurant",
          "catering.restaurant.cuban"
        ],
        "catering": {
          "cuisine": "cuban"
        },
        "distance": 265,
        "datasource": {
          "sourcename": "openstreetmap",
          "license": "Open Database License",
          "attribution": "© OpenStreetMap contributors"
        },
        "raw": {
            "osm_id": 3057276069,
            "osm_type": "n"
          }
      },
      "geometry": {
        "type": "Point",
        "coordinates": [-80.1316981, 25.7909549]
      }
    }
  ]
}

The response uses a standard GeoJSON-like structure, which is especially convenient for map applications. Depending on available source data, results may include categories, cuisine, phone number, website, opening hours, and other attributes.

The datasource field is especially useful because it makes the data origin explicit. In this example, the results come from OpenStreetMap, with attribution and license information included in the response.

The raw.osm_id and raw.osm_type values allow you to link back to the original OpenStreetMap object — for example: view this place in OpenStreetMap >>

Pros

Open data (OpenStreetMap-based) — transparent data source that allows you to cache, store, and redistribute data, depending on the OpenStreetMap license terms
Affordable pricing model — as a service provider (not a data owner), Geoapify offers more cost-efficient and predictable pricing
Simple and intuitive API — uses GET requests with clear query parameters, making it easy to test and integrate
Flexible usage — not tightly coupled to a specific platform, allowing more freedom in how data is stored and displayed
GeoJSON-like response format — ready to use directly in mapping libraries without transformation

Cons

No built-in reviews or ratings — unlike Google, the API does not provide user-generated reviews, ratings, or photos
Data completeness varies — coverage and quality depend on OpenStreetMap data in the region
Less enriched data — fewer high-level attributes compared to Google’s dataset
May require additional data sources — some features (e.g. reviews or popularity) may require integration with other APIs

Foursquare — Places API

📘 Docs · 💰 Pricing · ⚖️ Terms

Foursquare Places API provides access to a global POI dataset enriched with location intelligence and user behavior signals.

It is known for its structured place data and strong categorization system, making it well-suited for search and discovery use cases.

curl --request GET \
     --url 'https://api.foursquare.com/v3/places/search?ll=25.777415%2C-80.132432&radius=1000&categories=restaurants' \
     --header 'X-Places-Api-Version: 2023-10-01' \
     --header 'accept: application/json'

This request searches for restaurants near the given coordinates in Miami Beach within a 1 km radius.

Foursquare uses category IDs instead of text-based categories, which allows precise filtering but requires referencing their category taxonomy.

Example response

{
  "results": [
    {
      "fsq_id": "5f8a9c1b2d_example",
      "name": "Ocean Breeze Grill",
      "location": {
        "formatted_address": "200 Ocean Dr, Miami Beach, FL 33139",
        "locality": "Miami Beach",
        "region": "FL",
        "country": "US"
      },
      "geocodes": {
        "main": {
          "latitude": 25.778245,
          "longitude": -80.130912
        }
      },
      "categories": [
        {
          "id": 13065,
          "name": "Restaurant",
          "short_name": "Restaurant"
        }
      ],
      "distance": 180,
      "rating": 4.3,
      "price": 2,
      "tel": "+1 305-555-0199",
      "website": "https://oceanbreeze.example.com",

      "hours": {
        "display": "Mon–Sun 11:00 AM – 11:00 PM",
        "open_now": true
      },

      "features": {
        "services": {
          "delivery": true,
          "takeout": true,
          "dine_in": {
            "reservations": true
          }
        },
        "food_and_drink": {
          "meals": {
            "lunch": true,
            "dinner": true
          },
          "alcohol": {
            "beer": true,
            "wine": true
          }
        },
        "amenities": {
          "outdoor_seating": true,
          "wifi": "free"
        }
      },

      "photos": [
        {
          "id": "photo_001",
          "prefix": "https://fastly.4sqi.net/img/general/",
          "suffix": "/12345_sample.jpg",
          "width": 800,
          "height": 600
        }
      ],

      "tips": [
        {
          "id": "tip_001",
          "text": "Great seafood and ocean views. Try the grilled snapper!",
          "agree_count": 12
        }
      ],

      "stats": {
        "total_ratings": 540,
        "total_photos": 120,
        "total_tips": 34
      },

      "popularity": 0.82,
      "verified": true
    }
  ],
  "context": {
    "geo_bounds": {
      "circle": {
        "center": {
          "latitude": 25.777415,
          "longitude": -80.132432
        },
        "radius": 1000
      }
    }
  }
}

The response includes core place information such as name, location, categories, and distance. Depending on the endpoint and plan, Foursquare can also provide additional enrichment such as ratings, popularity signals, and place attributes.

Pros

Rich and structured place data — includes categories, attributes, popularity signals, and user-generated content
Includes user-generated content — provides photos and tips, adding useful context to places, though the coverage and depth may vary compared to larger platforms like Google Maps Platform
Strong categorization system — enables precise filtering using a well-defined taxonomy (category IDs)
High-quality curated dataset — especially strong in urban areas and commercial locations
Enriched data signals — provides popularity, trends, and behavioral insights beyond basic POI data

Cons

Strict licensing restrictions — data is provided under a limited, revocable license and must be used only within your application; you cannot store, merge, redistribute, or build your own POI dataset, and must display “Powered by Foursquare” attribution
Limited external usage — reports or demos must be non-monetized, non-competitive, and cannot expose material portions of data
Category-based filtering complexity — requires working with category IDs instead of simple text queries
Pricing scales with usage — costs can increase with request volume and data enrichment

HERE Technologies — Places API

📘 Docs · 🔎 Playground · 💰 Pricing · ⚖️ Terms

HERE Technologies provides location services and POI data through its Discover endpoint, which allows searching for places by category, location, and filters.

It is widely used in navigation, mobility, and enterprise applications, especially where accurate geolocation is critical.

Example request

GET https://discover.search.hereapi.com/v1/discover?at=25.777415,-80.132432&q=restaurant&limit=10&apiKey=YOUR_API_KEY

This request searches for restaurants near the given coordinates in Miami Beach.

Example response

{
  "items": [
    {
      "id": "here-poi-001",
      "title": "Ocean Breeze Restaurant",
      "resultType": "place",

      "address": {
        "label": "150 Ocean Dr, Miami Beach, FL 33139, United States",
        "countryCode": "USA",
        "countryName": "United States",
        "stateCode": "FL",
        "state": "Florida",
        "city": "Miami Beach",
        "street": "Ocean Dr",
        "postalCode": "33139",
        "houseNumber": "150"
      },

      "position": {
        "lat": 25.778215,
        "lng": -80.131102
      },

      "distance": 210,

      "categories": [
        {
          "id": "100-1000-0000",
          "name": "Restaurant",
          "primary": true
        }
      ],

      "foodTypes": [
        {
          "id": "101-000",
          "name": "Seafood",
          "primary": true
        }
      ],

      "contacts": [
        {
          "phone": [
            {
              "value": "+1 305-555-0188"
            }
          ],
          "www": [
            {
              "value": "https://oceanbreeze.example.com"
            }
          ]
        }
      ],

      "openingHours": [
        {
          "text": [
            "Mon–Sun: 11:00 AM – 11:00 PM"
          ],
          "isOpen": true
        }
      ],

      "timeZone": {
        "name": "America/New_York",
        "utcOffset": "-04:00"
      },

      "chains": [
        {
          "id": "chain-001",
          "name": "Ocean Breeze Group"
        }
      ],

      "media": {
        "images": {
          "items": [
            {
              "href": "https://images.example.com/photo1.jpg",
              "supplier": {
                "id": "tripadvisor"
              }
            }
          ]
        },
        "ratings": {
          "items": [
            {
              "count": 320,
              "average": 4.2,
              "supplier": {
                "id": "tripadvisor"
              }
            }
          ]
        }
      }
    }
  ],
  "count": 1,
  "limit": 10,
  "offset": 0
}

The HERE API returns structured place data with a strong focus on address details, categories, and consistency across regions.

Depending on the available data, the response may include:

Contact details such as phone numbers and websites
Opening hours in both structured and human-readable formats
Categories and food types for classification
Media and ratings, often sourced from third-party providers (for example, TripAdvisor)
Extended attributes such as EV charging stations, fuel information, or logistics-related data

Compared to consumer-focused APIs, HERE emphasizes reliable, standardized data and global coverage rather than building its own user-generated content ecosystem.

Pros

Reliable global coverage — strong presence across multiple regions and industries, including automotive and logistics
Structured and consistent data — predictable response format with detailed address components and classification
Simple request model — supports text-based and location-based search without complex request bodies
Enterprise-focused features — includes extended attributes such as EV stations, fuel data, and logistics-related information
Third-party enrichment — may include ratings and media from external providers (for example, TripAdvisor)

Cons

Proprietary dataset — data is not open and cannot be freely stored, reused, or redistributed
Limited user-generated content — generally does not provide native reviews or rich photo ecosystems like larger consumer platforms
Licensing restrictions — usage is governed by HERE terms, including limitations on storage, redistribution, and usage scope
Pricing scales with usage — costs depend on request volume and service usage

TomTom — Places API

📘 Docs · 🔎 Playground · 💰 Pricing · ⚖️ Terms

TomTom provides access to place data through its Search and Places APIs, allowing developers to search for POIs by category, name, or geographic location.

It is widely used in navigation, mobility, and enterprise applications, with a focus on accurate geolocation and global coverage.

Example request

curl -X GET "https://api.tomtom.com/search/2/categorySearch/restaurants.json?lat=25.777415&lon=-80.132432&radius=1000&categorySet=7315&view=Unified&relatedPois=off&key=YOUR_API_KEY" \
  -H "accept: */*"

This request searches for restaurants within a 1 km radius around Miami Beach and returns categorized place results using TomTom’s Places API.

Example response

{
  "summary": {
    "query": "restaurants",
    "queryType": "NON_NEAR",
    "numResults": 10,
    "offset": 0,
    "totalResults": 84,
    "geoBias": {
      "lat": 25.777415,
      "lon": -80.132432
    }
  },
  "results": [
    {
      "type": "POI",
      "id": "tomtom-poi-001",
      "score": 2.57,
      "dist": 145.3,
      "poi": {
        "name": "Ocean Breeze Cafe",
        "phone": "+1 305-555-0181",
        "url": "www.oceanbreeze.example.com",
        "categorySet": [
          {
            "id": 7315
          }
        ],
        "categories": [
          "restaurant"
        ],
        "classifications": [
          {
            "code": "RESTAURANT",
            "names": [
              {
                "nameLocale": "en-US",
                "name": "restaurant"
              }
            ]
          }
        ]
      },
      "address": {
        "streetNumber": "120",
        "streetName": "Ocean Dr",
        "municipality": "Miami Beach",
        "countrySubdivision": "FL",
        "postalCode": "33139",
        "countryCode": "US",
        "country": "United States",
        "freeformAddress": "120 Ocean Dr, Miami Beach, FL 33139"
      },
      "position": {
        "lat": 25.778201,
        "lon": -80.131502
      },
      "entryPoints": [
        {
          "type": "main",
          "position": {
            "lat": 25.77812,
            "lon": -80.13144
          }
        }
      ]
    },
    {
      "type": "POI",
      "id": "tomtom-poi-002",
      "score": 2.56,
      "dist": 210.8,
      "poi": {
        "name": "Seaside Grill",
        "categorySet": [
          {
            "id": 7315
          }
        ],
        "categories": [
          "restaurant"
        ]
      },
      "address": {
        "freeformAddress": "200 Collins Ave, Miami Beach, FL 33139"
      },
      "position": {
        "lat": 25.77901,
        "lon": -80.13088
      }
    }
  ]
}

The response includes a summary section plus a list of matching POIs. For each result, TomTom returns core place information such as the place name, categories, address, coordinates, and distance. Some results may also include contact details like a phone number or website.

A useful detail is the entryPoints field, which can help in routing and navigation scenarios by showing where the place can actually be accessed.

Pros

Reliable global location data — strong coverage optimized for navigation and mobility use cases
Well integrated with routing services — works seamlessly with routing, traffic, and navigation APIs
Simple and developer-friendly API — clear parameters and predictable responses
Accurate positioning data — includes fields like entryPoints for real-world navigation

Cons

Limited focus on user-generated content — minimal support for reviews or community-driven insights
Limited media support — photos and rich media are not part of standard responses
Proprietary dataset — data cannot be freely stored or redistributed
Licensing restrictions — usage is constrained by TomTom terms and conditions

What to choose?

Choosing a Places API depends not only on features, but also on your use case, constraints, and budget. Here’s a practical way to approach it.

1. Define your goal

Start with what you actually need to build:

Rich place details (reviews, photos, popularity signals) → Best fit: Google Maps Platform, Foursquare, HERE
Category-based search with structured place data (no need for reviews) → Best fit: Geoapify, TomTom, HERE
Navigation, routing, fleet, or logistics applications

→ Best fit: TomTom, HERE, Geoapify

👉 If your app relies on user-generated content, your main options are Google or Foursquare.

2. Consider your budget early

Pricing models differ significantly:

Google Maps Platform → powerful but can scale in cost quickly
Foursquare → commercial dataset with flexible plans
HERE / TomTom → enterprise-oriented pricing, often bundled with other services
Geoapify → affordable and predictable pricing

👉 Always estimate usage before building — especially for high-traffic apps.

3. Check licensing and data restrictions

This is often a deciding factor:

Some providers restrict storing or caching data (e.g., Google)
Some allow more flexibility with usage and storage
Most require attribution

👉 If you need to store or reuse data, this can narrow your options quickly.

4. Match provider strengths

Each provider is optimized for different scenarios:

Google / Foursquare → rich place content and discovery
HERE / TomTom → navigation, routing, and enterprise mobility
Geoapify → flexible APIs with open-data foundation, providing access to OpenStreetMap (OSM) data

👉 Example:

Building a city discovery app → Foursquare or Geoapify
Building a delivery platform → HERE or TomTom
Building an infrastructure or utility app (electricity, supply, field services) → Geoapify, TomTom, or HERE

5. Think long-term

Switching providers later can be costly.

Consider:

scaling costs
API limits
vendor lock-in
data portability

Summary

There is no single “best” API — only the best fit for your case.

Choose Google or Foursquare for rich place content
Choose HERE or TomTom for routing and mobility
Choose Geoapify for flexibility, open data, and cost efficiency

👉 The right choice comes down to balancing features, budget, and licensing constraints.

Got coordinates but need a city or ZIP code? This guide shows how to convert lat/lon into address data using reverse geocoding — with real examples, API calls, and a live demo.

Alfiya Tarasenko — Tue, 31 Mar 2026 11:47:09 +0000

Alfiya Tarasenko for Geoapify Maps API

Mar 31

How to Get City, Postal Code, Address from Latitude and Longitude

#webdev #codenewbie #programming #javascript

Comments

7 min read

How to Get City, Postal Code, Address from Latitude and Longitude

Alfiya Tarasenko — Tue, 31 Mar 2026 11:45:23 +0000

In many applications, you don’t start with an address — you start with coordinates.

A user clicks on a map, shares their GPS location, or your system receives latitude and longitude from a device. But raw coordinates like 40.748817, -73.985428 aren’t very useful on their own. Most applications need human-readable data: a city name, a postal code, or a full address.

This is where reverse geocoding comes in.

In this article, we’ll look at how to convert latitude and longitude into structured address data — including city, postal code, and formatted address — and, more importantly, what developers should be aware of when working with real-world location data.

To make things more practical, we’ll also use a simple interactive demo where you can click on a map and instantly get the corresponding address details:

CodePen Live Demo

Coordinates vs Address: Two Ways to Describe a Location

Latitude and longitude coordinates describe an exact point on Earth using a global grid system.

latitude defines how far north or south a location is
longitude defines how far east or west it is

Together, they pinpoint a precise location anywhere on the planet:

For example, the coordinates 40.748817, -73.985428 represent a specific point in New York.

However, while coordinates are extremely precise, they are not very intuitive for humans. People naturally think of locations in terms of:

cities
streets
postal codes
full addresses

This creates a gap between how machines represent locations and how humans understand them.

So how do you convert coordinates into a readable address?

To do that, you need a process that maps latitude and longitude to real-world location data — such as city names and postal codes. This process is called reverse geocoding.

Reverse Geocoding: Convert Coordinates to City, Postal Code, and Address

Reverse geocoding is the process of converting geographic coordinates (latitude and longitude) into a human-readable address.

In practice, reverse geocoding is not something you implement locally. It requires access to large, constantly updated geographic datasets that map coordinates to real-world address data — including administrative boundaries, streets, buildings, and postal codes.

Because of this, reverse geocoding is typically provided as a service via APIs.

One example is the Geoapify Reverse Geocoding API, which allows you to send coordinates and receive structured address data in response.

Here is an example API Request:

https://api.geoapify.com/v1/geocode/reverse?lat=40.748817&lon=-73.985428&format=json&apiKey=YOUR_API_KEY

The response contains structured fields such as:

city, town, village
postcode
street, housenumber
formatted (full address)

You can also control the level of detail using the type parameter, which helps filter results by address level (for example: city, postcode, street, etc.).

Getting city from coordinates

To get the city from coordinates, you can use reverse geocoding with the type=city parameter. This tells the API to return results at the city level.

For example:

https://api.geoapify.com/v1/geocode/reverse?lat=40.719726903683636&lon=-74.04103305850015&format=json&type=city&apiKey=YOUR_API_KEY

A typical response looks like this:

{
  "results": [
    {
      "country": "United States",
      "state": "New Jersey",
      "city": "Jersey City",
      "lon": -74.047455,
      "lat": 40.7215682,
      "result_type": "city",
      "formatted": "Jersey City, NJ, United States of America",
      "address_line1": "Jersey City, NJ",
      "address_line2": "United States of America",
      ...
    }
  ]
}

Using type=city ensures that the response focuses on the city-level administrative area, rather than returning street-level or building-level details.

Getting postcode (ZIP code) from coordinates

To get the postal code from coordinates, you can use reverse geocoding with the type=postcode parameter. This ensures the API returns results at the postcode level.

For example:

https://api.geoapify.com/v1/geocode/reverse?lat=40.739501996228256&lon=-74.18542863164123&type=postcode&format=json&apiKey=YOUR_API_KEY

A typical response looks like this:

{
  "results": [
    {
      "country": "United States",
      "state": "New Jersey",
      "city": "Newark",
      "postcode": "07103",
      "result_type": "postcode",
      "formatted": "Newark, NJ 07103, United States of America",
      "address_line1": "Newark, NJ 07103",
      "address_line2": "United States of America"
    }
  ]
}

The key field here is:

postcode — contains the postal (ZIP) code for the given coordinates

Additional useful fields include:

city — the associated city
formatted — full human-readable address

Using type=postcode ensures that the response focuses specifically on postcode-level data.

Keep in mind that:

not all locations have postal codes
postal codes may represent areas rather than exact points
formats vary depending on the country

Getting address from coordinates

To get a full address from coordinates, you can use reverse geocoding without specifying a type, which returns the most relevant place for the given location (for example, a building, POI, or street address).

For example:

https://api.geoapify.com/v1/geocode/reverse?lat=40.68818115914695&lon=-73.99558678565592&format=json&apiKey=YOUR_API_KEY

A typical response looks like this:

{
  "results": [
    {
      "name": "Citi Bike - Congress St & Clinton St",
      "housenumber": "183",
      "street": "Congress Street",
      "city": "New York",
      "postcode": "11201",
      "state": "New York",
      "country": "United States",
      "result_type": "amenity",
      "formatted": "Citi Bike - Congress St & Clinton St, 183 Congress Street, New York, NY 11201, United States of America",
      "address_line1": "Citi Bike - Congress St & Clinton St",
      "address_line2": "183 Congress Street, New York, NY 11201, United States of America"
    }
  ]
}

The most useful field for display is:

formatted — a ready-to-use human-readable address

You can also access individual components such as:

name — place or POI name (if available)
housenumber and street
city, postcode, state, country

By default, reverse geocoding returns the most relevant result for the given coordinates, which may be a specific place (like a business or landmark), not just a street or city.

Common Pitfalls When Converting Coordinates to Address

Reverse geocoding is powerful, but working with real-world location data comes with a few important caveats.

Understanding these will help you avoid common mistakes and build more reliable applications.

City is not always available

Not every location has a city field. Depending on where the coordinates point, the response may include:

city
town
village
or no settlement at all

To handle this correctly, always implement a fallback strategy instead of relying on a single field.

The result depends on the exact point

Small changes in coordinates can lead to different results.

For example, clicking on:

a building → returns a specific address
a road → returns street-level data
a park → may return only city or district

This is expected behavior, not an error.

The closest result may not match expectations

Reverse geocoding returns the nearest known object.

This could be:

a building
a business (POI)
a street
an administrative area

If you need a specific level (e.g., city or postcode), use the type parameter to control the result.

Coordinates may need normalization

Coordinates should always be valid:

latitude must be between -90 and 90
longitude must be between -180 and 180

Try It Yourself: Interactive Reverse Geocoding Demo

To better understand how reverse geocoding works in practice, try this interactive demo:

Live Demo on CodePen

The demo also shows how different clicks can return different types of results depending on the location — for example, a building, a street, or an administrative area.

Summary

Converting latitude and longitude into a city, postal code, or full address is a common requirement in many applications — from delivery services to map-based interfaces.

In this article, we explored how reverse geocoding works and how to use it to extract meaningful location data from coordinates.

Key takeaways:

coordinates describe precise locations, but are not human-friendly
reverse geocoding bridges the gap between coordinates and real-world addresses
you can extract specific data like city and postcode using the type parameter
not all locations have complete address data, so fallback logic is important
results may vary depending on the exact coordinates and context

By understanding these concepts and handling edge cases properly, you can build reliable features that convert coordinates into usable address information.

Additional Resources

FAQ

Is reverse geocoding free?

Most reverse geocoding services offer a free tier with usage limits.

For example, Geoapify provides a free plan with 3000 requests per day and 5RPS. This is usually enough for testing and small applications. For production use or higher volumes, paid plans are available.

How do I get an API key?

To use a reverse geocoding service like Geoapify, you need an API key.

You can get one by registering at the website.

After creating a project, you’ll receive an API key that you can use in your requests.

How do I get the timezone from coordinates?

Reverse geocoding responses often include timezone information.

For example, Geoapify returns a timezone object with:

{
  "name": "America/New_York",
  "offset_STD": "-05:00",
  "offset_STD_seconds": -18000,
  "offset_DST": "-04:00",
  "offset_DST_seconds": -14400,
  "abbreviation_STD": "EST",
  "abbreviation_DST": "EDT"
}

You can extract this directly from the response without making a separate API call.

How do I get the state or region?

To get the state or region from coordinates, you can use reverse geocoding with the type=state parameter. This ensures the API returns results at the state level.

How can I understand the quality of the result?

You can estimate how accurate the result is using the distance field.

distance represents how far (in meters) the returned result is from the input coordinates
smaller values indicate higher accuracy

For example:

0–10 meters → very precise (building-level)
10–100 meters → good accuracy
100+ meters → approximate result

Why do I sometimes get a place (POI) instead of an address?

By default, reverse geocoding returns the most relevant nearby object.

This could be:

a business or landmark (POI)
a building
a street
an administrative area

If you need a specific level (e.g., city or postcode), use the type parameter to control the result.

Can I use reverse geocoding offline?

In most cases, no.

Reverse geocoding requires large and frequently updated datasets, making it impractical to run locally. That’s why it is typically provided as an online API service.

What happens if there are no results?

In some cases, reverse geocoding may return no results:

remote areas
oceans or lakes
incomplete data coverage

Your application should handle this gracefully and provide fallback behavior.

Loading hundreds of places on a map? Learn how to make it fast and smooth! This tutorial shows how to use the Geoapify Places API with Leaflet, split map areas into chunks, and apply rate limiting for better performance and UX.

Alfiya Tarasenko — Fri, 07 Nov 2025 14:19:03 +0000

Alfiya Tarasenko for Geoapify Maps API

Nov 7 '25

Handle Large Place Searches: Chunked and Rate-Limited Search in Leaflet

#webdev #leaflet #api #javascript

Comments

6 min read

Handle Large Place Searches: Chunked and Rate-Limited Search in Leaflet

Alfiya Tarasenko — Fri, 07 Nov 2025 14:18:23 +0000

In the previous tutorial, we used the Geoapify Places API and Leaflet to display nearby places — like parks, museums, and cinemas — on a map.

That simple approach works well for small areas, but loading hundreds of places at once can slow the map or exceed API rate limits.

In this part, you’ll learn how to make place searches more efficient by:

Splitting the map area into chunks for smaller, faster requests
Applying rate limiting to control request flow
Rendering results progressively for smoother UX

Try the full example:
➡️ View on CodePen

Sure! Here’s a clean, Dev.to–ready Table of Contents for your article.
It matches your section headings exactly and uses the same anchor style Dev.to automatically generates.

🧭 Table of Contents

Introduction
Why large place searches can be slow
A better approach
Split the map bounds into smaller fragments
Run fragment requests with rate limiting
See the full implementation
Summary

Why large place searches can be slow

When your map covers a large area — for example, an entire city — the Geoapify Places API may need to process thousands of locations at once.
If you request all of them in a single query:

The API call can take longer to complete.
The response size becomes large, increasing data transfer time.
The map may freeze while parsing or rendering the results.
Users experience visible lag or delayed updates.
It might even require querying multiple pages of results to retrieve all places in that area.

A better approach

To keep your app fast and user-friendly, it’s better to:

Split the map area into smaller parts (chunks)

Each chunk is a smaller rectangle inside the visible map bounds.
The app sends several lightweight queries instead of one large request.
Results load progressively — users start seeing places immediately while others continue loading in the background.

Description: A map view divided into several rectangles, each labeled “API request,” showing places being loaded one fragment at a time. Arrows can indicate parallel or sequential loading.

Apply rate limiting

When you send multiple requests in parallel — for example, one per map fragment — it’s important to control how often they are executed.

Without rate limiting, dozens of simultaneous API calls can overload the network or exceed the API’s allowed request rate, leading to HTTP 429 (Too Many Requests) errors.

The Geoapify Request Rate Limiter automatically spaces out requests over time.
It ensures you stay within the API’s limits, keeps the map responsive, and provides a smooth, continuous loading experience for users.

Description: If rate limits are not respected, some API requests return 429 (Too Many Requests) errors.
In this example, the API allows 5 requests per second, but 9 are sent simultaneously — so 4 fail. The map shows those failed fragments highlighted in red.

Now that we understand why large queries can cause slow responses or 429 errors, let’s look at how to split the visible map area into smaller fragments.

Split the map bounds into smaller fragments

To make large-area searches more efficient, we’ll divide the visible map area into several smaller rectangles, called fragments.

For example, the following helper function decides how many pieces the map should be split into depending on the zoom level (fewer at high zoom, more at low zoom):

function getAxisChunksForZoom(zoom) {
  const z = Math.floor(zoom);
  const delta = Math.max(0, 17 - z);
  if (delta === 0) return 1;        // At zoom ≥ 16, one request is enough
  return delta;   // At lower zooms, split the area into more parts
}

The function takes the current map zoom level as input.
When you’re zoomed in close (zoom ≥ 16), the visible area is small, so only one fragment (one request) is needed.
As you zoom out, the visible area grows. The function increases the number of fragments exponentially — for example:
- At zoom 15 → 2 x 2 fragments per axis
- At zoom 14 → 3 x 3 fragments
- At zoom 13 → 4 x 4 fragments
This ensures that large views (like an entire city) are split into multiple smaller bounding boxes, each of which can be queried quickly and displayed independently.

Next, we’ll use this helper to actually divide the map bounds into fragments — small rectangular areas that together cover the visible region.

The following function, getFragments(bounds, zoom), takes the current map bounds and zoom level, then returns an array of rectangles. Each rectangle defines a mini viewbox that we’ll later use to query the Geoapify Places API:

function getFragments(bounds, zoom) {
  if (!bounds) return [];

  const chunks = getAxisChunksForZoom(zoom);
  const sw = bounds.getSouthWest();
  const ne = bounds.getNorthEast();

  // If only one chunk, return the full map bounds
  if (chunks <= 1) {
    return [{ minLng: sw.lng, minLat: sw.lat, maxLng: ne.lng, maxLat: ne.lat }];
  }

  const latStep = (ne.lat - sw.lat) / chunks;
  const lngStep = (ne.lng - sw.lng) / chunks;
  const rects = [];

  // Loop through rows and columns to build smaller rectangles
  for (let row = 0; row < chunks; row += 1) {
    const minLat = sw.lat + row * latStep;
    const maxLat = row === chunks - 1 ? ne.lat : minLat + latStep;

    for (let col = 0; col < chunks; col += 1) {
      const minLng = sw.lng + col * lngStep;
      const maxLng = col === chunks - 1 ? ne.lng : minLng + lngStep;
      rects.push({ minLng, minLat, maxLng, maxLat });
    }
  }

  return rects;
}

What this does

Calculates how many pieces (chunks) the area should be split into based on zoom level.
Divides the visible map into a grid of rectangles, using latitude and longitude steps.
Returns an array of bounding boxes — each one ready to be used in a request like:

  filter=rect:minLon,minLat,maxLon,maxLat

As a result, instead of sending one large, heavy API query, we can make multiple smaller requests — one per fragment — and load results progressively and smoothly.

Run fragment requests with rate limiting

Now that we can split the view into fragments and build one request per fragment, let’s execute them safely.
We’ll use [@geoapify/request-rate-limiter](https://www.npmjs.com/package/@geoapify/request-rate-limiter) to pace requests so the UI stays smooth and we avoid bursts.

// Build one async function per fragment (from previous step)
const requestFns = fragments.map(({ minLng, minLat, maxLng, maxLat }) => {
  const rect = `${minLng},${minLat},${maxLng},${maxLat}`;
  const url = `https://api.geoapify.com/v2/places?categories=${encodeURIComponent(categories)}&filter=rect:${rect}&limit=200&apiKey=${yourAPIKey}`;

  return async () => {
    const resp = await fetch(url);
    if (!resp.ok) throw new Error(`HTTP ${resp.status}`);
    const data = await resp.json();
    renderResults(data); // progressive rendering: draw as each fragment returns
    return data;
  };
});

// Run with rate limiting: 5 requests per 1000 ms window
const results = await RequestRateLimiter.rateLimitedRequests(
  requestFns,
  5,          // max requests per window
  1000,       // window duration (ms)
  {
    onProgress: ({ completedRequests, totalRequests }) => {
      // optional: update a small status label
      // e.g., setStatus(`Loaded ${completedRequests}/${totalRequests} fragments…`);
    }
  }
);

Paces outgoing requests to avoid spikes and keep the app responsive.
Renders progressively: users see places appear fragment-by-fragment, not all at once.
Keeps your code simple: pass an array of tasks and let the limiter schedule them.

See the full implementation

You can explore the complete working version in the CodePen example:
➡️ View on CodePen

The code sample demonstrates everything described in this tutorial — including:

Rate-limited API requests to keep the app smooth and avoid 429 errors
Canceling outdated searches when the user moves or zooms the map again
Progressive visualization of results as each fragment loads

Together, these techniques make large place searches fast, stable, and user-friendly — even when displaying thousands of points across a wide area.

Summary

In this tutorial, we improved the performance of large-area searches in Leaflet using the Geoapify Places API.

You learned how to:

Split the visible map area into smaller fragments for faster, lighter API calls
Apply rate limiting with the Geoapify Request Rate Limiter to avoid 429 errors
Load and render places progressively for a smoother, more responsive user experience

You can see the complete implementation — including canceling outdated searches and visualizing data — in the live CodePen example:
➡️ View the complete example

[Boost]

Alfiya Tarasenko — Wed, 05 Nov 2025 14:31:05 +0000

How to Query and Display Nearby Places on a Leaflet Map with the Geoapify Places API

Alfiya Tarasenko for Geoapify Maps API ・ Nov 5

#codepen #leaflet #webdev #geoapify