DEV Community: Luo Atlas

How to Check and Fix Your Windows Clock: A Step-by-Step Guide

Luo Atlas — Sun, 11 Oct 2026 01:58:03 +0000

Is your computer clock running fast or slow? You can check its estimated error in a browser, let Windows correct it, and check again. No coding is needed.

I build CoordMap, and this guide uses its device-time check.

1. Open the clock checker

Open CoordMap’s Eastern Time page. Below the large clock, find Current device time and click Calibrate device time. Wait for the check to finish.

The large clock shows Eastern Time. You do not need to live in that time zone or change your computer to it. Use the device-error result below the clock to check accuracy.

2. Read the result

The result tells you which way your clock is off:

Result	Meaning
Your device is … ms fast	Your computer clock is ahead of the reference time.
Your device is … ms slow	Your computer clock is behind the reference time.

1,000 ms = 1 second. For example, 50 ms fast means the clock is estimated to be 0.05 seconds ahead. It does not need a manual adjustment for everyday use.

If your clock is noticeably wrong, use Windows synchronization rather than trying to type in the exact time.

3. Correct the clock in Windows

Press Win + I, then open Time & language → Date & time.

Turn Set time automatically on.
Check Time zone. Keep it set to your actual location. If automatic time-zone detection is wrong, turn it off and select your local zone manually.
Find Synchronize your clock and click Sync now. Stay connected to the internet and wait for synchronization to succeed.

4. Check again

Return to the CoordMap tab, refresh the page, and click Calibrate device time again. Compare the new result with the previous one. You can repeat the check a couple of times if the readings vary.

You are checking whether the estimated error has reduced; you do not need an exact 0 ms result. The website reports a reference estimate, and network conditions can affect it. Its calibration button checks the clock; Windows performs the actual system-time correction.

If Windows reports that synchronization failed, check your internet connection and retry. For a work-managed computer or disabled controls, contact your administrator.

Off by whole hours? Recheck your local time zone first. Eastern Time and your local time can legitimately show different hours.

How to Get Your Current Location with JavaScript

Luo Atlas — Sun, 11 Oct 2026 01:32:40 +0000

A “Use my location” button can save someone from typing an address, searching for a place, or copying coordinates from another app.

For a map application, it is also a useful starting point: get the user's latitude and longitude, then use those coordinates to show a marker, look up an address, or search for nearby places.

In this tutorial, we will build a small browser example that requests location after a button click, displays the result, handles common errors, and creates a link to open the coordinates in Google Maps.

Start with the browser's Geolocation API

The Geolocation API is available through navigator.geolocation. For a single location request, use getCurrentPosition().

It accepts a success callback, an error callback, and an optional configuration object:

navigator.geolocation.getCurrentPosition(
  (position) => {
    const { latitude, longitude } = position.coords;
    console.log({ latitude, longitude });
  },
  (error) => {
    console.error(error.code, error.message);
  },
  {
    enableHighAccuracy: true,
    timeout: 10000,
    maximumAge: 0,
  }
);

The call is asynchronous. The coordinates arrive in the success callback; they are not the method's return value.

For a deployed website, use HTTPS. The user must allow location access, and a site's Permissions Policy can also block the feature. Local development on http://localhost is generally treated as a potentially trustworthy origin.

Build a complete example

Save the following as index.html, then serve it through localhost or HTTPS.

The page requests location only when the user clicks the button. It disables the button while the request is pending and shows a readable message if the request fails.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Find My Current Coordinates</title>
</head>
<body>
  <main>
    <h1>Find My Current Coordinates</h1>
    <p>Allow location access to see your latitude and longitude.</p>

    <button id="locate" type="button">Use my location</button>
    <p id="status" role="status" aria-live="polite"></p>

    <section id="result" hidden>
      <h2>Your reported location</h2>
      <dl>
        <dt>Latitude</dt>
        <dd id="latitude"></dd>
        <dt>Longitude</dt>
        <dd id="longitude"></dd>
        <dt>Estimated accuracy radius</dt>
        <dd id="accuracy"></dd>
        <dt>Position timestamp</dt>
        <dd id="timestamp"></dd>
      </dl>
      <a id="map-link" target="_blank" rel="noopener noreferrer">
        Open in Google Maps
      </a>
    </section>
  </main>

  <script>
    const button = document.querySelector("#locate");
    const status = document.querySelector("#status");
    const result = document.querySelector("#result");
    const mapLink = document.querySelector("#map-link");

    const errorMessages = {
      1: "Location access was denied or blocked. Check site permissions, or enter coordinates manually.",
      2: "Your device could not determine a position. Check location services and try again.",
      3: "The location request timed out. Try again, or enter coordinates manually.",
    };

    button.addEventListener("click", () => {
      result.hidden = true;
      mapLink.removeAttribute("href");

      if (!window.isSecureContext) {
        status.textContent = "Open this page over HTTPS or on localhost.";
        return;
      }

      if (!navigator.geolocation) {
        status.textContent = "Geolocation is unavailable in this browser.";
        return;
      }

      button.disabled = true;
      status.textContent = "Requesting your location. Please respond to any permission prompt.";

      navigator.geolocation.getCurrentPosition(
        (position) => {
          const { latitude, longitude, accuracy } = position.coords;

          document.querySelector("#latitude").textContent = latitude.toFixed(6);
          document.querySelector("#longitude").textContent = longitude.toFixed(6);
          document.querySelector("#accuracy").textContent = `${Math.round(accuracy)} meters`;
          document.querySelector("#timestamp").textContent =
            new Date(position.timestamp).toLocaleString();

          const url = new URL("https://www.google.com/maps/search/");
          url.searchParams.set("api", "1");
          url.searchParams.set("query", `${latitude},${longitude}`);
          mapLink.href = url.toString();

          result.hidden = false;
          status.textContent = "Location received. Check the accuracy estimate before using it.";
          button.disabled = false;
        },
        (error) => {
          status.textContent =
            errorMessages[error.code] || "Unable to get your location. Please try again.";
          button.disabled = false;
        },
        {
          enableHighAccuracy: true,
          timeout: 10000,
          maximumAge: 0,
        }
      );
    });
  </script>
</body>
</html>

For example, if you have Python installed, start a local server from the folder containing the file:

python -m http.server 8000

Then open http://localhost:8000. Opening the file through a local server gives you a more predictable development setup than relying on file:// behavior.

This example displays the coordinates without uploading them to an application server. Clicking the Google Maps link sends the coordinates to Google Maps in the URL.

Choose options for your use case

The configuration above favors a fresh result and requests better accuracy. Those choices may be appropriate for placing someone on a map, but they are not the best settings for every feature.

Option	Example value	Purpose
`enableHighAccuracy`	`true`	Request better accuracy, potentially at the cost of more time and power
`timeout`	`10000`	Limit position acquisition time to 10 seconds
`maximumAge`	`0`	Require a fresh position rather than accepting a cached result

The acquisition timeout does not include time spent waiting for permission or for the document to become visible. A user who leaves the permission prompt unanswered can therefore wait longer than ten seconds.

For a nearby-city feature, consider allowing a recent cached position:

const options = {
  enableHighAccuracy: false,
  timeout: 10000,
  maximumAge: 60000,
};

That allows the browser to reuse a position up to one minute old. Pick the settings based on how current and precise the result needs to be.

See the getCurrentPosition documentation and W3C Geolocation specification for the option definitions.

Show accuracy alongside the coordinates

A coordinate pair can look precise even when the underlying position is uncertain.

For example, displaying six decimal places does not prove that the device knows its position to that level of accuracy. In our example, toFixed(6) controls the presentation only.

The accuracy property reports a horizontal accuracy estimate in meters, specified at a 95% confidence level.

A reported radius of 20 meters and a reported radius of 2,000 meters should lead to different interface decisions. With the larger radius, a map can show a broader area and let the user adjust the location.

Browser geolocation also does not guarantee a GPS reading. The device and browser choose the available positioning sources. Treat the result as a reported position with an accuracy estimate.

Put the location on a MapLibre map

If your application already has an initialized MapLibre GL JS map, you can add a marker from the success callback.

Assume maplibregl is available and map refers to your map instance. Declare the marker variable once, outside the callback:

let userMarker;

// Call this from the geolocation success callback.
function showUserLocation(position) {
  const { latitude, longitude } = position.coords;

  // MapLibre expects longitude first.
  const lngLat = [longitude, latitude];

  if (userMarker) {
    userMarker.setLngLat(lngLat);
  } else {
    userMarker = new maplibregl.Marker()
      .setLngLat(lngLat)
      .addTo(map);
  }

  map.setCenter(lngLat);
}

Updating the existing marker prevents repeated button clicks from creating duplicate markers.

Pay attention to coordinate order. The Google Maps search query in our HTML example uses latitude,longitude; MapLibre uses [longitude, latitude]. The MapLibre Marker documentation describes its setLngLat() method.

Handle errors as part of the interface

The GeolocationPositionError codes identify three common failure cases:

Code	Name	Useful response
`1`	`PERMISSION_DENIED`	Explain that access was denied or blocked; offer manual input
`2`	`POSITION_UNAVAILABLE`	Suggest checking device location services and trying again
`3`	`TIMEOUT`	Offer a retry and another way to choose a location

Permission denial does not always mean the user clicked “Block” just now. Access may already have been denied or prevented by a policy.

Avoid retrying automatically after denial. Leave the person in control and provide an alternative, such as address search, coordinate input, or selecting a point on the map.

Try the workflow in a map tool

I built CoordMap's My Location tool around this workflow: start with an approximate IP location, then let the user request device location with the Use Precise Location button.

You can view the coordinates, copy them, and open the location in Google Maps. The page also supports searching for a place or entering coordinates manually.

IP location and device location can differ. An IP result is an approximate starting point, and it should be labeled separately from a position reported by the browser.

Use the coordinates for the next step

Once you have latitude and longitude, decide what the person needs to do next.

An address lookup needs reverse geocoding. A nearby-place search needs a search radius. A map marker needs the coordinate order expected by the mapping library.

For a “Use my location” feature, a useful first version is small: an explicit button, a position with its accuracy estimate, a map action, and a clear alternative when location is unavailable.

How to Convert an Address to Latitude and Longitude with JavaScript

Luo Atlas — Tue, 06 Oct 2026 07:03:06 +0000

If you have a street address and need to place it on a map, calculate distances, find nearby places, or store its location in a database, you first need to convert that address into geographic coordinates.

This process is called geocoding.

For example:

1600 Amphitheatre Parkway, Mountain View, CA

might be converted into something like:

Latitude: 37.422
Longitude: -122.084

In this guide, we'll look at how address-to-coordinate conversion works and how to implement it with JavaScript.

What Is Geocoding?

Geocoding converts a human-readable location into latitude and longitude coordinates.

The input could be:

A complete street address
A city name
A postal code
A landmark
A place name

For example:

Times Square, New York

can be converted into coordinates that can then be displayed on a map.

The reverse process is called reverse geocoding:

Latitude + Longitude → Address

So the two operations are:

Address → Coordinates     = Geocoding
Coordinates → Address     = Reverse Geocoding

Basic JavaScript Example

Most geocoding services expose an HTTP API.

A simplified JavaScript request looks like this:

async function geocodeAddress(address) {
  const url =
    `https://nominatim.openstreetmap.org/search` +
    `?format=json&q=${encodeURIComponent(address)}`;

  const response = await fetch(url);
  const results = await response.json();

  if (!results.length) {
    throw new Error("Location not found");
  }

  return {
    latitude: parseFloat(results[0].lat),
    longitude: parseFloat(results[0].lon)
  };
}

Then call it like this:

geocodeAddress("Times Square, New York")
  .then(location => {
    console.log(location.latitude);
    console.log(location.longitude);
  })
  .catch(error => {
    console.error(error);
  });

The result will look similar to:

{
  latitude: 40.758,
  longitude: -73.9855
}

The exact coordinates may vary depending on the geocoding provider and which geographic feature it considers the best match.

Why `encodeURIComponent()` Matters

Addresses often contain spaces, commas, apartment numbers, accented characters, and other symbols.

For example:

10 Downing Street, London

should not simply be inserted into a URL without encoding.

Use:

encodeURIComponent(address)

which produces a URL-safe version of the input.

const address = "10 Downing Street, London";

const encoded = encodeURIComponent(address);

console.log(encoded);

Without proper encoding, some addresses may produce invalid requests or unexpected search results.

Building a Simple Address Search

You can connect the geocoding function to an HTML input.

<input
  id="address"
  type="text"
  placeholder="Enter an address"
/>

<button id="search">
  Find Coordinates
</button>

<div id="result"></div>

Then add JavaScript:

const input = document.getElementById("address");
const button = document.getElementById("search");
const result = document.getElementById("result");

