Write a Place Into a Note So Any Map Can Read It

To write a place into a note so any map can read it, write two decimal numbers, latitude first, in a bare link: [Eiffel Tower](geo:48.85837,2.294481). No space after the comma, no extra parameters. Flip to longitude first only inside a geojson block — the one common format that reverses the order.

Swap the two numbers and the pin moves. The Eiffel Tower lands in the Indian Ocean. The Statue of Liberty lands on the Antarctic ice sheet, in the wrong hemisphere — and in both cases nothing in the file looks wrong.

Knowledge organised by place has an audience. "Local Wikipedia: Wikipedia, but only for things a half hour walk from you" had 1,243 points on Hacker News by 24 October 2026, within two days of being posted¹. Note-takers already put notes on maps: three geographic map plugins in Obsidian's community registry — Leaflet, Map View and Obsidian's own Maps — count 563,941 downloads between them². They do not all read the same property.

This reference lists each common way to write a place in a plain-text note, which tool reads it, the order it expects, and how many digits to keep. Each quote and figure is footnoted to its source — a standard, a tool's own documentation, or a test run — as of 24 October 2026.

What a place is, in a plain-text file

A place in a plain-text file is two decimal numbers plus an agreement about their order. Latitude runs north to south, from −90 to 90. Longitude runs east to west, from −180 to 180. Both are degrees on the WGS 84 datum. Write the numbers without settling the order, and the file says nothing reliable.

The geo: URI standard, RFC 5870, spells out the default. Its authors write: "The scheme provides the textual representation of the location's spatial coordinates in either two or three dimensions (latitude, longitude, and optionally altitude for the default CRS of WGS-84)."³ Its first example is a single line:

geo:13.4125,103.8667

Latitude first, then a comma, then longitude — nothing else is required.

The numbers are the easy part. The order — and the property name around them — is where a note stops being readable by the next tool.

Every format at a glance

Nine formats cover almost every place you will meet in a note, a calendar file or a phone link. Eight put latitude first. One — GeoJSON — puts longitude first. The separator changes too: a comma in most, a semicolon in iCalendar, a JSON array in GeoJSON. The property name changes with every tool.

Each row is sourced in its own section below — the tool's documentation, or a test run where the documentation is silent.

The table is not a ranking — it records which reader looks where. The same pattern, one value under a different name in every tool, governs a note's title too; Filename, H1, or Front Matter? Where Each Tool Reads Your Note's Title maps it for titles.

The coordinate order that puts a place in the wrong hemisphere

Swap latitude and longitude and the place moves, often by thousands of kilometres, and often without an error. The geo: standard names the mistake directly. GeoJSON, the format GitHub draws maps from, stores the pair in the opposite order — so copying numbers between a GeoJSON file and a note is the easiest way to make it.

RFC 5870's interoperability section is blunt: "Authors of 'geo' URIs should carefully check that coordinate components are set in the right CRS and in the specified order, since the wrong order of those components (or use of coordinates in a different CRS without transformation) are commonly observed mistakes producing completely bogus locations."³

GeoJSON's standard, RFC 7946, fixes the reverse: "The first two elements are longitude and latitude, or easting and northing, precisely in that order and using decimal numbers."⁴

Tom MacWright, who maintains a reference page on exactly this split, puts it in one line: "Geospatial software has a fundamental inconsistency: which order we put longitude and latitude in."⁵ He is also honest that neither side is wrong: "Which is right? Neither. This is an opinion with no right answer. Geographical tradition favors lat, lon. Math and software prefer lon, lat."⁵

Where a swapped pair lands

MacWright's own example: "One choice places a point on Chicago, and the other a location deep in Antarctica."⁵ The same arithmetic, run on four real pairs:

Distances are great-circle figures from the haversine formula⁶.

Why some swaps fail silently and some do not

A swap produces a valid-looking point whenever the longitude is between −90 and 90. Paris (2.29 E) and New York (74.05 W) swap into points no validator can object to. Seattle (122.3 W) swaps into a latitude that cannot exist, so a reader that validates its input can catch it.

On GIS Stack Exchange, the user whuber gives the quick check: "A nonzero hundreds digit tells us we're using longitude, not latitude!"⁷

So whether an error is even possible depends on where the place is — not on how careful you were. Most of Europe, Africa and the Americas east of 90 W swap into valid points.

Not every reader validates, either. Map View's inline parser, at commit e6e0430, accepted [Eiffel Tower](geo:2.294481,48.85837) in a test run without complaint⁸. The file was well formed. The place was in the sea.

Format 1: a bare geo: link, latitude first

