Feature request: Allow Display Rules to use metadata from linked notes (MD → GPX)

[Pakos091]

Hi,

First of all, thank you for the plugin — Map View is an amazing tool and I’m using it to build a structured motorcycling route atlas.

🧠 Use case

I have a domain model where:

• Each route segment is defined in a Markdown note:

  10_Segments/SK/SK-ORE-010.md

• The note contains metadata:

  segment_status: planned

• The actual geometry is stored as a GPX file:

  40_Tracks/segments/SK-ORE-010.gpx

• The note links to the GPX:

  track_file: [[SK-ORE-010.gpx]]

So effectively:

Markdown note (metadata) → GPX file (geometry)

---

🎯 What I want to achieve

I would like to style GPX paths based on metadata stored in the linked Markdown note.

Example:

• segment_status: planned → light blue
• all other segments → default blue

---

❌ Current limitation

Display Rules operate on the GPX file itself, and:

• GPX files do not contain the metadata
• Display Rules cannot resolve properties from linked notes
• Queries like this are not supported:

["segment_status":"planned"]

Even though the relationship exists:

SK-ORE-010.md → [[SK-ORE-010.gpx]]

---

⚠️ Current workarounds (not ideal)

To achieve this today, I would need to:

• duplicate metadata into file names (e.g. .planned.gpx)
• or split files into folders (segments/planned/)
• or abandon property-driven styling

All of these break a clean, normalized data model.

---

💡 Proposed solution

Allow Display Rules (optionally) to resolve metadata from linked notes.

For example:

path:"40_Tracks/segments" AND linked.note["segment_status"] == "planned"

Or more generally:

Allow path objects (GPX) to inherit or resolve properties from Markdown notes that link to them.

---

🧠 Why this matters

This would enable:

• clean separation of data (MD) and geometry (GPX)
• true property-driven styling
• much more powerful use of Map View in structured workflows

This pattern is especially useful for:

• route planning systems
• GIS-like note structures
• domain-driven vaults

---

🙏 Closing

I understand that this may go beyond the current philosophy (keeping filtering in Bases), but in this case:

• the metadata lives in Markdown
• the rendered object is the GPX
• and the relationship already exists via links

So exposing that relationship in Display Rules would unlock a lot of power without requiring a full custom query language.

Thanks again for the great work, and happy to provide more examples if needed!

[esm7]

That's a great suggestion, and in contrary to what you wrote, the current philosophy is not to keep filtering in Bases, but to continue developing Map View's internal querying abilities, since (unfortunately) Bases are not adding inline fields anytime soon and thus not replacing it.
I'm flagging it as a feature I'd like to add, but must be transparent that my time to work on the project is limited right now, and the next meaningful iteration for adding features might be many months away.