button.addEventListener("click", async () => {
  const address = input.value.trim();

  if (!address) {
    result.textContent = "Please enter an address.";
    return;
  }

  try {
    const location = await geocodeAddress(address);

    result.innerHTML = `
      Latitude: ${location.latitude}<br>
      Longitude: ${location.longitude}
    `;
  } catch (error) {
    result.textContent = "Location not found.";
  }
});

Now a user can enter an address and receive its latitude and longitude directly in the browser.

Geocoding Results Are Often Ambiguous

One important detail is that an address does not always correspond to exactly one location.

Consider a search like:

Springfield

There are many places with that name.

A geocoding service may return several possible results.

Instead of always selecting the first result, you can display a list.

async function searchLocations(address) {
  const url =
    `https://nominatim.openstreetmap.org/search` +
    `?format=json&limit=5&q=${encodeURIComponent(address)}`;

  const response = await fetch(url);

  return response.json();
}

Then:

const locations = await searchLocations("Springfield");

locations.forEach(location => {
  console.log(
    location.display_name,
    location.lat,
    location.lon
  );
});

For a real search interface, letting users choose from several matching locations is often better than assuming the first result is correct.

Latitude and Longitude Order Can Be Confusing

This is one of the most common coordinate mistakes.

Many JavaScript mapping libraries use:

latitude, longitude

or:

lat, lng

But GeoJSON uses:

[longitude, latitude]

For example:

const latitude = 40.758;
const longitude = -73.9855;

A normal object might look like:

{
  lat: 40.758,
  lng: -73.9855
}

But a GeoJSON point is:

{
  type: "Point",
  coordinates: [-73.9855, 40.758]
}

Notice that the order is reversed.

Mixing these formats can place your marker thousands of kilometers away from where you expected.

Displaying the Result on a Map

If you're using MapLibre GL JS, the result can be used directly to position a marker.

For example:

const location = {
  latitude: 40.758,
  longitude: -73.9855
};

new maplibregl.Marker()
  .setLngLat([
    location.longitude,
    location.latitude
  ])
  .addTo(map);

You can also center the map on the location:

map.flyTo({
  center: [
    location.longitude,
    location.latitude
  ],
  zoom: 14
});

Again, notice that MapLibre expects:

[longitude, latitude]

rather than:

[latitude, longitude]

What If an Address Cannot Be Found?

Geocoding is not exact.

A request might fail because:

The address is misspelled
The building is new
The address database is incomplete
The user entered only part of the address
The place has several possible names
The postal address format is unusual
The location is in a poorly mapped region

Instead of treating an empty response as a fatal error, a better interface might ask the user to modify the search.

if (!results.length) {
  console.log(
    "No exact result found. Try adding a city, region, or country."
  );
}

For example, instead of:

Main Street 25

try:

25 Main Street, Boston, MA, USA

More geographic context usually produces better results.

Avoid Geocoding the Same Address Repeatedly

If your application frequently looks up the same addresses, you may not want to send a new API request every time.

A simple application could store previously resolved addresses:

const cache = new Map();

async function getCoordinates(address) {
  const key = address.trim().toLowerCase();

  if (cache.has(key)) {
    return cache.get(key);
  }

  const coordinates = await geocodeAddress(address);

  cache.set(key, coordinates);

  return coordinates;
}

For larger applications, results can be stored in a database instead.

Before caching geocoding data in production, check the terms of the geocoding provider you're using.

Browser or Server?

For a small experiment, calling a geocoding API directly from the browser is convenient.

For production applications, a backend endpoint is often better.

Instead of:

Browser → Geocoding Provider

you can use:

Browser
   ↓
Your Server
   ↓
Geocoding Provider

This gives you more control over:

API keys
Rate limiting
Caching
Logging
Error handling
Provider changes

It also prevents private API credentials from being exposed in client-side JavaScript.

Common Address-to-Coordinate Mistakes

When implementing geocoding, these problems appear frequently.

1. Assuming the first result is always correct

Generic place names can return multiple matches.

2. Swapping latitude and longitude

Some APIs and mapping formats use different coordinate orders.

3. Not encoding the address

Always encode user input before adding it to a query URL.

4. Expecting every address to exist

Geocoding databases are incomplete and constantly changing.

5. Exposing private API keys

If your provider requires a secret API key, geocoding requests may need to go through your backend.

6. Sending a request on every keystroke

If you're building address autocomplete, debounce requests instead of calling the API for every character.

For example:

let timer;

input.addEventListener("input", () => {
  clearTimeout(timer);

  timer = setTimeout(() => {
    console.log("Search:", input.value);
  }, 400);
});

This greatly reduces unnecessary requests.

Testing Coordinates Manually

When debugging geocoding, it is useful to inspect the result outside your application.

You can search for an address and verify its coordinates with an online coordinate lookup tool such as CoordMap:

https://www.coordmap.com/longitude-latitude-finder

This is especially helpful when you're trying to determine whether a problem comes from:

The address
The geocoding service
Coordinate order
Your map code
Marker placement

Final Thoughts

Converting an address to latitude and longitude is conceptually simple:

Address
   ↓
Geocoding API
   ↓
Latitude + Longitude
   ↓
Map / Database / Distance Calculation

But reliable geocoding requires more than sending an address to an API.

You also need to consider ambiguous locations, missing addresses, coordinate order, request limits, caching, and error handling.

Once you have valid coordinates, they become the starting point for many other geographic tasks: displaying markers, calculating distances, finding nearby places, reverse geocoding, or performing spatial searches.

And that is why, in most mapping applications, coordinates are usually the beginning rather than the final answer.

Why Is My Map Marker in the Wrong Place? 5 Coordinate Mistakes Developers Make

Luo Atlas — Sun, 27 Sep 2026 01:18:34 +0000

You have a latitude and longitude. You pass them to a map, add a marker, and zoom in. The marker appears on another continent, in the ocean, or a few streets away from where you expected.

The map may be rendering correctly. The problem is often in the coordinates you gave it—or in what you assumed those coordinates meant. Here are five checks I use when debugging a misplaced marker.

1. Latitude and longitude are in the wrong order

A browser's Geolocation API gives you named properties: latitude and longitude. MapLibre GL JS expects an array in longitude, latitude order. GeoJSON uses the same order.

navigator.geolocation.getCurrentPosition(({ coords }) => {
  const { latitude, longitude } = coords;

  // Wrong: [latitude, longitude]
  // marker.setLngLat([latitude, longitude]);

  // Correct: [longitude, latitude]
  marker.setLngLat([longitude, latitude]);
});

For New York, 40.7128, -74.0060 is a familiar latitude, longitude pair. A MapLibre array for that location is [-74.0060, 40.7128].

This bug can be hard to spot when both numbers fall within valid latitude and longitude ranges. The map may show a real location, just the wrong one.

Check: Find the coordinate order in the documentation for every API boundary. Don't infer it from the phrase “lat/lon” in a UI label.

2. The numbers belong to a different coordinate reference system

A pair of numbers is incomplete without its coordinate reference system (CRS). WGS84 longitude and latitude are expressed in degrees. Web Mercator coordinates, commonly associated with EPSG:3857, are expressed in projected units such as metres.

If a data source gives you Web Mercator x and y, you cannot pass them to a function that expects [longitude, latitude] in degrees and hope the map will work it out.

// Conceptual example: these are projected x/y values,
// not longitude and latitude in degrees.
const point = { x: -8238310, y: 4970072, crs: "EPSG:3857" };

// Wrong: marker.setLngLat([point.x, point.y]);
// First transform the point to geographic longitude/latitude
// using an appropriate CRS transformation library or service.

The same warning applies when combining GPS data with coordinates from a local or regional map system. Label the source CRS, transform where necessary, and only then display the result.

Check: Do you know the CRS and units of the input? Values in the millions are a strong clue that they are not ordinary longitude and latitude in degrees.

3. You treated a formatted coordinate as a decimal number

A coordinate such as 40°42'46.08"N is in degrees, minutes, and seconds (DMS). It represents about 40.7128°, not 40.424608° and not the JavaScript number 40.

For one component, the conversion is:

function dmsToDecimal(degrees, minutes, seconds, hemisphere) {
  const value = degrees + minutes / 60 + seconds / 3600;
  return hemisphere === "S" || hemisphere === "W" ? -value : value;
}

const latitude = dmsToDecimal(40, 42, 46.08, "N");
const longitude = dmsToDecimal(74, 0, 21.6, "W");

console.log([longitude, latitude]); // [-74.006, 40.7128]

The function above converts already parsed DMS parts; it is not a parser for arbitrary text. If users paste coordinates, parse the separators and hemisphere letters explicitly, then validate the result. parseFloat("40°42'46.08\"N") will silently return 40, which can be especially misleading.

DMS to decimal degrees is a format conversion. It does not transform coordinates between WGS84 and another CRS.

Check: Inspect the raw input string and the numeric value immediately before adding the marker.

4. A hemisphere or minus sign was lost

Latitude is positive north of the equator and negative south. Longitude is positive east of the prime meridian and negative west. If you drop the W from 74°W, your marker moves from the western hemisphere to the eastern one.

This often happens while cleaning form input or exporting CSV data:

const input = "74.0060 W";
const longitude = parseFloat(input); // 74.006: the W is ignored

A safe parser needs to apply the hemisphere sign deliberately. It should also reject contradictory inputs such as -74 W unless you define exactly how your app handles them.

Before rendering, validate the basic ranges:

function isValidLngLat(longitude, latitude) {
  return Number.isFinite(longitude) &&
    Number.isFinite(latitude) &&
    longitude >= -180 && longitude <= 180 &&
    latitude >= -90 && latitude <= 90;
}

Range checks catch impossible numbers. They cannot reliably detect reversed coordinates when both values are plausible.

Check: Preserve N/S/E/W or signed values throughout parsing, storage, and export. Test at least one western and one southern hemisphere location.

5. You expected an approximate location to be exact

Sometimes the marker is in the right general area but not at the user's actual position. That may be a data quality issue rather than a mapping bug.

Browser geolocation can use different sources, including GPS, Wi-Fi, and network information. Its result includes an accuracy value in metres. An IP-based location is typically an approximate area and should not be presented as an exact device position.

navigator.geolocation.getCurrentPosition(({ coords }) => {
  marker.setLngLat([coords.longitude, coords.latitude]);
  console.log(`Reported accuracy: ${coords.accuracy} metres`);
});

If your app falls back to IP location after permission is denied, label that fallback clearly. Zooming to street level does not make an approximate coordinate more accurate.

Check: Show the location source and reported accuracy when available. Debug the input's precision before adjusting marker code.

A quick debugging checklist

When a marker appears in the wrong place, log the coordinate at the point where it enters the app and again just before it reaches the map:

console.table({
  source: "browser geolocation", // or your actual data source
  crs: "WGS84",
  longitude,
  latitude,
  valid: isValidLngLat(longitude, latitude)
});

marker.setLngLat([longitude, latitude]);

Then ask:

Does this API want [longitude, latitude] or [latitude, longitude]?
What CRS and units did the source use?
Was a DMS string parsed into decimal degrees correctly?
Did any minus sign or hemisphere letter disappear?
Is the source location approximate?

If you are unsure which coordinate system your data uses, inspect a sample point before processing the full dataset. You can use CoordMap's coordinate converter to compare supported systems and check the result on a map.

The most useful habit is simple: carry order, format, CRS, and accuracy alongside the numbers. Two coordinates alone rarely tell the whole story.

Coordinates Are Usually the Beginning, Not the Answer

Luo Atlas — Mon, 21 Sep 2026 02:23:19 +0000

When people work with maps, latitude and longitude are often treated as the final result.

You search for a place, get a pair of coordinates, and the task seems complete.

But in practice, coordinates are rarely the final answer.

They are usually the beginning of another question.

You may want to know:

Where exactly is this point?
What is the address?
What is the elevation?
What time is it there?
Which time zone is it in?
When does the sun rise or set?
How far is it from another location?
How can I open it in Google Maps, Apple Maps, or OpenStreetMap?
How can I convert the coordinates into another format?

These questions are closely related.

Yet on the web, the tools used to answer them are often completely separate.

That fragmentation was the main problem I wanted to solve when I started building CoordMap.

The Problem Is Not a Lack of Map Tools

There are already many excellent mapping platforms.

Google Maps, Apple Maps, OpenStreetMap, GIS applications, geocoding services, and countless APIs can all solve parts of the problem.

The issue is different.

For many small geographic tasks, the workflow is unnecessarily fragmented.

Imagine someone receives this coordinate:

40.7128, -74.0060

They may first search for the location.

Then they open another website to check elevation.

Then another one to calculate distance.

Then another tool for coordinate conversion.

Then they search for the local time.

If they need sunrise and sunset information, that may require yet another service.

None of these tasks is especially complicated on its own.

The friction comes from having to repeatedly move the same location between unrelated tools.

That made me think about geographic utilities differently.

Instead of asking:

How can I build another map?

I started asking:

What usually happens after someone finds a coordinate?

That question became the foundation of the project.

Coordinates Should Be a Starting Point

A coordinate is a compact representation of a location.

But humans usually care about the meaning behind that location.

A pair of numbers such as:

51.5074, -0.1278

is technically useful.

But the useful questions around it are much richer:

Coordinates
    ↓
Location
    ↓
Address
    ↓
Elevation
    ↓
Time Zone
    ↓
Local Time
    ↓
Sunrise / Sunset
    ↓
Distance

Not every user needs every piece of information.

But these questions belong to the same context.

That led to one of the main ideas behind CoordMap:

Geographic tools should remain focused, but they should also understand that users often have a next question.

The goal is not to put everything into one giant interface.

The goal is to make related geographic tasks easier to continue.

Goal 1: One Page, One Clear Question

One of the earliest design decisions was to avoid building a huge map dashboard.

Large dashboards can look powerful, but they often make simple tasks harder.

If someone wants to find the elevation of a location, the page should answer:

What is the elevation here?

If someone wants to measure distance, the page should answer:

How far apart are these two points?

If someone wants their current coordinates, the page should answer:

Where am I?

This sounds obvious, but it affects almost every design decision.

Each tool should have a clear purpose.

The map supports the task.

It should not become the task itself.

This principle also helps reduce unnecessary interface complexity.

Instead of exposing every possible setting at once, a page can focus on the smallest useful workflow.

Goal 2: Connect Related Geographic Information

Keeping tools separate does not mean they need to be isolated.

For example, after finding a location, useful next actions might include:

checking elevation,
viewing local time,
calculating distance,
converting coordinate formats,
checking sunrise and sunset,
opening the point in another map service.

The challenge is to connect these actions without turning every page into a crowded control panel.

I think of this as a network of small tools rather than one large application.

Each page solves one problem.

But the data can naturally lead into another tool.

For example:

My Location
     ↓
Latitude / Longitude
     ↓
Elevation
     ↓
Local Time
     ↓
Sunrise / Sunset

The user should not have to re-enter the same information every time.

Goal 3: Make Geographic Data Understandable

Developers are comfortable working with raw values.

Users often are not.

Consider this:

Latitude: 34.052235
Longitude: -118.243683

The numbers are precise, but they do not immediately tell most people much.

Once additional context is added, the information becomes far more useful.

For example:

Location: Los Angeles, California
Coordinates: 34.052235, -118.243683
Elevation: ...
Time Zone: ...
Local Time: ...
Sunrise: ...
Sunset: ...

This changes the role of coordinates.

They stop being isolated technical values and become a key for retrieving information about a place.

That is one reason I do not see coordinate lookup as a single-purpose feature.

It is more like an entry point into geographic information.

Goal 4: Keep Common Tasks Browser-First

A large amount of geographic work does not require installing GIS software.

Many tasks are small and immediate:

convert decimal degrees to DMS,
calculate the distance between two points,
find an address from coordinates,
find coordinates from a location,
check elevation,
inspect a location on a map.

For these cases, the browser is often enough.

That became another project goal:

If a geographic task can reasonably be completed in a browser, the user should not need additional software.

This does not replace professional GIS tools.

It serves a different use case.

Professional GIS applications are designed for analysis, datasets, projections, layers, and advanced spatial workflows.

A browser utility should optimize for speed and simplicity.

Goal 5: Be Useful to Both Users and Developers

Many geographic problems have two sides.

There is the user-facing question:

How far apart are these locations?

And there is the implementation question:

How do I calculate distance between two GPS coordinates?

The same is true for reverse geocoding.

A user wants:

What address is this coordinate?

A developer wants:

How do I turn latitude and longitude into an address with JavaScript?

This is why I have also been documenting some of the technical problems I encountered while building the project.

For example:

calculating distance between GPS coordinates,
converting decimal coordinates to DMS,
reverse geocoding,
finding nearby places,
opening coordinates in external map services,
working with MapLibre.

The tool solves the immediate problem.

The technical article explains how part of the solution works.

I like that combination because it makes the project useful at two different levels.

An Important Design Constraint: Do Not Add Features Just Because You Can

Mapping projects can become complicated very quickly.

Once a map is on the page, it is tempting to keep adding things:

layers,
controls,
drawing tools,
satellite imagery,
markers,
filters,
panels,
overlays,
export options.

Some of those features are useful.

But every feature also adds cognitive cost.

I have gradually become more interested in asking:

Does this feature help answer the main question of the page?

If the answer is no, it may not belong there.

This is especially important for utility websites.

A user often arrives with a very specific intention.

They are not exploring software.

They are trying to get an answer.

What I Am Actually Building

I no longer think of CoordMap simply as a collection of map pages.

A better description is:

A set of small geographic utilities built around common location-related questions.

The distinction matters.

The project is not trying to compete with full mapping platforms.

It is trying to reduce friction around small geographic tasks.

That includes questions involving:

coordinates,
locations,
elevation,
distance,
time zones,
local time,
coordinate formats,
sunrise and sunset,
browser geolocation.

The long-term challenge is not adding as many features as possible.

It is making these tools feel like parts of the same system without making the system complicated.

The Broader Lesson

Building the project changed how I think about utility websites.

At first, it is easy to think in terms of features:

I need a coordinate finder.

I need an elevation page.

I need a distance calculator.

But users do not really think in feature lists.

They think in questions.

And one answer often creates the next question.

That leads to a much more useful product question:

What will the user probably want to know next?

For geographic tools, the answer is often surprisingly predictable.

A coordinate leads to a place.

A place leads to context.

Context leads to distance, elevation, time, weather, sunlight, or another nearby location.

The interesting part is not the coordinate itself.

It is everything the coordinate allows you to ask afterward.

That is the idea I am continuing to explore with CoordMap.

Coordinates are useful.

But most of the time, they are only the beginning.

How to Open Latitude and Longitude in Google Maps, Apple Maps, and OpenStreetMap with JavaScript

Luo Atlas — Mon, 14 Sep 2026 02:29:30 +0000

Latitude and longitude are useful on their own, but in many applications the next step is simple:

Open those coordinates on a map.

For example, you may have coordinates like:

40.7128, -74.0060

and want to let a user view that location in Google Maps, Apple Maps, or OpenStreetMap.

Fortunately, you usually do not need a mapping SDK for this. A simple URL is enough.

In this article, we'll look at several practical ways to open GPS coordinates from JavaScript.

1. Starting with Latitude and Longitude

Suppose we already have a pair of coordinates:

const latitude = 40.7128;
const longitude = -74.0060;

These coordinates point to New York City.

If you want to test coordinates manually before using them in code, a coordinate finder such as:

https://www.coordmap.com/longitude-latitude-finder

can be useful for checking latitude and longitude directly on a map.

2. Open Coordinates in Google Maps

Google Maps supports coordinate-based URLs.

A simple URL looks like this:

https://www.google.com/maps?q=40.7128,-74.0060

In JavaScript:

const latitude = 40.7128;
const longitude = -74.0060;

const url = `https://www.google.com/maps?q=${latitude},${longitude}`;

window.open(url, "_blank");

This opens Google Maps centered around the specified coordinates.

You can wrap it in a reusable function:

function openGoogleMaps(latitude, longitude) {
  const url = `https://www.google.com/maps?q=${latitude},${longitude}`;
  window.open(url, "_blank");
}

openGoogleMaps(40.7128, -74.0060);

3. Use the Google Maps Search URL Format

Google also provides a more explicit search URL format:

function openGoogleMaps(latitude, longitude) {
  const url =
    `https://www.google.com/maps/search/?api=1&query=${latitude},${longitude}`;

  window.open(url, "_blank");
}

For example:

https://www.google.com/maps/search/?api=1&query=48.8566,2.3522

opens the location of Paris.

This format is useful because it clearly tells Google Maps that the coordinates should be treated as a search query.

4. Open Coordinates in Apple Maps

Apple Maps also accepts latitude and longitude through its URL parameters.

Example:

const latitude = 37.7749;
const longitude = -122.4194;

const url = `https://maps.apple.com/?ll=${latitude},${longitude}`;

window.open(url, "_blank");

This will open the coordinates around San Francisco.

You can also add a label:

function openAppleMaps(latitude, longitude, label = "Location") {
  const url =
    `https://maps.apple.com/?ll=${latitude},${longitude}&q=${encodeURIComponent(label)}`;

  window.open(url, "_blank");
}

Example:

openAppleMaps(
  37.7749,
  -122.4194,
  "San Francisco"
);

5. Open Coordinates in OpenStreetMap

OpenStreetMap is especially useful for open-source projects and applications that do not want to depend entirely on commercial map providers.

A typical URL looks like:

https://www.openstreetmap.org/?mlat=51.5074&mlon=-0.1278#map=14/51.5074/-0.1278

In JavaScript:

function openOpenStreetMap(latitude, longitude, zoom = 14) {
  const url =
    `https://www.openstreetmap.org/?mlat=${latitude}` +
    `&mlon=${longitude}` +
    `#map=${zoom}/${latitude}/${longitude}`;

  window.open(url, "_blank");
}

Example:

openOpenStreetMap(51.5074, -0.1278);

This opens London in OpenStreetMap and places a marker around the requested coordinates.

6. Let the User Choose a Map Provider

Instead of forcing users to use one map application, you can offer several options.

HTML:

<button onclick="openMap('google')">
  Google Maps
</button>

<button onclick="openMap('apple')">
  Apple Maps
</button>

<button onclick="openMap('osm')">
  OpenStreetMap
</button>

JavaScript:

const latitude = 35.6762;
const longitude = 139.6503;

function openMap(provider) {
  let url;

  switch (provider) {
    case "google":
      url =
        `https://www.google.com/maps/search/?api=1&query=` +
        `${latitude},${longitude}`;
      break;

    case "apple":
      url =
        `https://maps.apple.com/?ll=${latitude},${longitude}`;
      break;

    case "osm":
      url =
        `https://www.openstreetmap.org/?mlat=${latitude}` +
        `&mlon=${longitude}` +
        `#map=14/${latitude}/${longitude}`;
      break;

    default:
      return;
  }

  window.open(url, "_blank");
}

This is a simple approach that works well for location tools, travel websites, delivery applications, GPS utilities, and address lookup tools.

7. Get the User's Current Coordinates

You can combine map URLs with the browser Geolocation API.

navigator.geolocation.getCurrentPosition(
  (position) => {
    const latitude = position.coords.latitude;
    const longitude = position.coords.longitude;

    console.log(latitude, longitude);
  },
  (error) => {
    console.error(error);
  }
);

Then open the user's current position in Google Maps:

navigator.geolocation.getCurrentPosition((position) => {
  const latitude = position.coords.latitude;
  const longitude = position.coords.longitude;

  const url =
    `https://www.google.com/maps/search/?api=1&query=` +
    `${latitude},${longitude}`;

  window.open(url, "_blank");
});

Remember that browsers normally require the user to explicitly grant location permission.

8. A Reusable JavaScript Function

If your application supports several map providers, you can create one utility function:

function getMapUrl(provider, latitude, longitude) {
  switch (provider) {
    case "google":
      return (
        `https://www.google.com/maps/search/?api=1&query=` +
        `${latitude},${longitude}`
      );

    case "apple":
      return (
        `https://maps.apple.com/?ll=` +
        `${latitude},${longitude}`
      );

    case "osm":
      return (
        `https://www.openstreetmap.org/?mlat=${latitude}` +
        `&mlon=${longitude}` +
        `#map=14/${latitude}/${longitude}`
      );

    default:
      throw new Error("Unsupported map provider");
  }
}

Usage:

const url = getMapUrl(
  "google",
  40.7128,
  -74.0060
);

window.open(url, "_blank");

This keeps your location-handling code much easier to maintain.

9. Validate Coordinates Before Opening the Map

When coordinates come from user input, they should be validated.

Latitude must be between:

-90 and 90

Longitude must be between:

-180 and 180

A simple validation function:

function isValidCoordinate(latitude, longitude) {
  return (
    Number.isFinite(latitude) &&
    Number.isFinite(longitude) &&
    latitude >= -90 &&
    latitude <= 90 &&
    longitude >= -180 &&
    longitude <= 180
  );
}

Example:

const latitude = 40.7128;
const longitude = -74.0060;

if (isValidCoordinate(latitude, longitude)) {
  window.open(
    `https://www.google.com/maps?q=${latitude},${longitude}`,
    "_blank"
  );
}

This is especially important if coordinates are entered manually.

10. Testing Coordinates Visually

When developing coordinate-related features, it is often useful to verify the result visually.

