Das haben wir im Script gelöst. Man kann die Teil-Netze/Domänen anhand von Queries Beschreiben, die dem OSM/Nominatim Schema entsprechen. Und dann durch und+oder Verknüpfungen seine „Suchmaske“ zusammenschrauben. Leider arbeitet die Nominatim-API bei ganz kleinen Gebietsteilen nicht ganz so sauber, wie erwartet. Aber bis auf die Stadtteil-Ebene runter funktioniert es sehr gut. Mesh-Wolken, wo nur manche Knoten Geo-Daten haben werden komplett berücksichtigt. Hier findest du das Tool. Es sind ein paar Änderungen noch nicht commited (branch, Erkennung nicht korrekt). Und eine readme bin ich auch noch schuldig.
Ja, das habe ich leider nicht eingebaut. Konzept war: Ich lade eh schon seit jeher einmal stündlich die nodes.json und mesh.json herunter. Man hätte dann einen Zeitraum angeben können, in dem eine Mesh-Verbindung bestehen haben muss, um berücksichtigt zu werden. Hatte aber seinerzeit kein Feedback aus meiner Community diesbezüglich bekommen und es daher nicht eingebaut.
Eine Anmerkung noch: Zu beginn hatten wir den Ansatz in (einheitlichen) Wellen umzuziehen. D. h. erst alle „level2“-Nodes (also Knoten, die 2 Hops bis zum nächsten Knoten mit VPN Verbindung brauchen) umgezogen, dann alle level1-Nodes, dann alle level-0 Nodes (die mit VPN). In der Theorie ganz toll, in der Praxis nicht so. Leider sträuben sich ein paar Prozent der Knoten einige Stunden bis Tage, bis sie das Update endlich ziehen. Daher bin ich dann dazu übergegangen mehrere Ziele je Domäne zu definieren, die dann räumlich kleiner waren.
Wenn ich es jetzt noch mal schreiben müsste, würde ich direkt ein Ziel je lokaler Wolke generieren lassen und die Erstellung und Überwachung der Config automatisieren.
Um festzustellen, ob ein Knoten umgezogen ist, habe ich entsprechende Einträge aus dem nginx access.log gegrept und dann versucht den Knoten unter seiner (erwarteten) neuen Adresse anzupingen, falls erreichbar (== Umzug hat geklappt), falls nicht erreichbar und auch unter seiner alten Adresse nicht erreichbar (aber FW geladen) im Kommentar den Status auf „ready“ gesetzt, da es sich typischerweise um Level x (x>0) Knoten handelt, die noch auf ihren VPN-Knoten warten um wieder online zu kommen…
Da ich diese Thematik bei der Erstellung der Scripte komplett außen vor gelassen hatte, gab das hinterher ein kleines bash Script mit einem doch recht langen Aufruf mit diversen verknüpfungen und pipes. 
Das kommt bei unserem Verfahren schon hin. Es haben sich aber die meisten Betroffenen schon bei uns gemeldet (oder wir bei denen). Der Rest muss noch in der Nacharbeitung „gefunden“ werden.
