DEV Community: Luo Atlas

How to Convert DMS to Decimal Degrees in JavaScript

Luo Atlas — Sun, 25 Oct 2026 08:48:05 +0000

GPS coordinates do not always arrive in the format your application expects. A user might paste a location like this:

40°26′46″N, 79°58′56″W

Before using those coordinates in a map or an API request, you may need to convert them into decimal degrees:

40.446111, -79.982222

In this tutorial, we will build a JavaScript converter, validate its inputs, and parse common DMS strings.

Understanding the Conversion

DMS stands for degrees, minutes, and seconds:

One degree contains 60 minutes.
One minute contains 60 seconds.
One degree therefore contains 3,600 seconds.

The conversion formula is:

decimal degrees = degrees + minutes / 60 + seconds / 3600

For example:

40°26′46″N
= 40 + 26 / 60 + 46 / 3600
≈ 40.446111°

The hemisphere determines the sign:

Direction	Coordinate	Sign
N	Latitude	Positive
S	Latitude	Negative
E	Longitude	Positive
W	Longitude	Negative

For west longitude, calculate the complete value first and then make it negative:

79°58′56″W
= -(79 + 58 / 60 + 56 / 3600)
≈ -79.982222°

Create a JavaScript Conversion Function

The following function accepts numeric DMS components and a hemisphere letter:

function dmsToDecimal(degrees, minutes, seconds, direction) {
  if (![degrees, minutes, seconds].every(Number.isFinite)) {
    throw new TypeError("DMS components must be finite numbers.");
  }

  if (typeof direction !== "string") {
    throw new TypeError("Direction must be N, S, E, or W.");
  }

  const hemisphere = direction.trim().toUpperCase();

  if (!["N", "S", "E", "W"].includes(hemisphere)) {
    throw new RangeError("Direction must be N, S, E, or W.");
  }

  if (!Number.isInteger(degrees) || degrees < 0) {
    throw new RangeError("Degrees must be a non-negative integer.");
  }

  if (!Number.isInteger(minutes) || minutes < 0 || minutes >= 60) {
    throw new RangeError("Minutes must be an integer from 0 to 59.");
  }

  if (seconds < 0 || seconds >= 60) {
    throw new RangeError("Seconds must be at least 0 and less than 60.");
  }

  const limit = ["N", "S"].includes(hemisphere) ? 90 : 180;
  const decimal = degrees + minutes / 60 + seconds / 3600;

  if (decimal > limit) {
    throw new RangeError(
      `Coordinate exceeds the ${limit}-degree limit.`
    );
  }

  const sign = ["S", "W"].includes(hemisphere) ? -1 : 1;

  // Normalize zero so the function does not return -0.
  return decimal === 0 ? 0 : decimal * sign;
}

This function uses unsigned degrees and a separate direction. Enter 79 and "W", rather than -79 and "W". Keeping one source for the sign avoids ambiguity.

Number.isFinite() checks that each component is a number and rejects NaN and infinity. It also rejects numeric strings, so convert form values explicitly before calling the function.

Example Usage

const latitude = dmsToDecimal(40, 26, 46, "N");
const longitude = dmsToDecimal(79, 58, 56, "W");

console.log(latitude.toFixed(6));  // "40.446111"
console.log(longitude.toFixed(6)); // "-79.982222"

Decimal seconds work too:

const latitude = dmsToDecimal(40, 26, 46.5, "N");
console.log(latitude.toFixed(6)); // "40.446250"

The function returns a number. Use toFixed() when formatting the result for display, and keep the original numeric value for further calculations.

Parse a DMS Coordinate String

If users paste coordinates into a text field, you also need to extract the individual components.

The parser below supports these formats:

40°26′46″N
40° 26' 46" N
40 26 46 N
40°26′46.5″N

It requires all three components and a direction at the end.

function parseDms(input) {
  if (typeof input !== "string") {
    throw new TypeError("Coordinate must be a string.");
  }

  const normalized = input
    .trim()
    .replace(/[′’]/g, "'")
    .replace(/[″”]/g, '"');

  const patterns = [
    // Symbol-separated: 40° 26' 46" N
    /^(\d{1,3})\s*°\s*(\d{1,2})\s*'\s*(\d{1,2}(?:\.\d+)?)\s*"\s*([NSEW])$/i,

    // Space-separated: 40 26 46 N
    /^(\d{1,3})\s+(\d{1,2})\s+(\d{1,2}(?:\.\d+)?)\s*([NSEW])$/i
  ];

  let match;

  for (const pattern of patterns) {
    match = normalized.match(pattern);
    if (match) break;
  }

  if (!match) {
    throw new Error("Invalid DMS format. Try 40 26 46 N.");
  }

  const [, degrees, minutes, seconds, direction] = match;

  return dmsToDecimal(
    Number(degrees),
    Number(minutes),
    Number(seconds),
    direction
  );
}

Use it with the conversion function defined earlier:

console.log(parseDms("40°26′46″N").toFixed(6));
// "40.446111"

console.log(parseDms("79°58′56″W").toFixed(6));
// "-79.982222"

