PR #2: Fix edge_map semantics implementation #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
edge_mapsemantics that separate segment indices from edge labelsedge_mapwas applied at the wrong abstraction leveledge_mapis applied only to edge labels (edge_id) for final outputKey Changes
edge_mapto labels, use indices for internal operations_calculate_linear_position: Use segment indices directly instead of converting back to edge_idsTest Results
edge_maptests pass (10/10)Technical Details
The fix addresses the original bug where:
find_nearest_segment()returns segment indices (0, 1, 2, ...)edge_mapwas incorrectly applied to these indices_calculate_linear_position()expected edge_ids but received indices, causing KeyErrorNow:
edge_ids = edge_id_by_index[seg_idx]edge_mapto edge_ids:mapped_edge_ids = [edge_map.get(eid, eid) for eid in edge_ids]🤖 Generated with Claude Code