For example, after calculating or receiving:

48.8566, 2.3522

you may want to confirm whether the coordinates actually point to Paris.

Instead of writing temporary map code every time, you can paste the coordinates into a browser-based coordinate tool such as:

https://www.coordmap.com/longitude-latitude-finder

and inspect the position directly.

This is also useful when debugging:

GPS data
Geolocation API results
reverse geocoding
address lookup
distance calculations
coordinate conversions
location databases

Conclusion

Opening latitude and longitude in a map application is surprisingly simple.

For many projects, you do not need a complete maps SDK.

You can generate a URL such as:

https://www.google.com/maps?q=LATITUDE,LONGITUDE

and let the map provider handle the rest.

Google Maps, Apple Maps, and OpenStreetMap all support coordinate-based URLs, making this technique useful for lightweight location tools and web applications.

For developers working frequently with GPS coordinates, having both small JavaScript utilities and a visual coordinate finder can make debugging location data much easier.

Useful Links

Coordinate finder:

https://www.coordmap.com/longitude-latitude-finder

CoordMap:

https://www.coordmap.com/

Tags:

#javascript #webdev #maps #geolocation

A Practical Map Toolbox for Developers Working with Coordinates

Luo Atlas — Mon, 07 Sep 2026 02:02:20 +0000

If you work with maps, location data, or GPS coordinates, you probably know this situation:

You have a latitude and longitude pair such as:

37.4219983, -122.084

And suddenly you need to answer five more questions:

Where exactly is this?
What address does it belong to?
What's the elevation?
What places are nearby?
Is the coordinate itself even correct?

Of course, all of these problems can be solved with APIs and a few lines of JavaScript.

But sometimes you don't want to build anything.

You just want to check the data.

That's why I built CoordMap, a small collection of browser-based map utilities for working with coordinates and locations.

The problem with debugging location data

When developing location-based applications, I often find myself switching between several tools.

One site for coordinates.

Another for reverse geocoding.

Another for elevation.

Another map for visually checking whether a point is actually where I expect it to be.

For example, imagine an API returns:

{
  "latitude": 40.7484,
  "longitude": -73.9857
}

Before using that result in an application, I may want to quickly inspect it on a map.

Instead of creating a temporary map page or sending another API request, I can paste the coordinates into a coordinate finder and visually verify the location.

This sounds trivial, but it becomes surprisingly useful when working with:

delivery applications
travel websites
GPS tracking
geocoding APIs
weather applications
hiking tools
location-based search
map interfaces

Address → coordinates

One of the most common tasks is geocoding.

You start with something like:

1600 Amphitheatre Parkway, Mountain View

and need something like:

37.xxxxxx, -122.xxxxxx

In production applications, you would normally use a geocoding API.

But during development, manually testing an address first is often useful.

For example, if your API returns an unexpected location, checking the same address independently can help determine whether the problem is your application, your query formatting, or the underlying geocoder.

Coordinates → address

The opposite operation is equally useful.

Suppose your browser gives you a position:

navigator.geolocation.getCurrentPosition((position) => {
  console.log(position.coords.latitude);
  console.log(position.coords.longitude);
});

Now you have two numbers.

That's useful for a computer, but not particularly useful to a person.

Reverse geocoding converts those coordinates into a human-readable place or address.

During development, I often paste GPS coordinates directly into a map before integrating reverse geocoding into the application.

It makes debugging much faster.

Decimal coordinates vs DMS

Coordinates also appear in different formats.

Most web APIs use decimal degrees:

51.5074, -0.1278

But GPS devices, documents, and traditional maps may use degrees, minutes, and seconds:

51°30'26.6"N 0°07'40.1"W

The conversion itself isn't difficult.

For example:

function decimalToDMS(decimal) {
  const degrees = Math.floor(Math.abs(decimal));
  const minutesFloat = (Math.abs(decimal) - degrees) * 60;
  const minutes = Math.floor(minutesFloat);
  const seconds = (minutesFloat - minutes) * 60;

  return {
    degrees,
    minutes,
    seconds
  };
}

But if I only need to convert one coordinate while debugging something, opening a converter is usually faster than writing or running code.

Checking elevation

Coordinates are two-dimensional, but many real-world applications need a third value:

elevation.

This becomes useful for things like:

hiking applications
cycling routes
outdoor travel
terrain visualization
GPS photo metadata
geographic analysis

Elevation data should generally be treated as an estimate unless you're using survey-grade data, but it's still useful for quickly understanding a location.

A point at 20 meters above sea level and a point at 2,000 meters can obviously behave very differently in an outdoor or weather-related application.

Finding nearby places

Another common location workflow starts with a coordinate and asks:

What's around here?

For an application, this usually means calling a places API.

For debugging, however, it's useful to visually inspect nearby places first.

Given:

latitude = 48.8584
longitude = 2.2945

you may want to see nearby restaurants, hotels, landmarks, or other points of interest before deciding how your application should present the results.

This is particularly helpful when testing location search radius logic.

For example:

const searchRadius = 1000; // meters

A radius that works well in Manhattan may behave very differently in a rural area.

Looking at the map helps make those differences obvious.

A small tool I built for this

I eventually put these workflows together into one site:

https://www.coordmap.com/

The idea behind CoordMap is intentionally simple:

Paste an address or coordinate, inspect it on a map, and continue exploring from there.

It includes tools for working with latitude and longitude, checking your current location, exploring elevation, discovering nearby places, converting coordinate formats, measuring distance, browsing a world map, and working with other common geographic information.

There's no need to create an account just to use the basic map tools.

I mainly use it as a quick companion when developing or testing location-related features.

Tools don't replace APIs

A browser tool like this isn't intended to replace a proper geospatial stack.

If you're processing thousands of coordinates, you should use an API or a geographic database.

If you're calculating large datasets, use libraries such as Turf.js, PostGIS, or other GIS tools.

And if location is a critical part of your application, you should understand the accuracy and limitations of your underlying data sources.

But for questions like:

"Where is this coordinate?"

or:

"Did my geocoder return the right place?"

or:

"What's near this point?"

sometimes opening a map is simply the fastest solution.

That's the problem I wanted CoordMap to solve.

If you work with maps or location data, you can try it here:

👉 https://www.coordmap.com/

I'd also be interested to know which small geographic utilities you use most often while developing location-based applications.

A Simple Longitude and Latitude Finder for Developers, Travelers, and Map Users

Luo Atlas — Mon, 31 Aug 2026 06:41:03 +0000

When working with maps, location-based applications, GIS data, or travel planning, one small problem comes up surprisingly often:

How do I quickly find the exact longitude and latitude of a place?

Sometimes you have an address and need coordinates. Other times, you already have a pair of coordinates and want to know what location they represent.

For those situations, I recently built a simple browser-based tool:

👉 Longitude and Latitude Finder

The goal is simple: make coordinate lookup fast without requiring GIS software or writing API requests.

What can it do?

The tool supports several ways to find a location.

1. Find longitude and latitude from an address

Enter an address such as:

1600 Amphitheatre Parkway, Mountain View

The tool searches for the location and returns its geographic coordinates.

This can be useful when preparing:

Map markers
Location datasets
GIS data
Delivery coordinates
Travel routes
Geolocation test data

2. Find an address from coordinates

You can also do the opposite.

Enter:

Longitude: -122.084
Latitude: 37.422

and the tool attempts to identify the corresponding address or place.

This is useful when debugging applications that return GPS coordinates but don't provide a human-readable location.

3. Click anywhere on the map

Sometimes you don't know the address at all.

In that case, simply click a location on the map.

The tool will retrieve information about the selected point, including its coordinates and available place information.

For quickly exploring an unfamiliar area, this is often faster than typing an address.

4. Get more than just coordinates

After selecting a location, the result can include information such as:

Latitude
Longitude
Formatted address
Street
City or region
Country
Country code
Estimated elevation

Coordinates use the widely used WGS84 coordinate system, which makes the results convenient for web maps, GPS applications, and many GIS workflows.

Why I built it

There are many powerful GIS platforms available, but sometimes they are more than you need.

For a quick lookup, I wanted something where the workflow is simply:

Open page
→ Search or click map
→ Get coordinates
→ Copy result

No account creation and no complicated interface.

Useful development scenarios

I've found tools like this particularly useful when working on location-based projects.

For example, imagine you're building a map application and need a few coordinates for testing.

Instead of manually searching through map APIs, you can open the finder, click several locations, and quickly collect the coordinates you need.

It can also help when debugging cases like:

const location = {
  latitude: 37.422,
  longitude: -122.084
}

If your application receives coordinates but you aren't sure where they point, reverse lookup makes checking them much easier.

Worldwide coordinate lookup

The tool is designed for global location searches rather than being limited to a single country.

That makes it useful for projects involving international locations, travel planning, geographic datasets, or applications with users from multiple regions.

Try it

If you occasionally need to convert between addresses and geographic coordinates, you can try it here:

👉 https://www.coordmap.com/longitude-latitude-finder

I'm continuing to improve CoordMap and add useful tools around coordinates, maps, elevation, and location data.

If you work with maps or geolocation applications, I'd also be interested to hear what small location-related utilities you frequently need.

How to Find Nearby Places from Latitude and Longitude with JavaScript

Luo Atlas — Mon, 24 Aug 2026 03:36:25 +0000

When you already have a latitude and longitude pair, you can do much more than simply place a marker on a map.

For example, given:

Latitude:  40.7128
Longitude: -74.0060

you may want to find:

restaurants nearby,
cafes,
hotels,
hospitals,
gas stations,
pharmacies,
or other points of interest.

This is a common feature in travel apps, location tools, map interfaces, delivery applications, and local discovery websites.

In this tutorial, we'll build a simple nearby-place search with JavaScript using OpenStreetMap data and the Overpass API.

We'll cover:

How radius-based nearby searches work
How to query OpenStreetMap POIs
How to search multiple place categories
How to extract coordinates from results
How to calculate the distance to each result
A few important production considerations

The Basic Idea

A nearby search usually starts with three pieces of information:

Latitude
Longitude
Search radius

For example:

40.7128
-74.0060
1500 meters

We can then ask a geographic data source:

Find restaurants within
1500 meters of
40.7128, -74.0060

Conceptually:

User selects location
        ↓
Latitude + Longitude
        ↓
Nearby place query
        ↓
POI results
        ↓
Name + category + coordinates
        ↓
Display on map

Once you already have coordinates, the rest becomes a spatial search problem.

Using OpenStreetMap Data

OpenStreetMap contains geographic objects such as:

restaurants
cafes
hotels
schools
hospitals
shops
parks
pharmacies
fuel stations

These locations are usually described using tags.

A restaurant, for example, might contain:

amenity=restaurant

A cafe:

amenity=cafe

A hospital:

amenity=hospital

One way to query this data is the Overpass API.

For a simple experiment or developer tool, it gives us a convenient way to request OpenStreetMap objects near a coordinate.

A Simple Restaurant Query

Suppose we want to find restaurants within 1,500 meters of New York City coordinates:

const latitude = 40.7128;
const longitude = -74.0060;
const radius = 1500;

An Overpass query can look like this:

const query = `
[out:json][timeout:25];

(
  node["amenity"="restaurant"]
    (around:${radius},${latitude},${longitude});

  way["amenity"="restaurant"]
    (around:${radius},${latitude},${longitude});

  relation["amenity"="restaurant"]
    (around:${radius},${latitude},${longitude});
);

out center tags;
`;

There are three object types here:

node
way
relation

A small restaurant may be represented as a node.

A larger building may be represented as a way.

More complex geographic objects can also be relations.

Searching all three gives us more complete results.

Send the Request with JavaScript

We can create a reusable function:

async function findNearbyRestaurants(
  latitude,
  longitude,
  radius = 1500
) {
  const query = `
    [out:json][timeout:25];

    (
      node["amenity"="restaurant"]
        (around:${radius},${latitude},${longitude});

      way["amenity"="restaurant"]
        (around:${radius},${latitude},${longitude});

      relation["amenity"="restaurant"]
        (around:${radius},${latitude},${longitude});
    );

    out center tags;
  `;

  const response = await fetch(
    "https://overpass-api.de/api/interpreter",
    {
      method: "POST",
      body: new URLSearchParams({
        data: query
      })
    }
  );

  if (!response.ok) {
    throw new Error(
      `Nearby search failed: ${response.status}`
    );
  }

  return response.json();
}

Then call it:

findNearbyRestaurants(
  40.7128,
  -74.0060
).then(data => {
  console.log(data.elements);
});

The response contains OpenStreetMap elements matching our query.

Extract Useful Place Information

Raw OpenStreetMap objects contain more information than we usually need.

Let's normalize the response.

