Obsidian Map View: turning a notes vault into a personal map

The map is a view over your notes, not a separate database

The plugin describes itself as an interactive map plugin for Obsidian.md that transforms your notes into a personal geographic information system, and the What It Does section gives the mechanism in one sentence: Map View searches your notes for geolocations and paths, places them on an interactive map, and gives you tools to interact with them.

That is the whole architectural idea, and it is a good one. The alternative approach, which most mapping tools take, is that you maintain a separate file of locations, or you import from a service, and the notes and the map drift apart. Here the notes are the source of truth, and the map is derived. There is no synchronisation problem because there is only one copy of the data.

The features that follow from that are legible in the list. You can add locations from a search, from the map, from external mapping services, or from your device's GPS, and all four routes end up as something in your notes. You can view paths in GeoJSON, GPX, KML and TCX formats. You can draw locations and shapes on the map using Edit Mode. You can calculate routes between points by driving, cycling or walking.

The formatting support is worth noting because it is broader than the usual coordinates pair. GeoJSON, GPX, KML and TCX are the interchange formats of the running and cycling worlds, and a plugin that reads all four can consume tracks exported from a fitness app as readily as a pin dropped into a note.

The primary language on the project record is TypeScript, the licence is MIT, and the default branch is master.

Display rules are how you style a map without writing code

Two features stand out as the ones that separate this from a simple pin plotter.

The first is display rules, which let you customise marker icons, badges, colors and path styles. The point of a rules system is that you write a condition and an appearance, and the plugin applies it to everything matching, rather than you styling each marker by hand or writing a script. For a vault with hundreds of locations, that is the difference between a map you maintain and a map that maintains itself.

The second is the query language, described as a boolean query language for querying and filtering markers. A boolean language means you can express things like this location and not this category, and the same query syntax you would use in a search box applies to the map. If a vault has a taxonomy of tags, the map can be filtered by the same metadata the rest of Obsidian filters by, which means the map and the note list stay in agreement about what exists.

The third capability, embedding live maps in notes, is what makes the plugin part of a note-taking workflow rather than a separate application. You can put a map of one region inside the note that talks about that region, and the map is live rather than a screenshot.

The remaining features are small but real. Save maps for offline usage, which matters if you are reading notes in a place with no signal. Integrate with Obsidian Bases, which is Obsidian's own table view over a set of notes, and the integration means the map can draw from the same structured view that the rest of the plugin ecosystem reads. And the Edit Mode capability is what lets a location be created by clicking on the map rather than by typing a coordinate into a note.

Installation is one click, and the build is a rollup project

The installation instruction is short enough to state in full. Install Map View from the Obsidian Community Plugins store, search for Map View and click Install.

That path also means the plugin follows Obsidian's own update cycle, which removes the usual step of copying files into a plugins folder and reloading the app. The downside is that you take the community store's version rather than a build of your own, so a fork means either an unofficial plugin or a local build.

The repository is where the source lives, and the package manifest shows how it is assembled. The package is obsidian-map-view at version 6.1.4, with main pointing at main.js and the type set to module, which is the shape Obsidian expects for a plugin that ships a single bundled entry point.

The bundling is Rollup, with a config file at rollup.config.js. The build script runs rollup with a production environment flag, the dev script runs the same config in watch mode with a development flag, and there is a separate dev-dist script that watches without the environment flag, which is presumably how a development build gets written somewhere a local Obsidian install can load it.

The rest of the tooling is modern and conventional. Tests run under Vitest, with a vitest.config.ts in the repository and both jsdom and a browser mode dependency present. Formatting is Prettier with a Svelte plugin, since Obsidian's UI is built in Svelte. There is a lefthook.yml and a prepare script that runs lefthook install, so the git hooks are set up on install.

The dependency list is a reasonable map of what the plugin is built from. Leaflet and its marker cluster types are there for the map itself, GeoJSON types for the data, the Google Maps API loader for the external mapping services, and the CodeMirror packages for the note editor integration.

The documentation structure tells you what a user actually has to learn

The README is short and its structure tells you how the project expects to be used.

There is a full documentation site at esm7.github.io/obsidian-map-view, and the README links five specific pages: a Quick Start, a Location Formats page, a Queries page, a Display Rules page and a Changelog.

Two of those five are the learning curve. Location Formats is where you find out how the plugin parses what you write in a note, and that is the part that determines whether the plugin works for you. If your notes contain coordinates in a form the plugin does not recognise, the map will be empty and no amount of configuration elsewhere will fix it. Queries and Display Rules are the two pages you return to once the map has content, because they are where the styling and the filtering live.

The Changelog being linked from the README rather than buried is a good sign for a project where the version number matters. The recent releases are 6.1.4 on 2026-03-22, 6.1.3 on 2026-03-18 and 6.1.2 on 2026-01-18, so the version increments are small and the changes are likely to be about parser and formatting behaviour rather than a redesign. For a plugin that reads your writing, that is the right kind of release cadence, because a format change would break existing notes silently.

The support model is the usual plugin arrangement. The README asks for a coffee at a Buy Me a Coffee link, and directs bugs and feature requests to the GitHub issue tracker. The repository also carries a CHANGELOG.md, a CLAUDE.md, a skills directory, a docs directory and a lefthook.yml for git hooks.

The last push to the repository was on 2026-09-06 and the repository is not archived, so the source is being worked on even though the tagged releases stopped in March 2026. For a plugin installed from the community store, what you run is whatever the store has, and the store gets the release, so the version you get and the version in the repository can differ by several months.

Where a notes-derived map is the wrong tool

Three situations rule it out, and they are all about where the location data actually lives.

The first is if your locations are not in your notes. The plugin searches notes for geolocations and paths, which is the right model for a travel journal or a worldbuilding vault and the wrong model for a structured dataset. If your coordinates arrive from a database, a form submission or an API, then this plugin has nothing to search, and the tool you want is a map library pointed at your data rather than a plugin pointed at your prose.

The second is if you want to edit on the map and have it write back. The plugin offers Edit Mode, which lets you draw locations and shapes on the map, and it lets you add a location from the map. What the documentation does not describe is a round trip where a marker moved on the map updates the note it came from, which is the direction a personal GIS would ideally work in. If bidirectional editing is the requirement, the plugin as documented does not promise it.

The third is if you need multi-user or shared mapping. This is a single vault on a single machine, with a plugin that reads files and renders them. There is no account, no sync layer and no collaboration model, and none is implied.

There is also a question of scale and of what the map is for. A personal map of a few hundred places is exactly the right use. A map of every place mentioned in a large archive becomes a picture of a life, which may or may not be interesting, and the plugin offers no clustering control beyond the Leaflet marker cluster library being present in the dependencies.

What the plugin does well is make the map a place you read from, not a place you manage. If that is the relationship you want with your notes, it is a good fit, and the licence is permissive enough to fork.

Editorial conclusion

Obsidian Map View fits a note taker whose vault already contains place references, or who wants to add them without a second application to keep in sync, since the plugin treats the notes as the source of truth and the map as a view over them. It is the wrong choice if your location data lives in a structured database or a mapping service rather than in prose, because the plugin's job is to read your notes, not to import a data set, and it is the wrong choice if you need bidirectional editing where a change on the map is written back to the note, which the documentation does not describe. Before adopting it, read the Location Formats page to check that the way you write coordinates matches what the plugin parses, and read the Display Rules page to understand how much control you have over marker appearance without writing code.

Frequently asked questions

Official sources

1. esm7/obsidian-map-view on GitHub
2. Issues
3. License: MIT
4. README
5. Releases