Skip to content

Map fixme markers: light blue when object is a relation member#7

Closed
tordans wants to merge 1 commit into
masterfrom
cursor/fixme-relation-member-color-6fc2
Closed

Map fixme markers: light blue when object is a relation member#7
tordans wants to merge 1 commit into
masterfrom
cursor/fixme-relation-member-color-6fc2

Conversation

@tordans
Copy link
Copy Markdown
Owner

@tordans tordans commented May 30, 2026

Problem / user story

Selecting a relation on the map highlights its member ways (and other members) in a distinctive light blue (EditorMapLayer uses relationColor, RGB 66/188/244). Separately, objects tagged with fixme=* get a small “F” map marker (FixmeMarker via MapMarkerDatabase).

Today, relation member highlighting and fixme markers are unrelated visually. Every fixme badge uses the same generic blue button styling from MapMarker.makeButton(), whether the tagged object stands alone or belongs to one or more relations.

Problem: Fixmes on relation members are often not something mappers can resolve inside Go Map (they may require external tools, relation-level edits, or context the app does not expose). When scanning the map, those markers look the same as fixmes on ordinary nodes and ways, so they add noise without signaling “this is relation-scoped / probably not actionable here.”

Desired behavior: When a fixme=* marker is placed on an object that is a member of at least one relation, tint the marker with the same light blue as relation member highlighting—not the default fixme blue. Fixmes on non-relation objects keep today’s styling.

Why: Gives an at-a-glance visual filter: relation-bound fixmes read as a distinct category, so mappers can mentally (or eventually via marker filters) de-emphasize them while focusing on fixmes they can actually address in the editor.


Implementation notes (by Cursor)

  • Branch: cursor/fixme-relation-member-color-6fc2
  • File changed: src/Shared/MapMarkers/FixmeMarker.swift
  • Logic: After creating or reusing a marker button, FixmeMarker checks object.parentRelations.isEmpty. If the object has at least one parent relation (via OsmMapData’s parent-relation cache, same source used elsewhere in the app), the button background uses light blue UIColor(red: 66/255, green: 188/255, blue: 244/255, alpha: 1)—matching relationColor in EditorMapLayer. Otherwise it keeps the default .blue from MapMarker.makeButton().
  • Hooks: Overrides makeButton() (first display) and reuseButtonFrom(_:) (region refresh / marker refresh) so existing buttons pick up the correct color when relations load or membership changes.
  • Scope: Visual-only; no changes to fixme discovery, tap behavior, or overlay toggles.

Testing notes (@tordans)

Test Location: https://www.openstreetmap.org/way/1105973680

  1. Standalone fixme — Node or way with fixme=* and no parent relations → F marker should remain default blue.
  2. Relation member fixme — Way (or node) that is a member of a relation (e.g. multipolygon outer, route relation member) and has fixme=*F marker should be light blue (same hue as selected-relation member highlighting).
  3. Multiple relations — Member of more than one relation with fixme=* → still light blue.
  4. Pan/zoom refresh — Pan away and back, or zoom to trigger marker refresh; colors should stay correct after relations are loaded.
  5. Regression — Tap fixme marker still opens tag editor (map visible) or shows fixme text alert (map hidden); other marker types (notes, quests, KeepRight) unchanged.
BeforeAfter
relation-fixme-before.min.mov
relation-fixme-after.min.mov

No automated tests were added; this project is iOS/Xcode and was not built in the cloud agent environment.

Open in Web Open in Cursor 

Relation-bound fixmes use the same RGB as relation member highlighting
in EditorMapLayer so mappers can distinguish them from actionable fixmes.

Co-authored-by: Tobias <t@tobiasjordans.de>
@tordans
Copy link
Copy Markdown
Owner Author

tordans commented May 31, 2026

Now handled at bryceco#960

@tordans tordans closed this May 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants