[afonsojanu]

Fixes #234.

An extension element can declare its own default namespace that never shows up anywhere else in the document. The classic real-world example, reported independently by three different users on this issue over the years, is a Garmin gpx_style block:

<extensions>
  <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2">
    <color>000000</color>
  </line>
</extensions>

to_xml() can only write a prefix for a namespace that's already in nsmap, and nothing currently puts this one there, since it only appears nested inside an extensions element rather than on the gpx root or one of the other attributes the parser's regex scans for. When _resolve_prefix in gpxfield.py hits a Clark-notation tag whose namespace it can't find, it falls back to gluing the raw URI onto the local name as if it were a prefix:

<http://www.topografix.com/GPX/gpx_style/0/2:line>

which isn't well formed XML and can't be parsed back at all. I confirmed this against current dev with the file from the issue: the round trip through to_xml() and back raises ParseError: not well-formed (invalid token).

@tkrajina had already dug into the root cause and committed a failing test for this back in 2021 (test_extension_with_xmlns, referenced in the issue thread) but never got to a fix.

This adds GPX._register_extension_namespaces, called from to_xml right before the root element is written. It walks every extensions list in the document, including the root, metadata, waypoints, routes and their points, tracks and their segments and points, and recurses into nested children such as the line element above. Any namespace it finds that isn't already in nsmap gets a fresh nsN prefix assigned to it, which is then declared normally on the gpx root alongside the rest, so _resolve_prefix can resolve it like any other namespace instead of falling back to the broken path.

I've added a regression test with the same shape as the maintainer's 2021 one (adapted since ElementTree.getchildren() no longer exists on current Python), checking that the serialized output stays parseable and the extension data survives the round trip. Full test suite (146 tests) and mypy --strict both pass with no new findings compared to dev.

[afonsojanu]

Closing this one too, same reason: starting fresh and clearing out everything I had open.