A geo: link is the most portable way to write a place in a note's body. It is a standard URI, latitude first, and it means the same to every reader that knows the scheme. Keep it bare — two numbers, one comma, no space, no parameters — because tools that read it inline are stricter than the standard.

[Eiffel Tower](geo:48.85837,2.294481)

Map View's documentation describes the form: "Inline locations use the format [link-name](geo:lat,lng) and allow multiple markers in the same note."⁹ It adds a condition: "To use inline locations, the note must have a locations: tag in its front matter (note: locations, not location)."⁹

---
locations:
---
Lunch: [Eiffel Tower](geo:48.85837,2.294481)

What the strict parser rejects

The standard allows more than the tools read. A test of Map View's inline pattern at commit e6e0430, run on 24 October 2026, gave these results⁸:

[Eiffel Tower](geo:48.85837,2.294481)        match
[Eiffel Tower](geo:48.85837, 2.294481)       no match  (space after comma)
[Eiffel Tower](geo:48.85837,2.294481;u=10)   no match  (uncertainty parameter)
[Eiffel Tower](geo:48.8584,2.2945)           match     (fewer digits are fine)
[Eiffel Tower](geo:2.294481,48.85837)        match     (swapped, and silent)

A single space is enough to lose the pin — standard-legal is not the same as tool-readable.

What GitHub shows

On GitHub the coordinates vanish from the rendered page. GitHub's Markdown API, given [Eiffel Tower](geo:48.85837,2.294481) on 24 October 2026, returned only the words Eiffel Tower — no link, no numbers¹⁰. The angle-bracket form <geo:48.85837,2.294481> came back as visible plain text.

The file still holds the pair — a reader of the rendered page just never sees it. If a note will be read on GitHub, write the pair where a reader can see it too:

[48.85837,2.294481](geo:48.85837,2.294481) — Eiffel Tower

Format 2: a front-matter property, named for the tool

A front-matter property suits a note that is a place — a café, a trailhead, a site visit. Every map tool documented here agrees on latitude first. They disagree on the property's name and shape: Map View reads location, Obsidian's official Maps plugin reads whichever property you choose.

Front matter itself, the block between three dashes, is covered in The Three Dashes at the Top of Your Note.

Map View

Map View's documentation leads with a single line, no brackets⁹:

---
location: 40.6892494,-74.0466891
---

It also accepts an older form: "The older array format (compatible with obsidian-leaflet) is also supported:"⁹

---
location: [40.6892494, -74.0466891]
---

The same page says the first form "is encouraged for Obsidian 1.4 and above"⁹. Use it.

Obsidian Maps

Obsidian's official Maps plugin draws a map view inside Bases, and "Map views require Obsidian 1.10."¹¹ Its help page stores the Eiffel Tower as a two-item list and states the rule: "Coordinates are stored as latitude, longitude."¹¹

---
coordinates:
  - "48.85837"
  - "2.294481"
---

The text form is accepted too. "The property must contain latitude and longitude coordinates."¹¹

coordinates: "48.85837, 2.294481"

Same order, different names. Map View looks for a property called location; Obsidian Maps reads whichever property you select in the view's settings — so check that the one you select holds the pair in a form its help page lists: a two-item list, or "lat, lng" text.

The case for not typing coordinates at all

Map View's authors give the opposite advice to this whole article: "The best way to use Map View is to never enter geolocations manually — let the plugin handle it."⁹ It is good advice — a pair copied from a map's own menu cannot be swapped by a tired hand.

If you live in one tool, follow it. The point here is narrower. Whatever writes the pair, the file has to carry it in a form the next reader recognises — and that reader may be a different app, years later.

Format 3: a geojson block, longitude first

A fenced geojson block is the one common place format that puts longitude first. GitHub reads it, and Map View's source defines a pattern for geojson blocks too⁸. Use it when a note needs a shape — a route, an area — or when the file will live on GitHub. Inside the block, reverse the pair.

GitHub's documentation gives the syntax: "To create a map, add GeoJSON or TopoJSON inside a fenced code block with the geojson or topojson syntax identifier."¹²

```geojson
{
  "type": "Point",
  "coordinates": [2.294481, 48.85837]
}
```

Read the array aloud: 2.29 east, 48.86 north. That is the Eiffel Tower — but only because GeoJSON reads it longitude first⁴.

GeoJSON also fixes its datum. RFC 7946 says its coordinates are WGS 84 in decimal degrees, equivalent to the Open Geospatial Consortium's CRS84 — and, as above, written longitude first⁴. The standard dropped custom coordinate systems on purpose: they had "proven to have interoperability issues."⁴