function normalizePlace(element) {
  const latitude =
    element.lat ??
    element.center?.lat;

  const longitude =
    element.lon ??
    element.center?.lon;

  return {
    id: element.id,

    name:
      element.tags?.name ??
      "Unnamed place",

    latitude,
    longitude,

    category:
      element.tags?.amenity,

    cuisine:
      element.tags?.cuisine,

    website:
      element.tags?.website,

    openingHours:
      element.tags?.opening_hours
  };
}

Now:

const data =
  await findNearbyRestaurants(
    40.7128,
    -74.0060
  );

const places =
  data.elements
    .map(normalizePlace)
    .filter(
      place =>
        place.latitude != null &&
        place.longitude != null
    );

console.log(places);

The result becomes much easier to work with:

[
  {
    id: 123456,
    name: "Example Restaurant",
    latitude: 40.715,
    longitude: -74.003,
    category: "restaurant",
    cuisine: "italian"
  }
]

Search Multiple Categories

Searching only for restaurants is useful, but most map applications support several categories.

We can use a regular expression in the Overpass query.

For example:

const amenityTypes = [
  "restaurant",
  "cafe",
  "bar",
  "fast_food"
];

Convert them into:

const pattern =
  amenityTypes.join("|");

Then use:

["amenity"~"restaurant|cafe|bar|fast_food"]

Our JavaScript function becomes:

async function findNearbyFood(
  latitude,
  longitude,
  radius = 1500
) {
  const pattern =
    "restaurant|cafe|bar|fast_food";

  const query = `
    [out:json][timeout:25];

    (
      node["amenity"~"${pattern}"]
        (around:${radius},${latitude},${longitude});

      way["amenity"~"${pattern}"]
        (around:${radius},${latitude},${longitude});

      relation["amenity"~"${pattern}"]
        (around:${radius},${latitude},${longitude});
    );

    out center tags;
  `;

  const response = await fetch(
    "https://overpass-api.de/api/interpreter",
    {
      method: "POST",

      body: new URLSearchParams({
        data: query
      })
    }
  );

  if (!response.ok) {
    throw new Error(
      "Unable to search nearby places"
    );
  }

  return response.json();
}

This gives us a simple nearby food search.

Calculate Distance to Each Place

The API tells us which places are nearby, but we may also want to show:

Cafe A       240 m
Restaurant B 480 m
Cafe C       720 m

We can calculate this using the Haversine formula.

function distanceBetween(
  lat1,
  lon1,
  lat2,
  lon2
) {
  const earthRadius = 6371000;

  const toRadians = degrees =>
    degrees * Math.PI / 180;

  const dLat =
    toRadians(lat2 - lat1);

  const dLon =
    toRadians(lon2 - lon1);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRadians(lat1)) *
    Math.cos(toRadians(lat2)) *
    Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return earthRadius * c;
}

Then:

const origin = {
  latitude: 40.7128,
  longitude: -74.0060
};

const placesWithDistance =
  places.map(place => ({
    ...place,

    distance:
      distanceBetween(
        origin.latitude,
        origin.longitude,
        place.latitude,
        place.longitude
      )
  }));

We can sort the results:

placesWithDistance.sort(
  (a, b) =>
    a.distance - b.distance
);

Now the nearest location appears first.

Format the Distance

A small formatting helper improves the UI:

function formatDistance(meters) {
  if (meters < 1000) {
    return `${Math.round(meters)} m`;
  }

  return `${(
    meters / 1000
  ).toFixed(1)} km`;
}

Usage:

for (
  const place
  of placesWithDistance
) {
  console.log(
    place.name,
    formatDistance(place.distance)
  );
}

Example:

Coffee Shop       180 m
Pizza Restaurant  420 m
Cafe              1.2 km

Connect Nearby Search to a Map Click

This becomes especially useful when combined with an interactive map.

For example, with MapLibre:

map.on(
  "click",
  async event => {
    const {
      lat,
      lng
    } = event.lngLat;

    const data =
      await findNearbyFood(
        lat,
        lng,
        1500
      );

    console.log(
      "Nearby places:",
      data.elements
    );
  }
);

Now the workflow becomes:

Click map
   ↓
Get longitude / latitude
   ↓
Search nearby places
   ↓
Display markers

This makes the map itself the search interface.

Instead of forcing users to type an exact address, they can explore visually.

Combine It with Browser Geolocation

We can also start from the user's current position.

navigator.geolocation
  .getCurrentPosition(
    async position => {
      const {
        latitude,
        longitude
      } = position.coords;

      const data =
        await findNearbyFood(
          latitude,
          longitude,
          1500
        );

      console.log(data);
    },
    error => {
      console.error(
        "Unable to get location",
        error
      );
    }
  );

This creates another common workflow:

Use My Location
      ↓
Browser geolocation
      ↓
Latitude + Longitude
      ↓
Nearby search
      ↓
Restaurants / Cafes / POIs

Always remember that browser geolocation requires user permission.

Location access should also be requested only when the feature actually needs it.

Don't Forget Coordinate Validation

Before sending coordinates to any geographic service, validate them.

Latitude must be:

-90 to 90

Longitude must be:

-180 to 180

A simple helper:

function validateCoordinates(
  latitude,
  longitude
) {
  if (
    !Number.isFinite(latitude) ||
    latitude < -90 ||
    latitude > 90
  ) {
    throw new RangeError(
      "Invalid latitude"
    );
  }

  if (
    !Number.isFinite(longitude) ||
    longitude < -180 ||
    longitude > 180
  ) {
    throw new RangeError(
      "Invalid longitude"
    );
  }
}

This prevents many surprisingly common bugs.

The Latitude / Longitude Order Problem

One more thing deserves special attention.

Some APIs expect:

latitude, longitude

Others use:

longitude, latitude

GeoJSON, for example, uses:

[
  longitude,
  latitude
]

MapLibre also commonly works with:

[
  longitude,
  latitude
]

But the Overpass around syntax in our example uses:

latitude, longitude

Mixing these up can move your result thousands of kilometers away.

Naming variables explicitly helps:

const latitude = 40.7128;
const longitude = -74.0060;

instead of:

const x = 40.7128;
const y = -74.0060;

Production Considerations

The public Overpass API is great for learning, prototypes, and relatively light queries.

It should not automatically be treated as the backend for a high-traffic production application.

If you're building a larger application, consider:

caching nearby searches,
limiting the search radius,
limiting requested categories,
avoiding unnecessary repeat queries,
debouncing map interactions,
using your own backend,
or using a commercial/local-search provider designed for production traffic.

Also remember that OpenStreetMap coverage varies by location.

Some cities contain extremely detailed POI information, while other areas may contain fewer mapped businesses.

Try Nearby Search with Real Locations

When developing a nearby-search feature, one of the most useful things you can do is test it with coordinates from different types of places.

For example:

New York
40.7128, -74.0060

London
51.5074, -0.1278

Tokyo
35.6762, 139.6503

Sydney
-33.8688, 151.2093

I've been building CoordMap, a browser-based collection of geographic tools for working with coordinates, maps, elevation, location lookup, and nearby places.

You can use CoordMap Nearby Places to select an address or map location and explore restaurants, cafes, hotels, and similar places around it.

The live CoordMap tool uses its own nearby-place provider; the OpenStreetMap/Overpass implementation in this tutorial is an independent example for developers who want to understand how radius-based geographic searches work.

It's also useful when you need real coordinates to test your own mapping application.

Final Thoughts

Once your application has a reliable latitude and longitude pair, nearby search becomes another layer on top of the same location state.

The architecture can stay surprisingly simple:

Address Search ───────┐
                      │
Map Click ────────────┼──→ Latitude + Longitude
                      │
Current Location ─────┘
                              │
                              ▼
                       Nearby Search
                              │
                   ┌──────────┼──────────┐
                   ▼          ▼          ▼
              Restaurants   Cafes      Hotels
                   │
                   ▼
                 Markers

This pattern is reusable across travel applications, mapping tools, local search interfaces, delivery systems, and location-based web apps.

And once the coordinate pair becomes the center of your application state, you can easily add other geographic layers such as:

Address
Elevation
Weather
Distance
Nearby places
Time zone

That's one of the reasons latitude and longitude are such useful building blocks for location-based applications.

How to Turn Latitude and Longitude into an Address with JavaScript

Luo Atlas — Tue, 18 Aug 2026 03:21:20 +0000

Sometimes you have GPS coordinates like:

40.7128, -74.0060

But coordinates alone are not very useful to most users.

They usually want to know something much simpler:

What place is this?

The process of converting latitude and longitude into a human-readable address is called reverse geocoding.

In this article, we'll build a simple reverse geocoding example with JavaScript.

What Is Reverse Geocoding?

Normal geocoding converts an address into coordinates:

New York, NY
↓
40.7128, -74.0060

Reverse geocoding does the opposite:

40.7128, -74.0060
↓
New York, NY, United States

This is useful for location tools, GPS applications, travel websites, delivery systems, photo location tools, and map interfaces.

Reverse Geocoding with JavaScript

For a simple example, we can use the OpenStreetMap Nominatim reverse geocoding endpoint.

async function reverseGeocode(lat, lon) {
  const url =
    `https://nominatim.openstreetmap.org/reverse` +
    `?lat=${lat}&lon=${lon}&format=jsonv2`;

  const response = await fetch(url);

  if (!response.ok) {
    throw new Error("Reverse geocoding failed");
  }

  const data = await response.json();

  return data;
}

reverseGeocode(40.7128, -74.0060)
  .then(data => {
    console.log(data.display_name);
  })
  .catch(error => {
    console.error(error);
  });

The returned data usually contains a readable location name together with structured address information.

Display the Address on a Page

We can turn the example into a small browser tool.

<input id="lat" placeholder="Latitude">
<input id="lon" placeholder="Longitude">

<button onclick="findAddress()">
  Find Address
</button>

<p id="result"></p>

<script>
async function findAddress() {
  const lat = document.getElementById("lat").value;
  const lon = document.getElementById("lon").value;

  const result = document.getElementById("result");

  try {
    const url =
      `https://nominatim.openstreetmap.org/reverse` +
      `?lat=${lat}&lon=${lon}&format=jsonv2`;

    const response = await fetch(url);
    const data = await response.json();

    result.textContent =
      data.display_name || "Location not found";
  } catch (error) {
    result.textContent = "Unable to find this location";
  }
}
</script>

Now a user can paste coordinates and immediately see the corresponding place.

Coordinates from a Map Click

A more natural interface is to let users click directly on a map.

A typical map application can capture the clicked coordinate:

map.on("click", async (event) => {
  const latitude = event.lngLat.lat;
  const longitude = event.lngLat.lng;

  const location = await reverseGeocode(
    latitude,
    longitude
  );

  console.log(location.display_name);
});

This creates a useful interaction:

Click map
   ↓
Get latitude / longitude
   ↓
Reverse geocode coordinates
   ↓
Display the address

For many users, this is easier than manually entering GPS coordinates.

A Quick Way to Test Coordinates

If you only need to check a coordinate occasionally, building an application may be unnecessary.

You can use a browser-based coordinate lookup tool such as:

CoordMap Geocoding Tool

It lets you search locations, enter coordinates, or click directly on a map to inspect a position.

This can also be useful when debugging a geocoding application because you can compare your application's output with the location shown on the map.

Reverse Geocoding Is Not Always Exact

One important thing to remember is that reverse geocoding does not magically know the exact address of every coordinate.

A geocoder normally searches its geographic database for the most appropriate nearby mapped object.

That means a coordinate near a road, building boundary, park, or rural area may return a nearby address rather than an exact street address.

So your application should treat reverse-geocoded addresses as location information rather than guaranteed survey-level data.

Latitude and Longitude Order Matters

Another common source of bugs is mixing up latitude and longitude.

For example:

Latitude:  40.7128
Longitude: -74.0060

Some APIs and GIS formats use:

latitude, longitude

while others use:

longitude, latitude

Always check the format expected by the API or mapping library you are using.

A coordinate with the values reversed may point to a completely different part of the world—or may not be valid at all.

Final Thoughts

Reverse geocoding is a small feature, but it makes geographic coordinates much more understandable.

Instead of showing users:

40.7128, -74.0060

you can show them an actual place name or address.

From there, you can build more useful features such as interactive maps, location sharing, GPS tools, travel utilities, nearby-place searches, or location-based applications.

Sometimes the most useful mapping feature is simply answering one question:

Where is this coordinate?

Tags: #javascript #webdev #maps #geocoding

How to Calculate Distance Between Two GPS Coordinates in JavaScript

Luo Atlas — Tue, 11 Aug 2026 01:25:23 +0000

When working with maps, GPS data, or location-based applications, one of the most common questions is:

How far apart are these two coordinates?

Suppose we have two locations:

Point A
Latitude:  40.7128
Longitude: -74.0060

