master @ af87d70
RenderInfoCollection.collisionFreeOrdered() resolves label collisions in pure insertion order — the priority sort is present but disabled:
// packages/mapsforge_flutter_rendertheme/lib/src/model/render_info_collection.dart:23-24
// sort items by priority (highest first)
// renderInfos.sort((a, b) => b.renderInstruction.priority.compareTo(a.renderInstruction.priority));
A single render-theme that draws both a and a produces two independent RenderInfo entries (both added via LayerContainer.addLabel), each competing separately in collisionFreeOrdered()'s haveSpace loop. They are not treated as an atomic pair, so it's possible for the caption to win its collision check while the symbol loses (or vice versa) against some unrelated nearby label — with no ordering guarantee since priority currently has no effect at all.
Symptom we're seeing: a POI's text label renders with no icon anywhere near it, looking like the label "drifted" to an arbitrary spot — e.g. a man_made=survey_point/survey_point=trig_1st node's (name) surviving while its (the marker icon) is silently dropped. Reproducible more easily once the candidate label pool for a render pass is widened (e.g. batching retrieveLabels over a multi-tile range instead of one tile at a time) — more competing labels means more chances for a rule's symbol and caption to end up on opposite sides of a collision.
Ask:
Is leaving the sort disabled intentional (e.g. a known-slow path, or WIP), or just left in mid-refactor?
Regardless of the sort, could + pairs from the same rule be grouped so they survive or drop together? Right now there's no way for a consumer to prevent "headless" captions without re-implementing collision resolution ourselves.
master @ af87d70
RenderInfoCollection.collisionFreeOrdered() resolves label collisions in pure insertion order — the priority sort is present but disabled:
// packages/mapsforge_flutter_rendertheme/lib/src/model/render_info_collection.dart:23-24
// sort items by priority (highest first)
// renderInfos.sort((a, b) => b.renderInstruction.priority.compareTo(a.renderInstruction.priority));
A single render-theme that draws both a and a produces two independent RenderInfo entries (both added via LayerContainer.addLabel), each competing separately in collisionFreeOrdered()'s haveSpace loop. They are not treated as an atomic pair, so it's possible for the caption to win its collision check while the symbol loses (or vice versa) against some unrelated nearby label — with no ordering guarantee since priority currently has no effect at all.
Symptom we're seeing: a POI's text label renders with no icon anywhere near it, looking like the label "drifted" to an arbitrary spot — e.g. a man_made=survey_point/survey_point=trig_1st node's (name) surviving while its (the marker icon) is silently dropped. Reproducible more easily once the candidate label pool for a render pass is widened (e.g. batching retrieveLabels over a multi-tile range instead of one tile at a time) — more competing labels means more chances for a rule's symbol and caption to end up on opposite sides of a collision.
Ask:
Is leaving the sort disabled intentional (e.g. a known-slow path, or WIP), or just left in mid-refactor?
Regardless of the sort, could + pairs from the same rule be grouped so they survive or drop together? Right now there's no way for a consumer to prevent "headless" captions without re-implementing collision resolution ourselves.