The same fence family carries diagrams, which The Flowchart You Can Diff covers.

A habit that prevents the swap: when you paste a pair into a geojson block, write the place's name on the line above it, then read the array back — east first, then north — before saving.

Calendar and contact files carry places too

Places also live in calendar and contact files, and both standards put latitude first. They differ in the separator. A vCard 4 contact wraps a full geo: URI, comma and all. An iCalendar event uses a semicolon. Copy a pair between them without changing the separator, and the line breaks the other standard.

vCard 4, RFC 6350, defines a GEO property and recommends the URI form: "The "geo" URI scheme [RFC5870] is particularly well suited for this property, but other schemes MAY be used."¹³

GEO:geo:37.386013,-122.082932

The doubled GEO:geo: is correct. The first is the property name; the second begins the URI. Keeping contacts as plain text more broadly is the subject of How to Keep Your Contacts in Plain Text.

iCalendar, RFC 5545, is older and stricter: "This property value specifies latitude and longitude, in that order (i.e., "LAT LON" ordering)." And: "The value MUST be two SEMICOLON-separated FLOAT values."¹⁴

GEO:37.386013;-122.082932

The same point — two syntaxes, one character apart.

Opening a place on a phone

On Android, a geo: link is documented: an app can open the map at a latitude and longitude. Apple's current Maps URL documentation does not mention geo: at all; it documents its own maps.apple.com URLs for iOS 18.4 and later. Neither is a reason to change how the note stores the pair.

Android's developer guide lists geo:latitude,longitude as the syntax, with this example and a zoom variant¹⁵:

geo:47.6,-122.3
geo:47.6,-122.3?z=11
geo:0,0?q=34.99,-106.61(Treasure)

The third form drops a labelled marker. Zoom has a ceiling: "The highest (closest) zoom level is 23."¹⁵

One small illustration of how easily the order slips. Android's guide writes the syntax latitude first — yet its description of that same row reads: "Show the map at the given longitude and latitude."¹⁵ The syntax is right — the sentence beside it says the words the other way round.

Apple's page describes a newer scheme: "In iOS 18.4 and later, macOS 15.4 and later, and watchOS 11.4 and later, the Maps platform provides a new, unified collection of URLs that offers the same functionality on all devices."¹⁶ Its center parameter takes a "comma-separated coordinate pair", latitude first:

https://maps.apple.com/frame?center=40.753035,-73.981846

What an iPhone does when you tap a geo: link is not described in that documentation. Test it on your own device before relying on it.

How many decimal places to write

Four or five decimal places are enough for almost any note. Each extra digit makes the place ten times finer: three decimals is about a neighbourhood block, four is a building, six is about ten centimetres. More digits than your source had add no accuracy — and the standard says digits must not be read as a statement of uncertainty.

One decimal place of latitude is worth a fixed distance anywhere on Earth. Longitude shrinks toward the poles, so the latitude figure is the upper bound⁶:

At the Eiffel Tower's latitude, four decimals of longitude is about 7.3 m.

whuber's answer to the question — viewed more than 620,000 times — puts the fourth decimal in plain words: "The fourth decimal place is worth up to 11 m: it can identify a parcel of land."⁷

Two standards, two answers for six digits

The standards disagree about six decimals. RFC 7946 says: "For geographic coordinates with units of degrees, 6 decimal places (a default common in, e.g., sprintf) amounts to about 10 centimeters, a precision well within that of current GPS systems."⁴ RFC 5545, the calendar standard, says six places "will allow for accuracy to within one meter of geographical position."¹⁴

The arithmetic sides with RFC 7946: 0.000001° of latitude is 0.111 m⁶. Treat "six decimals is one metre" as folklore.

Extra digits also cost space. "A GeoJSON text containing many detailed Polygons can be inflated almost by a factor of two by increasing coordinate precision from 6 to 15 decimal places."⁴

Digits are not a precision claim

Rounding removes information — but adding digits does not state certainty. RFC 5870 is explicit: "Note: The number of digits of the values in MUST NOT be interpreted as an indication to the level of uncertainty."³

whuber makes the human version of the point: "Using too much precision can mislead people into believing the accuracy is greater than it really is."⁷

The standard's way to state fuzziness is a parameter: "The 'u' ("uncertainty") parameter indicates the amount of uncertainty in the location as a value in meters."³ RFC 5870's own example carries one:

geo:48.198634,16.371648;crs=wgs84;u=40

It is valid — and Map View's inline parser will not read it⁸. In a note, keep the link bare and write the uncertainty in words beside it.

Round the place before you share the note

