Stimmt schon, aber ob’s wirklich gut funktioniert steht auf einem anderen Blatt. Die spärliche Doku, macht das Verständnis der overpass-Abfragesprache ja auch nicht gerade einfach 
Aber ich hab dann mal ein bisschen rumprobiert:
Also hier mal eine Abfrage, wo geprüft wird ob alle 300m (oder größerer Abstand) im Durchschnitt in einem Weg sind.
way({{bbox}})[highway] (if:count_members() < length() / 300);
Recht simpel:
way({{bbox}})[water] (if:count_members()-1 > 4 && count_members()-1 <= 8);
Ggf. statt nur >water< halt ein >water~“lake|pond|lagoon|oxbow|basin”< oder was auch immer noch machen (siehe https://wiki.openstreetmap.org/wiki/DE:Key:water ), sodass halt man nicht jede Kläranlage oder rechteckigen Pool mit dabei hat. Ggf. auch eher “natural=water”, weil vl. nicht jedes Gewässer auch konkret erfasst ist?
Für die beiden Dinge hier eine entsprechende Overpass-Abfrage:
https://overpass-turbo.eu/s/10Gp
Ich glaube hier stößt man final an die Grenzen von Overpass. Will nicht ausschließen, das man es irrrrgendwie gefriemelt bekommt (viele seltsame Schleifen, “triangulieren” via “around”-Funktion, verquere Mathematik, dann aber noch inkl. guter Performance ohne den Overpass-Server leiden zu lassen? hmmm…
Auch fehlt mir hier ein Beispiel zum Testen. Kannst du mal ein Gebiet verlinken?
Zudem Frage ich mich, ob die formulierten Abfragewünsche halt wirklich so formuliert dir das bringen, was du im Kern suchst?
(Wald)wege: Hier wirst du mit der Abfrage auch vieles bekommen, was du als valide erachten wirst. Desto kleiner du den Abstand machst, desto mehr davon. Machst du ihn größer, wird mehr von dem was du suchst, halt nicht im Sieb hängen bleiben.
Ggf. hat ein Way ja auch nur deshalb (ausreichend) viele Nodes, weil halt wiederum andere Wege davon abgehen (oder Waldgrenzen oder Bäche oder oder). Sprich der Weg ist vl. eigentlich in der Karte 2km schnurgerade, aber hat halt aus welchem Grund auch immer halt insgesamt ausreichend viele Nodes drin, sodass es im Durchschnitt passt. Ggf. auch nur am Ende eine “Kurve”. 2km schnurgerade und am Ende eine Kurve mit 10 Nodes - schwups ist der durchschnittliche Abstand gut unter 200m und fällt damit nicht auf.
Oder auf der Karte ist klar langer gerader Weg sichtbar, aber in OSM besteht der aus vielen einzelnen Ways.
oder oder
4-8-Punkt-Seen:
Geht dir doch um den Detailgrad? Also wäre doch auch eher hier ein Punkte zu Umfang(Länge)-Verhältnis oder Fläche eher sinnvoll? Denn ein 6eckiger-Pool oder winziger Tümpel ist sicherlich ok, aber ein See mit 6 Punkten, der einige Hektar groß ist, wohl eher nicht.
Waldgebiete:
Kapier ich irgendwie nicht ganz, aber ich bin auch nicht in der Thematik drin, wie (Wald-)Flächen ideal zu erfassen wären - abgesehen davon, dass OSM-typisch es zig Ideale wohl geben wird ^^
Denke aber spätestens hier wäre es wohl sinnvoll die Auswertung durch andere Tools weiter zu verfeinern. Auch bei dem anderen wirds komplizierter und allem voran geht eine klare Definition dessen, was man eigentlich sucht. Sodass man halt möglichst auch nur das im Pot hat und nicht viel anderes.
Vermutlich wird man sich also einmal viele Daten via Overpass abgreifen und dann anders auswerten. Wo man dann z.B. auch Winkelberechnungen und quasi ein Scoring einsetzt, ähnlich eines Spamfilters. Nur ein Merkmal löst halt nicht gleich eine Treffermeldung aus, aber desto mehr Anhaltspunkte sich summieren, desto stärker wird darauf hingewiesen. So würde ich das umsetzten und dann entsprechend des Scoringwertes durchsuchen.
Aber das ist jetzt kein Angebot zur (kostenfreien) Umsetzung, denn da steckt viel Aufwand drin, was ich z.Z. freizeittechnisch nicht hinbekäme.
Gruß,
asca