How to Manage Locations in Obsidian for D&D
With just a few basic properties, we unlock a lot of powerful capabilities in how we organize and use our location notes.

When working with Obsidian for Dungeons & Dragons, some notes are easy to organize. You might have a note for each character and a folder for them all. But what about locations? What about locations within locations? What about folders and properties? Let’s take a look at organizing locations within Obsidian.
Nested Folder Nightmare No More
We will start with a simple Locations
folder. We'll avoid proceeding with a hierarchy of “locations within locations” meaning folders within folders. The relativity of locations within our settings doesn’t need to match our file structure for organizing them. We can decouple those two things—it’s just our brains that try to associate them.
That said, folders are useful for organizing. So where do we draw the line? Here is a paradigm that I sometimes find useful:
- Default to a note rather than a new folder within
Locations
. - Add a folder when we need to separate a larger amount of notes that we might want to search though quickly (in isolation).
One example would be a folder for each “setting” in our world. For me, these are usually continents. Some are geographically close but conceptually different (or featured different campaigns). Within those settings, there are no more folders. It’s all markdown files. All regions, landmarks, geography, settlements, etc. live in shared or individual markdown files. Because of that, we have no more arbitrary hierarchy leading to a nested folder nightmare. So what does organization actually look like?
Properties
The first property I use is category
. This is the highest-level categorization of my RPG notes. It's telling me which "type" of note this is. For locations, the value is location
.
The second property is geography
. This further classifies each location for more advanced filtering. Examples include mountain
, forest
, settlement
, temple
, volcano
, lake
, etc.
The third property I use for locations is location
. This is a link to the parent location for the current note. For example, a settlement's location
might be [[King's Valley]]
. This unlocks the ability to show locations within locations. Bonus: this property is also reusable for other types of notes. It can show the location of NPCs, items, and quests!
The last property I use for locations is campaigns
. This is a link to all campaigns a particular note relates to. This unlocks powerful relationship building for each campaign, from graph view to campaign-centric bases.
Nested Locations
To see all locations within the current location note, we can just embed a view of the following base:
filters:
and:
- category == ["location"]
views:
- type: table
name: Table
filters:
and:
- location.contains(this.file)
order:
- file.name
- geography
columnSize:
file.name: 134
Locations-Within.base
This results in an automatic collection of all category: location
notes tagged with the current note in their location
property.

Campaign Locations
With the above properties in place, we can also embed a campaign-centric base in our main campaign note. One of the views can filter down to locations within the current campaign.

From there, we could expand our base views to show all settlements, ruins, temples, etc.
With just a few basic properties, we unlock a lot of powerful capabilities in how we organize and use our location notes. Want to see this in action? Become an Architect supporter and grab the Architect's Vault.
Game on.