Display rules crash when rendering GeoJSON/GPX path embeds — Object.keys(null) in Query.testIdentifier

[Graham3324]

Summary
When the vault has any property/tag-based display rule (e.g. [type:foo]), embedding a GeoJSON or GPX path (![[route.gpx]]) throws an uncaught TypeError and the path never renders. Map View parses the track fine (it logs initialized with … markers & paths), but the display-rule pass over the path layer crashes on Object.keys(null).

Environment
Map View: 6.1.4 (latest)
Obsidian: 1.12.7, macOS 26.5.1
Setting Handle supported path embeds (handlePathEmbeds): on
Steps to reproduce
In Map View settings, add a display rule with a property/tag query, e.g. [type:national-park] (in my vault this is one of ~35 auto-generated per-type pin rules).
Add any track file to the vault — route.gpx or route.geojson with a LineString.
In a note, embed it: ![[route.gpx]].
Open the note in reading view.
Expected
The path renders as a line, and display rules either apply gracefully to path features or are skipped for them.

Actual
No line renders — the embedded map falls back to a default (world/US) view with no auto-fit — and the console throws:

Uncaught (in promise) TypeError: Cannot convert undefined or null to object
at Object.keys ()
at Query.testIdentifier (plugin:obsidian-map-view:64135:41)
at Query.testLayer (plugin:obsidian-map-view:64023:37)
at DisplayRulesCache.runOn (plugin:obsidian-map-view:78454:27)
at GeoJsonLayer.runDisplayRules (plugin:obsidian-map-view:47991:59)
at buildGeoJsonLayers (plugin:obsidian-map-view:48119:15)
at async MapViewPlugin.updateMarkersWithRelationToFile (plugin:obsidian-map-view:81188:37)
One error fires per path embed on the page.

Additional findings (narrowing it down)
Not file-specific: a hand-authored GeoJSON with an explicit non-empty properties object ({"name":…,"stroke":…}) throws the identical stack — so it's the display-rule evaluation on the path layer, not missing feature properties.
Markers are unaffected: normal note markers render correctly under the same display rules; only GeoJSON/GPX path layers crash.
Parsing succeeds: the crash is at display-rule evaluation (GeoJsonLayer.runDisplayRules), after the path is loaded.
Likely cause: Query.testIdentifier calls Object.keys(...) on a value that is null/undefined for path features (which lack the frontmatter/tag identifier map that note markers have). A guard there — or skipping identifier-based display rules for path features — would likely resolve it.

[esm7]

Thank you, will fix in a high priority.

[Graham3324]

Did some digging in the source and I believe I've isolated this — sharing in case it saves you time (happy to be corrected if you'd rather handle path layers differently).

Root cause: a GeoJsonLayer's file is the .gpx/.geojson TFile itself, which can never have YAML frontmatter. In Query.testIdentifier (src/query.ts), the property-query branch reads:

const fileCache = this.app.metadataCache.getFileCache(layer.file);
let propertyValues: string[] = [];
if (isExactName) {
    const property = fileCache.frontmatter?.[propertyName];
    ...
} else {
    propertyValues = Object.keys(fileCache.frontmatter)  // ← throws here

An unquoted property name (e.g. [type:national-park]) takes the else branch, so Object.keys(undefined) throws the reported TypeError for every path layer. Two adjacent cases look exposed as well: a markdown note with an inline geolocation but no frontmatter hits the same Object.keys(undefined), and the isExactName branch can still throw when fileCache itself is null (the optional chain guards frontmatter's contents, not fileCache).

Suggested minimal fix — hoist the lookup and treat "no frontmatter" as "property query doesn't match," which seems like the right semantics rather than just crash-avoidance:

const frontmatter = this.app.metadataCache.getFileCache(layer.file)?.frontmatter;
if (!frontmatter) return false;
let propertyValues: string[] = [];
if (isExactName) {
    const property = frontmatter[propertyName];
    if (typeof property !== 'undefined') propertyValues = [property];
} else {
    propertyValues = Object.keys(frontmatter)
        .filter((k) => k.includes(propertyName))
        .map((k) => frontmatter[k]);
}

With the guard in place, non-matching rules fall through to the preset default path style and the embedded track renders. If you'd prefer skipping property/tag rules for path layers entirely (or matching them against the GeoJSON properties object instead), that of course supersedes this.

Thanks for the quick triage on this — the plugin is a core part of my vault.

Disclosure: this analysis was done with an AI assistant (Claude), but it's verified against the actual query.ts in the current release, and the stack trace in my original report is from my live vault.

[Graham3324]

Follow-up: the suggested guard is field-tested and resolves the crash.

Since the fix hadn't landed yet, I applied the exact guard from my previous comment to a local build to unblock my vault — sharing the results here as a data point for whenever you get to this:

• Built from the 6.1.4 tag with only the testIdentifier change (hoist the frontmatter lookup, return false when absent).
• The full upstream test suite passes: 366/366.
• In the originating vault (~35 property-based [type:…] display rules): GPX and GeoJSON embeds now render their track with auto-fit, and the per-embed TypeError is gone from the console. Note markers continue to render normally under the same rules.
• It's had a real workout since: I've added GeoJSON route embeds to 92 notes in this vault, all rendering under the same display rules with no errors.

The semantics also feel right in practice: a path layer simply doesn't match property queries, so non-matching rules fall through to the default path style rather than crashing the whole display-rule pass.

No rush at all — happy to help however you'd prefer to take it from here.

Disclosure: as before, this was done with an AI assistant (Claude), but the build, test run, and rendering results are from my live vault.