Point B
Latitude:  34.0522
Longitude: -118.2437

These are approximately New York City and Los Angeles.

We can't simply subtract the latitude and longitude values and treat them like normal Cartesian coordinates.

The Earth is curved.

For many web applications, a practical solution is the Haversine formula, which calculates the great-circle distance between two points on a sphere.

In this article, we'll build a reusable JavaScript implementation that supports:

Latitude and longitude validation
Degrees-to-radians conversion
The Haversine formula
Kilometers
Miles
Nautical miles
TypeScript
Unit tests
Real-world coordinate testing

Why Simple Euclidean Distance Doesn't Work

If we had two points on a flat coordinate plane:

(x1, y1)
(x2, y2)

we could use:

distance = √((x2 - x1)² + (y2 - y1)²)

Latitude and longitude don't work like that.

They represent positions on the Earth's surface.

A degree of longitude also does not represent the same physical distance everywhere.

Near the Equator, one degree of longitude covers a much larger distance than it does near the poles.

So this:

const distance = Math.sqrt(
  (lat2 - lat1) ** 2 +
  (lon2 - lon1) ** 2
);

does not give us a meaningful distance in kilometers or miles.

We need to account for the Earth's curvature.

The Haversine Formula

The Haversine formula estimates the great-circle distance between two points using their latitude and longitude.

The main idea is:

Latitude / Longitude
        ↓
Convert degrees to radians
        ↓
Calculate angular distance
        ↓
Multiply by Earth's radius
        ↓
Physical distance

We'll break the implementation into small pieces.

Convert Degrees to Radians

JavaScript's trigonometric functions such as:

Math.sin()
Math.cos()
Math.atan2()

expect radians rather than degrees.

So we first need a helper:

function toRadians(degrees) {
  return degrees * Math.PI / 180;
}

For example:

console.log(toRadians(180));

returns approximately:

3.141592653589793

which is π radians.

A Basic Distance Function

Let's start with a simple Haversine implementation:

function distanceBetweenCoordinates(
  lat1,
  lon1,
  lat2,
  lon2
) {
  const earthRadiusKm = 6371.0088;

  const dLat = toRadians(lat2 - lat1);
  const dLon = toRadians(lon2 - lon1);

  const latitude1 = toRadians(lat1);
  const latitude2 = toRadians(lat2);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(latitude1) *
      Math.cos(latitude2) *
      Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return earthRadiusKm * c;
}

Usage:

const distance = distanceBetweenCoordinates(
  40.7128,
  -74.0060,
  34.0522,
  -118.2437
);

console.log(distance);

The result is approximately:

3935 km

depending on the Earth radius and rounding you use.

What Is Happening Inside the Formula?

Let's break the calculation down.

First, calculate the differences:

const dLat = toRadians(lat2 - lat1);
const dLon = toRadians(lon2 - lon1);

Then convert both latitude values to radians:

const latitude1 = toRadians(lat1);
const latitude2 = toRadians(lat2);

const a =
  Math.sin(dLat / 2) ** 2 +
  Math.cos(latitude1) *
    Math.cos(latitude2) *
    Math.sin(dLon / 2) ** 2;

This gives us an intermediate value representing the angular relationship between the two points.

Then:

const c =
  2 * Math.atan2(
    Math.sqrt(a),
    Math.sqrt(1 - a)
  );

produces the central angle between the locations.

Finally:

earthRadiusKm * c

converts that angular distance into kilometers.

Validate Latitude and Longitude

Before calculating distance, we should validate the inputs.

Latitude must be between:

-90 and 90

Longitude must be between:

-180 and 180

Let's create reusable validators:

function isValidLatitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -90 &&
    value <= 90
  );
}

function isValidLongitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -180 &&
    value <= 180
  );
}

Then:

function validateCoordinate(
  latitude,
  longitude
) {
  if (!isValidLatitude(latitude)) {
    throw new RangeError(
      "Latitude must be between -90 and 90"
    );
  }

  if (!isValidLongitude(longitude)) {
    throw new RangeError(
      "Longitude must be between -180 and 180"
    );
  }
}

Now our distance function can validate both points.

A More Reliable Implementation

Let's combine validation with the Haversine calculation:

function toRadians(degrees) {
  return degrees * Math.PI / 180;
}

function isValidLatitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -90 &&
    value <= 90
  );
}

function isValidLongitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -180 &&
    value <= 180
  );
}

function validateCoordinate(
  latitude,
  longitude
) {
  if (!isValidLatitude(latitude)) {
    throw new RangeError(
      "Latitude must be between -90 and 90"
    );
  }

  if (!isValidLongitude(longitude)) {
    throw new RangeError(
      "Longitude must be between -180 and 180"
    );
  }
}

function distanceBetweenCoordinates(
  lat1,
  lon1,
  lat2,
  lon2
) {
  validateCoordinate(lat1, lon1);
  validateCoordinate(lat2, lon2);

  const earthRadiusKm = 6371.0088;

  const latitude1 = toRadians(lat1);
  const latitude2 = toRadians(lat2);

  const dLat = toRadians(lat2 - lat1);
  const dLon = toRadians(lon2 - lon1);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(latitude1) *
      Math.cos(latitude2) *
      Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return earthRadiusKm * c;
}

Now invalid coordinates are rejected immediately.

For example:

distanceBetweenCoordinates(
  120,
  0,
  40,
  20
);

throws:

RangeError: Latitude must be between -90 and 90

Support Kilometers, Miles, and Nautical Miles

A mapping tool may need more than kilometers.

Common units include:

Kilometers
Miles
Nautical miles

We can define Earth-radius values for each unit:

const EARTH_RADIUS = {
  km: 6371.0088,
  miles: 3958.7613,
  nauticalMiles: 3440.0695
};

Then update the function:

function distanceBetweenCoordinates(
  lat1,
  lon1,
  lat2,
  lon2,
  unit = "km"
) {
  validateCoordinate(lat1, lon1);
  validateCoordinate(lat2, lon2);

  const radius =
    EARTH_RADIUS[unit];

  if (!radius) {
    throw new Error(
      "Unsupported distance unit"
    );
  }

  const latitude1 = toRadians(lat1);
  const latitude2 = toRadians(lat2);

  const dLat = toRadians(lat2 - lat1);
  const dLon = toRadians(lon2 - lon1);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(latitude1) *
      Math.cos(latitude2) *
      Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return radius * c;
}

Usage:

console.log(
  distanceBetweenCoordinates(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437,
    "km"
  )
);

Miles:

console.log(
  distanceBetweenCoordinates(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437,
    "miles"
  )
);

Nautical miles:

console.log(
  distanceBetweenCoordinates(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437,
    "nauticalMiles"
  )
);

Return Structured Data

For a real application, returning just one number may be too limited.

Instead, we can calculate the distance once and return multiple units.

function getDistance(
  lat1,
  lon1,
  lat2,
  lon2
) {
  const kilometers =
    distanceBetweenCoordinates(
      lat1,
      lon1,
      lat2,
      lon2,
      "km"
    );

  return {
    kilometers,
    miles: kilometers * 0.621371,
    nauticalMiles:
      kilometers * 0.539957
  };
}

Usage:

console.log(
  getDistance(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437
  )
);

Example output:

{
  kilometers: 3935.75,
  miles: 2445.56,
  nauticalMiles: 2125.13
}

You can then decide how many decimal places to show in the UI.

Keep Calculation Precision Separate from Display Precision

Avoid rounding too early.

For example, don't do this inside the calculation:

return Number(
  distance.toFixed(2)
);

if the value will later be reused in other calculations.

Instead, return the full value:

return distance;

and format it only when displaying it:

const distance =
  distanceBetweenCoordinates(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437
  );

console.log(
  `${distance.toFixed(2)} km`
);

This keeps your calculation layer more accurate and reusable.

Handle Identical Coordinates

What happens if both points are exactly the same?

distanceBetweenCoordinates(
  40.7128,
  -74.006,
  40.7128,
  -74.006
);

The Haversine formula naturally returns:

So you usually don't need a special condition.

However, if your application wants to optimize this case:

if (
  lat1 === lat2 &&
  lon1 === lon2
) {
  return 0;
}

This can avoid unnecessary trigonometric calculations.

For most applications, either approach is fine.

Example: London to Paris

Let's try a shorter real-world distance.

London:

51.5074, -0.1278

Paris:

48.8566, 2.3522

JavaScript:

const londonToParis =
  distanceBetweenCoordinates(
    51.5074,
    -0.1278,
    48.8566,
    2.3522
  );

console.log(
  `${londonToParis.toFixed(2)} km`
);

The result is roughly:

344 km

This is the straight-line great-circle distance, not driving distance.

That's an important distinction.

Great-Circle Distance Is Not Driving Distance

The Haversine formula answers:

What is the shortest distance over the Earth's surface between two coordinates?

It does not consider:

Roads
Bridges
Traffic
Mountains
Walking routes
Rail networks
Borders
One-way streets

So:

GPS coordinate distance

and:

driving distance

are two different problems.

For driving distance, you need a routing engine or routing API.

The Haversine formula is better suited to:

Straight-line map distance
Nearby-location filtering
GPS proximity checks
Geographic analysis
Approximate travel radius
Location ranking

What About Earth's Shape?

The Haversine formula assumes the Earth is a sphere.

In reality, the Earth is closer to an oblate ellipsoid.

That means Haversine distance is an approximation.

For most:

Web applications
Map tools
Location searches
GPS utilities
Nearby-place calculations

the approximation is usually sufficient.

Applications requiring survey-grade or high-precision geodesic calculations should use an ellipsoidal model such as WGS84 with a proper geodesic algorithm.

So choose the calculation method based on the accuracy requirements of your application.

A TypeScript Version

We can make the unit options explicit with TypeScript.

type DistanceUnit =
  | "km"
  | "miles"
  | "nauticalMiles";

Define the radius map:

const EARTH_RADIUS: Record<
  DistanceUnit,
  number
> = {
  km: 6371.0088,
  miles: 3958.7613,
  nauticalMiles: 3440.0695
};

Then:

function distanceBetweenCoordinates(
  lat1: number,
  lon1: number,
  lat2: number,
  lon2: number,
  unit: DistanceUnit = "km"
): number {
  validateCoordinate(lat1, lon1);
  validateCoordinate(lat2, lon2);

  const radius =
    EARTH_RADIUS[unit];

  const latitude1 =
    toRadians(lat1);

  const latitude2 =
    toRadians(lat2);

  const dLat =
    toRadians(lat2 - lat1);

  const dLon =
    toRadians(lon2 - lon1);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(latitude1) *
      Math.cos(latitude2) *
      Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return radius * c;
}

Now this is valid:

distanceBetweenCoordinates(
  40.7128,
  -74.006,
  34.0522,
  -118.2437,
  "miles"
);

while this will be caught by TypeScript:

distanceBetweenCoordinates(
  40.7128,
  -74.006,
  34.0522,
  -118.2437,
  "meters"
);

unless you explicitly support that unit.

Testing With Vitest

Geographic calculation functions are good candidates for unit tests.

Example:

import {
  describe,
  expect,
  it
} from "vitest";

describe(
  "distanceBetweenCoordinates",
  () => {
    it(
      "returns zero for identical coordinates",
      () => {
        const distance =
          distanceBetweenCoordinates(
            40.7128,
            -74.006,
            40.7128,
            -74.006
          );

        expect(distance).toBe(0);
      }
    );

    it(
      "calculates London to Paris",
      () => {
        const distance =
          distanceBetweenCoordinates(
            51.5074,
            -0.1278,
            48.8566,
            2.3522
          );

        expect(distance)
          .toBeGreaterThan(340);

        expect(distance)
          .toBeLessThan(350);
      }
    );

    it(
      "rejects invalid latitude",
      () => {
        expect(() =>
          distanceBetweenCoordinates(
            100,
            0,
            40,
            20
          )
        ).toThrow(RangeError);
      }
    );
  }
);

For geographic calculations, testing a reasonable range is often safer than checking a value to many decimal places.

Different Earth-radius assumptions can produce slightly different results.

Build a Simple Distance Calculator UI

A basic HTML interface might contain:

<input
  id="lat1"
  type="number"
  step="any"
  placeholder="Latitude 1"
/>

<input
  id="lon1"
  type="number"
  step="any"
  placeholder="Longitude 1"
/>

<input
  id="lat2"
  type="number"
  step="any"
  placeholder="Latitude 2"
/>

<input
  id="lon2"
  type="number"
  step="any"
  placeholder="Longitude 2"
/>

<button id="calculate">
  Calculate Distance
</button>

<p id="result"></p>

Then:

document
  .querySelector("#calculate")
  .addEventListener(
    "click",
    () => {
      const lat1 = Number(
        document
          .querySelector("#lat1")
          .value
      );

      const lon1 = Number(
        document
          .querySelector("#lon1")
          .value
      );

      const lat2 = Number(
        document
          .querySelector("#lat2")
          .value
      );

      const lon2 = Number(
        document
          .querySelector("#lon2")
          .value
      );

      try {
        const distance =
          distanceBetweenCoordinates(
            lat1,
            lon1,
            lat2,
            lon2
          );

        document
          .querySelector("#result")
          .textContent =
            `${distance.toFixed(2)} km`;
      } catch (error) {
        document
          .querySelector("#result")
          .textContent =
            error.message;
      }
    }
  );

This is enough to build a simple browser-based GPS distance calculator.

Using Map Clicks Instead of Manual Coordinate Entry

For map applications, users may prefer selecting points visually.

The flow becomes:

Click Point A
      ↓
Store coordinates

Click Point B
      ↓
Store coordinates

Calculate Haversine distance
      ↓
Display result

For example:

const points = [];

map.on("click", event => {
  points.push({
    latitude: event.lngLat.lat,
    longitude: event.lngLat.lng
  });

  if (points.length === 2) {
    const [a, b] = points;

    const distance =
      distanceBetweenCoordinates(
        a.latitude,
        a.longitude,
        b.latitude,
        b.longitude
      );

    console.log(
      `${distance.toFixed(2)} km`
    );

    points.length = 0;
  }
});

This interaction works especially well for map-based measurement tools.

Test With Real Coordinates

When working on distance calculations, it's useful to test the function with real places rather than only artificial coordinate values.

I've been building CoordMap's Measure Distance tool, which lets you work with real geographic points and measure distances between locations.

You can use it to pick two locations and compare the result with your JavaScript implementation.

For example:

London
51.5074, -0.1278

Paris
48.8566, 2.3522

or:

New York
40.7128, -74.0060

Los Angeles
34.0522, -118.2437

Testing different regions is useful because it helps catch common mistakes such as:

latitude / longitude swapped

degrees passed directly into Math.sin()

incorrect Earth radius

invalid coordinate ranges

Complete Copy-Paste Version

Here's the full implementation:

const EARTH_RADIUS = {
  km: 6371.0088,
  miles: 3958.7613,
  nauticalMiles: 3440.0695
};

function toRadians(degrees) {
  return degrees * Math.PI / 180;
}

function isValidLatitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -90 &&
    value <= 90
  );
}

function isValidLongitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -180 &&
    value <= 180
  );
}

function validateCoordinate(
  latitude,
  longitude
) {
  if (!isValidLatitude(latitude)) {
    throw new RangeError(
      "Latitude must be between -90 and 90"
    );
  }

  if (!isValidLongitude(longitude)) {
    throw new RangeError(
      "Longitude must be between -180 and 180"
    );
  }
}

function distanceBetweenCoordinates(
  lat1,
  lon1,
  lat2,
  lon2,
  unit = "km"
) {
  validateCoordinate(lat1, lon1);
  validateCoordinate(lat2, lon2);

  const radius =
    EARTH_RADIUS[unit];

  if (!radius) {
    throw new Error(
      "Unsupported distance unit"
    );
  }

  if (
    lat1 === lat2 &&
    lon1 === lon2
  ) {
    return 0;
  }

  const latitude1 =
    toRadians(lat1);

  const latitude2 =
    toRadians(lat2);

  const dLat =
    toRadians(lat2 - lat1);

  const dLon =
    toRadians(lon2 - lon1);

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(latitude1) *
      Math.cos(latitude2) *
      Math.sin(dLon / 2) ** 2;

  const c =
    2 * Math.atan2(
      Math.sqrt(a),
      Math.sqrt(1 - a)
    );

  return radius * c;
}

const distance =
  distanceBetweenCoordinates(
    40.7128,
    -74.0060,
    34.0522,
    -118.2437
  );

console.log(
  `${distance.toFixed(2)} km`
);

Final Thoughts

Calculating the distance between two GPS coordinates is a small problem with a few important details.

The core process is:

Two GPS coordinates
        ↓
Validate latitude / longitude
        ↓
Convert degrees to radians
        ↓
Apply Haversine formula
        ↓
Calculate angular distance
        ↓
Multiply by Earth radius
        ↓
Kilometers / miles / nautical miles

The main things to remember are:

Latitude must stay between -90 and 90.
Longitude must stay between -180 and 180.
JavaScript trigonometric functions use radians.
The Haversine formula calculates great-circle distance.
Great-circle distance is not driving distance.
Avoid rounding until the presentation layer.
Use a more precise geodesic model when your application requires survey-grade accuracy.

For most web mapping, GPS, and proximity applications, the Haversine formula remains a useful and straightforward solution.

How to Build a Longitude and Latitude Finder with JavaScript and MapLibre

Luo Atlas — Mon, 10 Aug 2026 02:59:19 +0000

Longitude and latitude finders look simple from the outside:

Search for an address.
Get its coordinates.
Or click somewhere on a map.
Get the address for that point.

But building a useful version involves several pieces working together:

An interactive map
Forward geocoding
Reverse geocoding
Coordinate validation
Browser geolocation
Map and form state synchronization
Error handling

In this article, we'll build the core architecture of a browser-based longitude and latitude finder using JavaScript and MapLibre GL JS.

The goal is a tool that supports three common workflows:

Address → Longitude / Latitude

Longitude / Latitude → Address

Map Click → Longitude / Latitude + Address

Let's build it step by step.

What Are We Building?

Our interface can be kept simple.

┌─────────────────────────────────────┐
│ Search an address                   │
│ [ New York City                ] 🔍 │
└─────────────────────────────────────┘

Longitude
[-74.0060]

Latitude
[40.7128]

[Look up]

┌─────────────────────────────────────┐
│                                     │
│             Interactive Map         │
│                                     │
│          Click any location         │
│                                     │
└─────────────────────────────────────┘

Selected location

New York, NY, United States

Longitude: -74.0060
Latitude:   40.7128

The important design decision is that all three inputs update the same selected location state.

Whether the user:

searches an address,
enters coordinates,
clicks the map,
or uses browser geolocation,

the application should eventually produce the same internal representation.

For example:

const selectedLocation = {
  longitude: -74.006,
  latitude: 40.7128,
  address: "New York, NY, United States"
};

This makes the rest of the application much easier to maintain.

Understanding Longitude and Latitude

Before writing the UI logic, we need to validate coordinates correctly.

Latitude ranges from:

-90 to 90

Longitude ranges from:

-180 to 180

Examples:

New York

Latitude:   40.7128
Longitude: -74.0060

Sydney

Latitude:  -33.8688
Longitude: 151.2093

A simple JavaScript validator looks like this:

function isValidLatitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -90 &&
    value <= 90
  );
}

function isValidLongitude(value) {
  return (
    Number.isFinite(value) &&
    value >= -180 &&
    value <= 180
  );
}

Then combine them:

function validateCoordinates(
  longitude,
  latitude
) {
  if (!isValidLongitude(longitude)) {
    throw new RangeError(
      "Longitude must be between -180 and 180"
    );
  }

  if (!isValidLatitude(latitude)) {
    throw new RangeError(
      "Latitude must be between -90 and 90"
    );
  }
}

This should happen before moving the map or sending a reverse-geocoding request.

Create the Map with MapLibre

First, create a container:

<div id="map"></div>

Give it a height:

#map {
  width: 100%;
  height: 500px;
}

Then initialize MapLibre:

const map = new maplibregl.Map({
  container: "map",

  style: "YOUR_MAP_STYLE_URL",

  center: [0, 20],

  zoom: 2
});

Notice the coordinate order here:

[longitude, latitude]

Not:

[latitude, longitude]

This is an easy mistake to make when working with mapping APIs.

I prefer naming variables explicitly:

const longitude = -74.006;
const latitude = 40.7128;

map.flyTo({
  center: [
    longitude,
    latitude
  ],
  zoom: 12
});

That is much easier to read than:

map.flyTo({
  center: [-74.006, 40.7128]
});

Click the Map to Get Coordinates

One of the most useful interactions is allowing users to click anywhere on the map.

MapLibre exposes the clicked geographic position:

map.on("click", event => {
  const {
    lng,
    lat
  } = event.lngLat;

  console.log("Longitude:", lng);
  console.log("Latitude:", lat);
});

You can round the coordinates for display:

map.on("click", event => {
  const longitude =
    event.lngLat.lng.toFixed(6);

  const latitude =
    event.lngLat.lat.toFixed(6);

  console.log({
    longitude,
    latitude
  });
});

A click might produce:

{
  longitude: "-74.006015",
  latitude: "40.712728"
}

For calculations and API requests, however, keep them as numbers.

const longitude =
  event.lngLat.lng;

const latitude =
  event.lngLat.lat;

Only format the values when displaying them.

Add a Marker to the Selected Location

A visual marker makes it obvious which point is currently selected.

const marker =
  new maplibregl.Marker();

function setMarker(
  longitude,
  latitude
) {
  marker
    .setLngLat([
      longitude,
      latitude
    ])
    .addTo(map);
}

Then:

map.on("click", event => {
  const longitude =
    event.lngLat.lng;

  const latitude =
    event.lngLat.lat;

  setMarker(
    longitude,
    latitude
  );
});

We can also move the camera:

function focusLocation(
  longitude,
  latitude
) {
  map.flyTo({
    center: [
      longitude,
      latitude
    ],
    zoom: 14
  });
}

Reverse Geocoding: Coordinates to Address

Coordinates are useful for software.

Humans usually want an address or place name.

That's where reverse geocoding comes in.

The flow looks like this:

-74.0060, 40.7128
        ↓
Reverse Geocoding API
        ↓
New York, NY, United States

Instead of connecting your frontend directly to a provider containing a private API key, a safer architecture is:

Browser
   ↓
Your API
   ↓
Geocoding Provider

For example, the browser can call:

async function reverseGeocode(
  longitude,
  latitude
) {
  validateCoordinates(
    longitude,
    latitude
  );

  const params =
    new URLSearchParams({
      longitude,
      latitude
    });

  const response = await fetch(
    `/api/reverse-geocode?${params}`
  );

  if (!response.ok) {
    throw new Error(
      "Reverse geocoding failed"
    );
  }

  return response.json();
}

The response from your own backend can be normalized.

For example:

{
  "address": "New York, NY, United States",
  "longitude": -74.006,
  "latitude": 40.7128,
  "country": "United States",
  "countryCode": "US"
}

Normalizing the response is useful because different geocoding providers often return different field structures.

Your frontend doesn't need to care which provider was used.

Connect Reverse Geocoding to Map Clicks

Now we can combine the pieces.

map.on("click", async event => {
  const longitude =
    event.lngLat.lng;

  const latitude =
    event.lngLat.lat;

  setMarker(
    longitude,
    latitude
  );

  try {
    const place =
      await reverseGeocode(
        longitude,
        latitude
      );

    console.log(place);
  } catch (error) {
    console.error(
      "Unable to find address:",
      error
    );
  }
});

The user interaction is now:

Click map
   ↓
Read longitude / latitude
   ↓
Move marker
   ↓
Reverse geocode
   ↓
Display address

That already gives us a basic longitude and latitude finder.

Forward Geocoding: Address to Coordinates

We also need the opposite direction.

1600 Amphitheatre Parkway
          ↓
      Geocoding API
          ↓
37.4220, -122.0841

Create a search function:

async function geocodeAddress(
  query
) {
  const value = query.trim();

  if (!value) {
    throw new Error(
      "Address is required"
    );
  }

  const params =
    new URLSearchParams({
      q: value
    });

  const response = await fetch(
    `/api/geocode?${params}`
  );

  if (!response.ok) {
    throw new Error(
      "Address search failed"
    );
  }

  return response.json();
}

A normalized response might look like:

{
  "longitude": -122.0841,
  "latitude": 37.422,
  "address": "1600 Amphitheatre Parkway, Mountain View, CA"
}

Then update the map:

async function searchAddress(
  query
) {
  const place =
    await geocodeAddress(query);

  setMarker(
    place.longitude,
    place.latitude
  );

  focusLocation(
    place.longitude,
    place.latitude
  );

  updateLocationPanel(place);
}

Build the Address Search Form

The HTML can stay simple:

<form id="address-form">
  <input
    id="address-input"
    type="search"
    placeholder="Enter an address or place"
  />

  <button type="submit">
    Search
  </button>
</form>

And the JavaScript:

const form =
  document.querySelector(
    "#address-form"
  );

const input =
  document.querySelector(
    "#address-input"
  );

form.addEventListener(
  "submit",
  async event => {
    event.preventDefault();

    try {
      await searchAddress(
        input.value
      );
    } catch (error) {
      console.error(error);
    }
  }
);

Now users can search a city, street address, or place name.

Let Users Enter Coordinates Directly

