[tristan0x]

🤔 What

• New migration sql/9_41_2026_11_11_country_coordinates.sql corrects the latitude / longitude of three t_country rows:

  ISO	Country	Before (wrong)	After
  GE	Georgia	32.157, -82.907 (the US state Georgia)	42.315407, 43.356892
  VA	Holy See	30.034, -95.812 (a place in Texas)	41.902916, 12.453389
  SO	Somalia	9.987, 45.299 (Somaliland, the north)	5.152149, 46.199616

• The seed sql/2_2021_09_22_4_countries.sql gets the same values, so fresh databases are right too.

• New test test/integration/0_models/TCountry.coordinates.test.js.

🤷‍♂️ Why

The issue reports that the Georgia link on the countries page leads to the US state of Georgia. The link itself is right: the front end builds /ui/countries/GE and every country endpoint looks the country up by its ISO code. The data is what's wrong. The coordinates that GET /api/v1/countries/GE returns, which the country page uses to center its map, are those of the US state. The country was geocoded from its English name and landed on a homonym.

I cross-checked all 250 rows of t_country for the same mistake and found two more: Holy See (placed in Texas) and Somalia (placed on Somaliland).

🔍 How

• The new values come from the same country-centroid dataset as the other rows (FR, US, GB… match it exactly).

• Each UPDATE only changes a row that still holds the wrong value, so a coordinate someone already corrected by hand is kept. Running the migration twice changes nothing.

• The test runs the real migration file (through forTestDatabase, as test/customSQL.js does for other migrations) on rows seeded with the wrong values, then checks that:

  • each country now falls inside its own bounding box;
  • GET /api/v1/countries/GE returns a point in Georgia;
  • a hand-corrected value survives a second run;
  • the seed file holds the corrected coordinates.

  With the migration replaced by a no-op and the seed reverted, the migration and seed assertions fail (expected 32.1574351 to be within 41..44).

⚠️ Production does not run migrations on deploy: apply sql/9_41_2026_11_11_country_coordinates.sql by hand. It only updates data and can be applied before or after the merge.

Not in this PR: CD, KP, KR, PS, AX, BL, CW, MF and SS have no coordinates at all (their country page shows no marker). That is a different problem from this bug, which is wrong coordinates.

🧪 Testing

• npm run lint: clean.
• npm run test: 6168 passing, 0 failing.
• I ran the migration on the local dev database inside a transaction that I then rolled back: each of the three statements updated one row, with the values above.
• Manual check after applying the migration: open /ui/countries/GE and check that the map is centered on the Caucasus. Do the same for /ui/countries/VA (Rome) and /ui/countries/SO.

📸 Previews

No UI change in this repository. The country page map for GE moves from the south-eastern US to Georgia (Caucasus).

Closes #1699

[Paul-AUB]

Approved: no must-fix issues found in the three changed files at ae9bd06.

The migration guards exactly match the previous seed values using decimal comparisons, and the replacements agree with both the updated seed and Google's country-coordinate dataset. The ISO-scoped updates preserve coordinates already corrected by hand. The required manual production migration is documented in the PR.

Validation: JavaScript syntax checking, git diff --check, and a dependency-free check of all three old-value guards, replacement/seed consistency, and forTestDatabase normalization passed. I could not run ESLint or the integration suite here: dependencies are not installed and Docker is unavailable. GitHub reports no checks on this branch, so the PR author's reported full-suite result was not independently reproduced.

Suggestions (Should Consider)

1. [test/integration/0_models/TCountry.coordinates.test.js:92] Consider running await runMigration() in the API test's own setup. The suite-level before seeds the incorrect coordinates, and this test currently relies on the preceding it to migrate them. Running the documented filtered command with --grep "serves the country page map" skips that preceding test and asserts Georgia's bounding box against the old US coordinates. Giving the API test its own migration step would let it run independently and make failures easier to diagnose.