console.log(parseDms("33 51 31 S").toFixed(6));
// "-33.858611"

The parser intentionally accepts a limited set of formats. Inputs such as N 40°26′46″, signed degrees, or coordinates with missing seconds require additional parsing rules.

Convert a Latitude and Longitude Pair

For an application, separate latitude and longitude fields make validation easier.

This wrapper verifies that each field uses the correct direction:

function parseDmsPair(latitudeInput, longitudeInput) {
  if (
    typeof latitudeInput !== "string" ||
    typeof longitudeInput !== "string"
  ) {
    throw new TypeError("Both coordinates must be strings.");
  }

  if (!/[NS]$/i.test(latitudeInput.trim())) {
    throw new Error("Latitude must end with N or S.");
  }

  if (!/[EW]$/i.test(longitudeInput.trim())) {
    throw new Error("Longitude must end with E or W.");
  }

  return {
    latitude: parseDms(latitudeInput),
    longitude: parseDms(longitudeInput)
  };
}

Example:

const location = parseDmsPair(
  "40°26′46″N",
  "79°58′56″W"
);

console.log(location);
// {
//   latitude: 40.44611111111111,
//   longitude: -79.98222222222222
// }

Named properties help keep latitude and longitude distinct when passing the result between functions.

Common Conversion Mistakes

Applying the Negative Sign Only to Degrees

This calculation is incorrect for west longitude:

const longitude = -79 + 58 / 60 + 56 / 3600;

It adds the minutes and seconds to a negative degree value. Apply the sign to the entire magnitude instead:

const longitude = -(79 + 58 / 60 + 56 / 3600);

Treating DMS as a Decimal Number

This is incorrect:

40°26′46″ → 40.2646

Minutes and seconds are base-60 subdivisions. They must be divided by 60 and 3600, respectively.

Accepting Out-of-Range Values

These inputs should be rejected:

40°60′00″N
40°26′60″N
90°00′01″N
180°00′01″E

Latitude can reach 90 degrees and longitude can reach 180 degrees, but neither can exceed its limit. At those boundaries, minutes and seconds must both be zero.

Confusing Format Conversion with CRS Conversion

Converting DMS to decimal degrees changes how a coordinate is written. It does not transform the coordinate into a different coordinate reference system.

If your source data uses a different datum or CRS from your map, changing its notation alone will not resolve the mismatch.

Rounding Too Early

Keep the full numeric result during calculations:

const latitude = parseDms("40°26′46.5″N");

// Format only when displaying the value.
const label = latitude.toFixed(6);

Showing more decimal places does not improve the accuracy of the original measurement.

Check a Coordinate Before Using It

After converting a coordinate, inspect its position on a map. This can reveal a missing negative sign, swapped fields, or a transcription error that still passes numeric validation.

For a quick visual check, you can use the CoordMap Latitude and Longitude Finder.

The essential steps are straightforward: convert minutes and seconds into fractions of a degree, apply the hemisphere sign to the complete result, and validate the coordinate before using it.

How to Find a Time Zone from Latitude and Longitude

Luo Atlas — Sat, 17 Oct 2026 06:57:53 +0000

You have a pair of GPS coordinates, but your application needs more than a marker on a map. Perhaps you want to display the local time at a destination, label a weather observation, or help someone choose a time to call.

How do you turn latitude and longitude into a time zone?

There are two parts to the task: identify the time zone for the location, then use that zone to display the time for a particular date. Keeping those steps separate helps avoid common daylight saving time bugs.

What should a time zone lookup return?

Consider this coordinate pair in New York City:

Latitude:   40.7128
Longitude: -74.0060

The useful result is a named time zone such as America/New_York, together with the local time and UTC offset for the date you are checking.

These values describe different things:

Value	Example	Meaning
Coordinates	`40.7128, -74.0060`	The location on Earth
Time zone identifier	`America/New_York`	The named zone used by date and time software
UTC offset	`UTC−04:00`	The difference from UTC at a particular instant
Local date and time	`July 15, 2026, 8:00 AM`	How that instant is displayed in the selected zone

The IANA Time Zone Database maintains rules for local time, including changes to UTC offsets and daylight saving time. A zone identifier lets software select the relevant rules; a fixed offset alone does not capture them.

Check a time zone without writing code

For an individual lookup, you can use the CoordMap latitude and longitude finder. I built this tool to bring coordinates and useful location details together in one place.

1. Enter the coordinates

Put 40.7128 in the latitude field and -74.0060 in the longitude field, then select Look up.

The negative longitude means west of the prime meridian. Dropping that minus sign selects a different location.

If your source uses degrees, minutes, and seconds or degrees and decimal minutes, the finder also accepts DMS and DDM input. Check that each value is assigned to the correct field.

2. Confirm the point on the map

Before using the time zone result, make sure the map shows the place you intended. Reversed coordinates or an incorrect direction letter can produce a valid-looking result for the wrong location.

You can also search for an address or select a point directly on the map.

3. Read the time zone details

The result panel shows the selected point's IANA time zone name, current local date and time, and current UTC offset when those details are available.

For a recognized time zone, a linked detail page is also available. Keep in mind that the displayed current offset describes the current date. A trip or appointment in another season may use a different offset.

Why dividing longitude by 15 is not enough

Earth rotates approximately 15 degrees per hour, so longitude can help estimate solar time. Civil time follows rules set by governments, and real time zone boundaries do not form a simple set of equal longitude strips.

This calculation therefore cannot reliably identify the legal time zone of a location:

// A rough geographic estimate, not a civil time zone lookup.
const estimatedOffsetHours = longitude / 15;

For an application, use a service or geographic boundary dataset that maps coordinates to named time zones. Then apply the rules for the date you need.

Display the result with JavaScript

Once you know the zone identifier, JavaScript's Intl.DateTimeFormat can display an instant in that zone:

function formatLocalTime(timeZone, instant = new Date()) {
  if (!(instant instanceof Date) || !Number.isFinite(instant.getTime())) {
    throw new TypeError("Provide a valid Date.");
  }

  return new Intl.DateTimeFormat("en-US", {
    timeZone,
    year: "numeric",
    month: "short",
    day: "numeric",
    hour: "numeric",
    minute: "2-digit",
    hour12: true,
    timeZoneName: "shortOffset",
  }).format(instant);
}

const instant = new Date("2026-07-15T12:00:00Z");

console.log(formatLocalTime("America/New_York", instant));
// Example: Jul 15, 2026, 8:00 AM GMT-4

console.log(formatLocalTime("Asia/Tokyo", instant));
// Example: Jul 15, 2026, 9:00 PM GMT+9

Both lines display the same instant. The formatter changes its local representation according to the selected zone. Exact punctuation can vary between runtimes.

The Z in the input timestamp explicitly identifies UTC. You do not need to add an offset to the Date before formatting it.

See the MDN documentation for Intl.DateTimeFormat for additional formatting options.

Intl.DateTimeFormat does not accept latitude and longitude. You must resolve coordinates to a zone identifier separately. Also, resolvedOptions().timeZone reports the runtime's configured time zone, which may differ from the selected map location.

Check daylight saving time for the date you need

A location can keep the same named time zone while its UTC offset changes during the year.

For example, compare New York at two UTC instants:

const winter = new Date("2026-01-15T12:00:00Z");
const summer = new Date("2026-07-15T12:00:00Z");

console.log(formatLocalTime("America/New_York", winter));
// Example: Jan 15, 2026, 7:00 AM GMT-5

console.log(formatLocalTime("America/New_York", summer));
// Example: Jul 15, 2026, 8:00 AM GMT-4

For a scheduled event, retain its time zone identifier and calculate the display for the event date. Avoid reusing today's offset for every future date. Keep your runtime's time zone data current as rules can change.

What if you need an automated coordinate lookup?

For a backend integration, the Google Time Zone API accepts coordinates and a timestamp and returns a time zone identifier plus offset information.

Its request documentation specifies the coordinate order as latitude,longitude and the timestamp in Unix seconds. JavaScript's Date.now() returns milliseconds, so convert it with Math.floor(Date.now() / 1000).

Google's setup guide covers account and billing requirements, enabling the API, and configuring a key. Keep a server-side service key on your backend and restrict its use appropriately.

Handle unavailable results explicitly, particularly for points over water. Also check the provider's historical coverage: Google's documentation notes that its lookup does not account for a location having belonged to a different time zone in the past.

Common mistakes to avoid

Swapping latitude and longitude. Some map libraries use [longitude, latitude]; a lookup service may expect the opposite order.
Saving only an abbreviation. Labels such as CST can be ambiguous. Retain the full zone identifier.
Using the device's offset for a remote point. getTimezoneOffset() describes the runtime's local zone for that date, not a selected coordinate.
Applying the offset twice. Pass the original instant to Intl.DateTimeFormat with the target zone.
Treating current local time as a scheduling conversion. Converting an instant to local time is straightforward. Turning a user-entered local appointment into an instant also requires handling missing or repeated times around daylight saving transitions.

When building a location panel, give the time zone identifier, local date and time, and UTC offset separate labels. That makes the result easier to understand and helps users check that they are looking at the intended place and date.

References

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

DEV Community: Luo Atlas

How to Convert DMS to Decimal Degrees in JavaScript

Understanding the Conversion

Create a JavaScript Conversion Function

Example Usage

Parse a DMS Coordinate String

Convert a Latitude and Longitude Pair

Common Conversion Mistakes

Applying the Negative Sign Only to Degrees

Treating DMS as a Decimal Number

Accepting Out-of-Range Values

Confusing Format Conversion with CRS Conversion

Rounding Too Early

Check a Coordinate Before Using It

How to Find a Time Zone from Latitude and Longitude

What should a time zone lookup return?

Check a time zone without writing code

1. Enter the coordinates

2. Confirm the point on the map

3. Read the time zone details

Why dividing longitude by 15 is not enough

Display the result with JavaScript

Check daylight saving time for the date you need

What if you need an automated coordinate lookup?

Common mistakes to avoid

References

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

Why `encodeURIComponent()` Matters