Replace preview_edit links with GeoJSON fenced blocks in coordinate proposed edits

[Copilot]

Coordinate proposed-edit feedback was generating https://nav.tum.de/api/preview_edit/... links in PR descriptions. This replaces them with inline geojson fenced code blocks that GitHub renders natively as interactive maps.

Proposed Change(s)

• coordinate.rs — Coordinate::apply() now returns a pretty-printed RFC 7946 GeoJSON Feature wrapped in a ```geojson fenced block instead of a preview URL:

  {
    "type": "Feature",
    "geometry": { "type": "Point", "coordinates": [11.668, 48.262] },
    "properties": { "kind": "coordinate-change", "id": "mi", "to_lat": 48.262, "to_lon": 11.668 }
  }
  

  Loading
• description.rs — New apply_set_as_blocks() method renders edits as a bullet list where each block result is emitted with a blank line and 4-space indentation, so fenced code blocks are correctly nested under the list item in GitHub-flavored Markdown. Existing appply_set() table method is unchanged — image submissions continue to use it.
• tmp_repo.rs — Routes coordinate edits through apply_set_as_blocks() and image edits through appply_set().

Checklist

• Documentation
  • I have updated the documentation
  • No need to update the documentation

Original prompt

Create a pull request in TUM-Dev/NavigaTUM that replaces the current behavior of attaching https://nav.tum.de/api/preview_edit/... links to the feedback / proposed-edits output with a new system that embeds GeoJSON in fenced Markdown code blocks (geojson ... ).

Context / current behavior:

• The feedback proposed-edits pipeline currently generates preview links. For coordinate edits, Coordinate::apply(...) returns a string containing https://nav.tum.de/api/preview_edit/{key}?to_lat={lat}&to_lon={lon}.
• This string is later included in the GitHub issue/PR description generated by the server-side proposed-edits flow.

Primary changes:

1. Server: stop producing preview_edit links for proposed edits. Instead, produce a GeoJSON payload representing the proposed edit.

   • For coordinate edits, output a GeoJSON Feature with geometry Point at the proposed coordinate.
   • Use standard GeoJSON coordinate ordering: [lon, lat].
   • Include relevant metadata under properties, at minimum:
     • kind: string, e.g. "coordinate-change"
     • id: the key/id being edited
     • to_lat, to_lon: numeric (optional redundancy but useful)

2. Markdown formatting: ensure the GitHub description contains the GeoJSON in a fenced code block labeled geojson.

   • If the description generator currently expects a link string, adjust it to embed the returned GeoJSON in a code block.
   • Keep the rest of the description formatting intact.

3. Backwards compatibility / cleanup:

   • Remove/adjust any references to preview_edit in the proposed-edits feedback path.
   • Ensure any tests that assert the old URL string are updated to assert GeoJSON output instead.

4. Frontend / types (if applicable):

   • If the webclient shows or constructs these links, update it to display/submit the GeoJSON code block format instead.
   • Update any OpenAPI schema / generated types only if required by compilation.

Acceptance criteria:

• No nav.tum.de/api/preview_edit link is generated/embedded for coordinate proposed edits.
• Generated GitHub feedback/PR description includes a ```geojson fenced block containing valid GeoJSON.
• All tests pass.
• Rust formatting/lints pass.

Useful code locations already identified:

• server/src/routes/feedback/proposed_edits/coordinate.rs (currently builds the preview_edit URL)
• server/src/routes/feedback/proposed_edits/mod.rs (AppliableEdit trait + request/description flow)
• server/src/main.rs wires feedback::proposed_edits::propose_edits

Notes:

• Keep the scope focused to proposed-edits feedback output formatting.
• If additional edit types (image/description) also produce preview_edit links, update them similarly.

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR updates the server-side proposed-edits GitHub description generation for coordinate changes to embed GeoJSON directly in Markdown, replacing the previous preview URL approach, so GitHub can render interactive maps natively.

Changes:

• Coordinate proposed edits now produce a pretty-printed GeoJSON Feature wrapped in a geojson fenced code block.
• Added a new description rendering path (apply_set_as_blocks) to emit edits as Markdown blocks (instead of tables) for categories that need fenced blocks.
• Routed coordinate edits through the new block rendering path while keeping image edits on the existing table rendering path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
server/src/routes/feedback/proposed_edits/coordinate.rs	Replaces preview URL output with a GeoJSON Feature fenced in ```geojson for coordinate edits.
server/src/routes/feedback/proposed_edits/description.rs	Adds apply_set_as_blocks() to render edits as Markdown block/list output suitable for fenced code blocks, plus unit tests.
server/src/routes/feedback/proposed_edits/tmp_repo.rs	Switches coordinate edits to use apply_set_as_blocks() while leaving image edits on the table path.

[CommanderStorm]

@copilot test_apply_set_as_blocks is failing.

[Copilot]

@copilot test_apply_set_as_blocks is failing.

Fixed in 8f57a8e. The test was asserting the old format (no blank line, no indentation). The apply_set_as_blocks method was already updated with the indentation fix, so only the test expected string needed updating to reflect the new output: blank line after the list-item colon + 4-space indent on each line of the block result.