A coordinate in a shared note can point to a home. Round it before the note leaves your hands: three decimals, about 111 metres, says "this neighbourhood"; four, about 11 metres, says "this café." Leave home addresses out of shared notes entirely. Coarser locations put a person in a far larger crowd.

The geo: standard flags the shift itself. When a URI identifies where someone is, "it becomes part of a Location Object and is therefore subject to GEOPRIV rules."³

Evidence for rounding comes from a 2009 study of home and work locations. Philippe Golle and Kurt Partridge, at PARC, found that "the median size of the individual’s anonymity set in the U.S. working population is 1, 21 and 34,980, for locations known at the granularity of a census block, census track [sic] and county respectively."¹⁷

The scope matters. The paper measures a pair of places — home and workplace — not a single pin in one note. Its lesson is about granularity. Coarser locations hide people in larger crowds, and very fine ones can leave a crowd of one.

The authors' own advice transfers directly: "To minimize privacy concerns, the best practice is to collect the minimum amount of information needed."¹⁷

# private note — full precision
location: 48.85837,2.294481

# shared note — rounded to about 111 m
location: 48.858,2.294

The rule

Write decimal degrees, latitude first, as a bare geo: link or a front-matter property — and flip to longitude first only inside a geojson block. Keep no spaces and no parameters in the link, write the pair visibly if GitHub will render it, and round it before the note is shared.

The same rule as five checks, one per failure shown above:

1. Is the first number between -90 and 90?        catches: most swaps
2. Is it longitude-first ONLY inside geojson?     catches: the hemisphere flip
3. No space after the comma, no ;u= in the link?  catches: missing pins
4. Can a reader of the rendered page see it?      catches: GitHub dropping the link
5. Rounded to 3-4 decimals in shared notes?       catches: a home at 10 cm

If the pair passes all five, the next map you open will put it where you stood.

Frequently Asked Questions

These seven questions are taken verbatim from Stack Exchange, Stack Overflow and the Obsidian forum, where people asked them in exactly these words. Each answer stays inside what the standards and documentation above actually say — no tool behaviour beyond what was tested — and each fits in a paragraph you can paste into a note.

Is SRID 4326 Lon/Lat or Lat/Lon?

It depends on the format, not the datum. The same WGS 84 coordinates are written latitude first in a geo: URI (RFC 5870) and longitude first in GeoJSON (RFC 7946), which describes its system as equivalent to OGC's CRS84. Tom MacWright's summary: geographic tradition favours lat, lon; software favours lon, lat.

Measuring accuracy of latitude and longitude

Each decimal place of latitude is ten times finer: about 111 m at three places, 11 m at four, 1.1 m at five, 0.11 m at six. Longitude steps shrink toward the poles. RFC 7946 puts six decimals at about 10 centimetres. More digits than your source had do not add accuracy.

ogr2ogr specify lat/long order on conversion to GeoJSON

GeoJSON has no option here: RFC 7946 requires longitude first, then latitude, "precisely in that order." Any conversion to GeoJSON must emit [lon, lat]. Check the output by reading one known point aloud, east value first. If a European city appears near the equator, the input order was misread.

Limiting decimal places of coordinate values in GEOJSON file using QGIS?

Whichever tool exports the file, six decimal places is the standard's own yardstick: RFC 7946 says six places is about 10 centimetres, and that going from 6 to 15 places can nearly double the size of a file full of detailed polygons. For notes, four or five decimals are enough.

Detecting geo-uri-support

Android documents geo: links: its developer guide lists geo:latitude,longitude as a map intent. Apple's current Maps URL documentation does not mention geo:; it documents maps.apple.com URLs for iOS 18.4 and later. Store the pair as a geo: link in the note, and test on the actual device.

How do I show a marker in Maps launched by geo URI Intent?

Android's developer guide documents the form geo:0,0?q=lat,lng(label), with the example geo:0,0?q=34.99,-106.61(Treasure). The plain geo:47.6,-122.3 form centres the map on a point; the q= form places a labelled marker there instead. Both put latitude first, and the guide sets the highest zoom level at 23.

Bases and maps, automatic coordinates

Obsidian's help page for the Maps plugin says you can get coordinates by right-clicking a location on the map and choosing Copy coordinates, which avoids typing them. It stores them latitude first, as a list or a "lat, lng" text property. Map View's documentation gives the same advice: let the plugin write the numbers.

A place is two numbers and an order. Write the order down, and the place outlives every map you will ever open it in.

MNMNOTE keeps notes as plain Markdown on your own device, so a place written this way stays readable in any text editor that opens the file. mnmnote.com

References