Another important workflow is:

User already has coordinates
           ↓
Enters longitude + latitude
           ↓
Map opens that point
           ↓
Address is resolved

HTML:

<input
  id="longitude"
  type="number"
  step="any"
  min="-180"
  max="180"
  placeholder="Longitude"
/>

<input
  id="latitude"
  type="number"
  step="any"
  min="-90"
  max="90"
  placeholder="Latitude"
/>

<button id="lookup">
  Look up
</button>

JavaScript:

document
  .querySelector("#lookup")
  .addEventListener(
    "click",
    async () => {
      const longitude =
        Number(
          document
            .querySelector(
              "#longitude"
            )
            .value
        );

      const latitude =
        Number(
          document
            .querySelector(
              "#latitude"
            )
            .value
        );

      validateCoordinates(
        longitude,
        latitude
      );

      setMarker(
        longitude,
        latitude
      );

      focusLocation(
        longitude,
        latitude
      );

      const place =
        await reverseGeocode(
          longitude,
          latitude
        );

      updateLocationPanel(place);
    }
  );

Now we support two-way conversion:

Address → Coordinates

Coordinates → Address

Add Browser Geolocation

Users often want one more shortcut:

Where am I right now?

The browser Geolocation API can provide this.

function locateUser() {
  if (!navigator.geolocation) {
    throw new Error(
      "Geolocation is not supported"
    );
  }

  navigator.geolocation
    .getCurrentPosition(
      async position => {
        const {
          longitude,
          latitude
        } = position.coords;

        setMarker(
          longitude,
          latitude
        );

        focusLocation(
          longitude,
          latitude
        );

        const place =
          await reverseGeocode(
            longitude,
            latitude
          );

        updateLocationPanel(
          place
        );
      },
      error => {
        console.error(
          "Unable to get location:",
          error
        );
      }
    );
}

Connect it to a button:

<button id="locate-me">
  Locate me
</button>

document
  .querySelector("#locate-me")
  .addEventListener(
    "click",
    locateUser
  );

Always request location only after a clear user action.

Users should understand why location permission is being requested.

Use One Location State for Every Input Method

At this point we have several ways to select a location:

Address search
Coordinate input
Map click
Browser geolocation

A common mistake is writing independent UI logic for each workflow.

That quickly becomes difficult to maintain.

Instead, use one function.

let currentLocation = null;

async function selectLocation({
  longitude,
  latitude,
  address = null,
  moveMap = true
}) {
  validateCoordinates(
    longitude,
    latitude
  );

  let location = {
    longitude,
    latitude,
    address
  };

  if (!address) {
    const result =
      await reverseGeocode(
        longitude,
        latitude
      );

    location = {
      ...location,
      ...result
    };
  }

  currentLocation = location;

  setMarker(
    longitude,
    latitude
  );

  if (moveMap) {
    focusLocation(
      longitude,
      latitude
    );
  }

  updateCoordinateInputs(
    longitude,
    latitude
  );

  updateLocationPanel(
    location
  );

  return location;
}

Now a map click becomes:

map.on("click", event => {
  selectLocation({
    longitude:
      event.lngLat.lng,

    latitude:
      event.lngLat.lat,

    moveMap: false
  });
});

Address search becomes:

const place =
  await geocodeAddress(query);

await selectLocation(place);

And browser geolocation becomes:

await selectLocation({
  longitude:
    position.coords.longitude,

  latitude:
    position.coords.latitude
});

This architecture dramatically reduces duplicated code.

Keep Longitude and Latitude Inputs in Sync

Once a location changes, update the input fields:

function updateCoordinateInputs(
  longitude,
  latitude
) {
  document
    .querySelector(
      "#longitude"
    )
    .value =
      longitude.toFixed(6);

  document
    .querySelector(
      "#latitude"
    )
    .value =
      latitude.toFixed(6);
}

Notice again that rounding is done for presentation.

The internal state can keep the full numeric precision.

Build the Location Details Panel

A minimal result panel could contain:

<section id="place-details">
  <h2>Place details</h2>

  <p id="address"></p>

  <dl>
    <dt>Longitude</dt>
    <dd id="result-longitude"></dd>

    <dt>Latitude</dt>
    <dd id="result-latitude"></dd>
  </dl>
</section>

Update it:

function updateLocationPanel(
  location
) {
  document
    .querySelector("#address")
    .textContent =
      location.address ??
      "Address unavailable";

  document
    .querySelector(
      "#result-longitude"
    )
    .textContent =
      location.longitude
        .toFixed(6);

  document
    .querySelector(
      "#result-latitude"
    )
    .textContent =
      location.latitude
        .toFixed(6);
}

The same component works regardless of how the user selected the location.

Add Elevation as a Separate Data Layer

Once we have coordinates, we can query additional geographic data.

For example:

Selected point
     ↓
Longitude / Latitude
     ↓
Elevation API or dataset
     ↓
Estimated elevation

A frontend helper might look like:

async function getElevation(
  longitude,
  latitude
) {
  const params =
    new URLSearchParams({
      longitude,
      latitude
    });

  const response = await fetch(
    `/api/elevation?${params}`
  );

  if (!response.ok) {
    throw new Error(
      "Elevation lookup failed"
    );
  }

  return response.json();
}

Then:

const elevation =
  await getElevation(
    longitude,
    latitude
  );

console.log(
  `${elevation.meters} m`
);

One important UI detail:

don't imply that estimated terrain elevation is the same thing as high-precision surveyed altitude.

Always describe the accuracy of your source clearly.

Add Nearby Places as an Optional Extension

Once a user has selected a location, the same coordinates can power other features.

For example:

Selected coordinates
       ↓
Nearby search
       ↓
Restaurants
Hotels
Cafes
Attractions

This doesn't need to be part of the core coordinate finder.

I prefer treating it as a secondary action:

Find location
     ↓
Show coordinates + address
     ↓
Optional: explore nearby places

That keeps the primary workflow focused.

Handle Loading and Errors

Network requests fail.

Addresses can also return no results.

Location permission can be denied.

A real application should explicitly handle these states.

For example:

async function searchAddress(
  query
) {
  setLoading(true);

  try {
    const place =
      await geocodeAddress(query);

    if (!place) {
      showError(
        "No matching place found."
      );

      return;
    }

    await selectLocation(place);
  } catch (error) {
    showError(
      "Unable to search this address."
    );
  } finally {
    setLoading(false);
  }
}

Useful error states include:

Address not found

Invalid longitude

Invalid latitude

Location permission denied

Network unavailable

Geocoding service unavailable

Showing a clear message is better than silently doing nothing.

Avoid Exposing API Keys in the Browser

If your geocoding provider requires a private API key, don't embed that key directly in public frontend JavaScript.

Avoid:

const API_KEY =
  "my-secret-api-key";

Anything shipped to the browser should be considered visible to users.

A better setup is:

Frontend
   ↓
/api/geocode
   ↓
Backend
   ↓
External geocoding provider

Your server can:

protect credentials,
normalize responses,
add caching,
add rate limits,
switch providers later.

This also keeps the frontend code much cleaner.

A Simple Application Architecture

The final data flow might look like this:

              ┌─────────────────┐
              │ Address Search  │
              └────────┬────────┘
                       │
                       ▼
                   Geocoding

Map Click ─────────────┐
                      │
Coordinate Input ─────┼──→ selectLocation()
                      │
My Location ──────────┘
                            │
                            ▼
                 Longitude + Latitude
                            │
               ┌────────────┼────────────┐
               ▼            ▼            ▼
             Marker       Address     Elevation
               │
               ▼
            Map View

The key idea is simple:

Every interaction eventually becomes a longitude and latitude pair.

Once you have that pair, the rest of the application becomes a collection of optional geographic lookups.

Try a Real Longitude and Latitude Finder

I used this same interaction model while building CoordMap's Longitude and Latitude Finder.

The live tool lets you:

search an address for longitude and latitude,
enter longitude and latitude to find an address,
click directly on the map,
use your current location,
inspect location details,
and continue exploring geographic information around the selected point.

If you're building your own version, using a live map tool can also be useful for testing coordinates from different countries and hemispheres.

For example, try:

Washington, DC
38.9072, -77.0369

London
51.5074, -0.1278

Tokyo
35.6762, 139.6503

Sydney
-33.8688, 151.2093

These help test:

North + West
North + East
South + East

and reveal common latitude/longitude ordering mistakes.

What I Would Add Next

Once the core finder is reliable, several extensions become possible.

Coordinate format conversion

Display the same location as:

Decimal Degrees
40.7128, -74.0060

and:

DMS
40°42'46.08"N
74°00'21.60"W

Shareable locations

Generate a URL containing:

longitude
latitude
zoom

so users can send the selected point to someone else.

Distance measurement

Once you can select one coordinate, selecting two points allows you to calculate distance.

Additional coordinate systems

More advanced GIS applications may also need transformations between WGS84 and other coordinate reference systems.

The important thing is to build these on top of the same clean location state instead of creating separate implementations for every feature.

Final Thoughts

A longitude and latitude finder is a good example of a small application where UI design and data architecture matter just as much as the map itself.

The basic workflow is:

User selects a location
          ↓
Longitude + Latitude
          ↓
Validate coordinates
          ↓
Update marker and map
          ↓
Resolve address
          ↓
Display place details

From there, features such as elevation, nearby places, distance measurement, coordinate conversion, and sharing can all be added without changing the core model.

The most important implementation lessons are:

Treat longitude and latitude as the central state.
Keep map interactions and form inputs synchronized.
Validate coordinate ranges.
Keep numeric precision separate from display formatting.
Normalize geocoding responses.
Keep private API credentials on the server.
Handle permission and network errors explicitly.
Keep optional map features secondary to the main coordinate workflow.

Once those foundations are in place, building additional mapping tools becomes much easier.

DEV Community: Luo Atlas

How to Check and Fix Your Windows Clock: A Step-by-Step Guide

1. Open the clock checker

2. Read the result

3. Correct the clock in Windows

4. Check again

How to Get Your Current Location with JavaScript

Start with the browser's Geolocation API

Build a complete example

Choose options for your use case

Show accuracy alongside the coordinates

Put the location on a MapLibre map

Handle errors as part of the interface

Try the workflow in a map tool

Use the coordinates for the next step

How to Convert an Address to Latitude and Longitude with JavaScript

What Is Geocoding?

Basic JavaScript Example

Why encodeURIComponent() Matters

Building a Simple Address Search

Geocoding Results Are Often Ambiguous

Latitude and Longitude Order Can Be Confusing

Displaying the Result on a Map

What If an Address Cannot Be Found?

Avoid Geocoding the Same Address Repeatedly

Browser or Server?

Common Address-to-Coordinate Mistakes

1. Assuming the first result is always correct

2. Swapping latitude and longitude

3. Not encoding the address

4. Expecting every address to exist

5. Exposing private API keys

6. Sending a request on every keystroke

Testing Coordinates Manually

Final Thoughts

Why Is My Map Marker in the Wrong Place? 5 Coordinate Mistakes Developers Make

1. Latitude and longitude are in the wrong order

2. The numbers belong to a different coordinate reference system

3. You treated a formatted coordinate as a decimal number

4. A hemisphere or minus sign was lost

5. You expected an approximate location to be exact

A quick debugging checklist

Coordinates Are Usually the Beginning, Not the Answer

The Problem Is Not a Lack of Map Tools

Coordinates Should Be a Starting Point

Goal 1: One Page, One Clear Question

Goal 2: Connect Related Geographic Information

Goal 3: Make Geographic Data Understandable

Goal 4: Keep Common Tasks Browser-First

Goal 5: Be Useful to Both Users and Developers

An Important Design Constraint: Do Not Add Features Just Because You Can

What I Am Actually Building

The Broader Lesson

How to Open Latitude and Longitude in Google Maps, Apple Maps, and OpenStreetMap with JavaScript

1. Starting with Latitude and Longitude

2. Open Coordinates in Google Maps

3. Use the Google Maps Search URL Format

4. Open Coordinates in Apple Maps

5. Open Coordinates in OpenStreetMap

6. Let the User Choose a Map Provider

7. Get the User's Current Coordinates

8. A Reusable JavaScript Function

9. Validate Coordinates Before Opening the Map

10. Testing Coordinates Visually

Conclusion

Useful Links

A Practical Map Toolbox for Developers Working with Coordinates

The problem with debugging location data

Address → coordinates

Coordinates → address

Decimal coordinates vs DMS

Checking elevation

Finding nearby places

A small tool I built for this

Tools don't replace APIs

A Simple Longitude and Latitude Finder for Developers, Travelers, and Map Users

What can it do?

1. Find longitude and latitude from an address

2. Find an address from coordinates

3. Click anywhere on the map

Why `encodeURIComponent()` Matters