- ~/pbf/planet.osm.pbf — 86GB planet PBF
  - ~/pbf/germany.osm.pbf — 4.5GB Germany PBF
  - ~/pbf/monaco.osm.pbf — small test PBF
  - ~/indexes-old-code/ — old code planet output (77GB, 943K admin polygons)
  - ~/planet-old-code.cache — old code cache (16GB)
  - /tmp/de-parallel/ — new code Germany output (just completed)
  - /tmp/de-sequential/ — sequential Germany output (should be running or about to start)
  - /tmp/traccar-geocoder/ — latest code (commit acf403e with node-ID fix)
  - /tmp/diff_admin — compiled admin comparison tool
  - /tmp/compare_indexes.cpp — semantic comparison source

  Git State

  Repo: git@github.com:zp-forks/traccar-geocoder.git (branch: main)
  Latest commit: 1a25143 — "fix: use node IDs for ring stitching instead of coordinates"

  Key commits:
  - 93fe6e4 — rename strings to string_pool (s2 namespace conflict)
  - 6fe46b1 — parallel processing with sharded node index
  - 3117db8 — reduce shards to 16, stream way blocks
  - a19cb3c — lockless dense array index
  - 0a2bb57 — increase to 15B max node ID with bounds checking
  - 58349a5 — parallel admin assembly
  - b79a003 — ring rotation normalization + compare_indexes tool
  - acf403e — only store admin member way geometries
  - 1a25143 — node ID matching for ring stitching

  What Needs Doing Next

  1. Compare Germany parallel vs sequential admin polygon counts to see if the node-ID fix resolved the ~12K discrepancy
  2. If it matches, run a full planet build with the new code and compare against ~/indexes-old-code/
  3. If discrepancies remain, investigate which specific relation types our ring stitcher fails on
  4. Run the Rust server against the generated indexes and test queries across 40 global locations (the test script was written but never
  executed on planet data)
  5. Compare index sizes across all modes (full, no-addresses, admin-only) for planet + each continent
  6. The dashboard is running at localhost:8888 on the local Mac

  Memory Constraints

  - Node 2a/2b: 192GB cgroup limit. Dense array (111GB) + data (~30GB) + way processing fits but barely. Previous OOM kills at 175GB (64-shard),
  survived at 168GB (no shards).
  - Node 3: 174GB physical + 50GB swap, no cgroup. Dense array works but previous runs segfaulted when MAX_NODE_ID was 13B (fixed to 15B).
  - /tmp on node 3 is a 79GB tmpfs (RAM-backed). Use ~/ for large files (disk-backed).```