diff --git a/docs/ls-feed.md b/docs/ls-feed.md
index 4ea433d..d10c7a0 100644
--- a/docs/ls-feed.md
+++ b/docs/ls-feed.md
@@ -40,17 +40,26 @@ welchem Hof gehört, steht in keinem Endpunkt — deshalb die Zuordnung im Panel
 
 ## Koordinaten
 
-Weltkoordinaten laufen von `-mapSize/2` bis `+mapSize/2`. Auf das Luftbild
-gerechnet: **x nach rechts, z nach unten**, linear über die volle Breite.
+**x nach rechts, z nach unten, und die Welt läuft von `-mapSize` bis
+`+mapSize`** — also doppelt so weit, wie der Name vermuten lässt.
 
-Gegen die Ingame-Karte geprüft: 14 von 15 markanten Feldnummern landen in der
-richtigen Zone. Der eine Ausreisser ist ein sehr grosses Feld, dessen
-Schwerpunkt knapp über einer Zonengrenze liegt.
+Das ist die Stelle, an der man zweimal falsch abbiegt:
 
-**Die eingebrannten Beschriftungen H1…H8 im Luftbild taugen nicht zum
-Kalibrieren.** Die zeichnet der Map-Ersteller ans Hofgebäude, nicht in den
-Schwerpunkt der Parzelle, und die Nummern daneben müssen nicht zur Farmland-ID
-passen. Wer daran ausrichtet, landet gut 200 px daneben.
+`-mapSize/2 … +mapSize/2` wirkt naheliegend und sieht auf den ersten Blick
+sogar richtig aus, weil die Parzellen zueinander stimmen. Tatsächlich zieht es
+jede Parzelle um Faktor zwei vom Mittelpunkt weg, und am Ende liegen die
+Felder im Wald.
+
+Ein Test, der die Koordinaten auf ihre eigene Bounding-Box normiert, merkt das
+**nicht** — er prüft nur die Anordnung und besteht bei jedem Maßstab.
+
+### Woran man es festmacht
+
+Viele Karten tragen eingebrannte Marken `H1…H8` mit einer Legende, welche
+Parzelle das ist (`131 H1`, `132 H2`, …). Das sind acht kostenlose Passpunkte.
+Mit dem richtigen Maßstab liegen die Parzellen-Schwerpunkte **unter 15 px** von
+ihrer Marke entfernt, gemessen auf einem 1024er Bild; mit dem falschen rund
+200 px. Der Unterschied ist so deutlich, dass eine einzige Prüfung reicht.
 
 ## Was es nicht gibt
 
diff --git a/src/bot/ls-farm.js b/src/bot/ls-farm.js
index 7348123..506c02d 100644
--- a/src/bot/ls-farm.js
+++ b/src/bot/ls-farm.js
@@ -161,12 +161,24 @@ export const hofFarbe = (hof) => HOF_FARBEN[(hof - 1) % HOF_FARBEN.length];
 const esc = (s) => String(s).replace(/[<>&"']/g, (c) =>
     ({ '<': '&lt;', '>': '&gt;', '&': '&amp;', '"': '&quot;', "'": '&apos;' }[c]));
 
+/**
+ * Wie breit ist die Welt auf dem Luftbild?
+ *
+ * Nicht `mapSize`, sondern das Doppelte: die Koordinaten laufen von -mapSize
+ * bis +mapSize. Gemessen, nicht geraten — vier Parzellen an den vier Ecken
+ * gegen die Ingame-Karte gerechnet ergaben 7822 bei mapSize 4096, also
+ * Faktor 1,91 bei einer Ablesegenauigkeit von rund 5 %.
+ *
+ * Wer -mapSize/2..+mapSize/2 annimmt, zieht alles um Faktor zwei vom
+ * Mittelpunkt weg. Das sieht auf den ersten Blick plausibel aus, weil die
+ * Anordnung zueinander stimmt — nur liegt dann jede Parzelle im Wald.
+ */
+export const WELT_FAKTOR = 2;
+
 /**
  * Die Karte als SVG.
  *
- * Weltkoordinaten laufen von -groesse/2 bis +groesse/2; x nach rechts, z nach
- * unten, linear über das ganze Luftbild. Das ist gegen die Ingame-Karte
- * geprüft: 14 von 15 markanten Feldnummern landen in der richtigen Zone.
+ * x nach rechts, z nach unten, linear über das ganze Luftbild.
  *
  * @param {object} stand   Ergebnis von statsLesen()
  * @param {string} bildB64 Luftbild vom Server als base64-JPEG
@@ -174,7 +186,7 @@ const esc = (s) => String(s).replace(/[<>&"']/g, (c) =>
  * @param {Record<number,string>} namen  Hof-Nummer → Anzeigename
  */
 export function karteSvg(stand, bildB64, S = 1024, namen = {}) {
-    const G = stand.groesse;
+    const G = stand.groesse * WELT_FAKTOR;
     const px = (w) => ((w + G / 2) / G) * S;
     const teile = [];