Hecken/Wassergräben als Feldbegrenzung - Nodes verbinden?

Mrvn9 wrote:

Zusätzlich handhabe es so, dass ich die Knicks, Hecken und Wassergräben am Rande von Feldern auch nicht mit den Nodes des Feldes verbinde.

+1
Wenn ich so im Detail mappe, halte ich es ebenso. Das folgt konsequent der Regel, dass lineare OSM-Objekte, die real dennoch eine gewisse flächige/räumliche Ausdehnung besitzen, nicht mit den Kanten von Flächen verbunden werden sollten.

Mrvn9 wrote:

Das führt allerdings dazu, dass auf der gerenderten Karte dann weiße Lücken zwischen Feld und Knick auftauchen

Na und? Ich finde das gar nicht schlimm. Eine Karte muss nicht zwingend vollflächig gerendert sein, es darf auch Lücken haben. Es gibt halt Bereiche, die sind weder das eine noch das andere und werden bisher auch noch nicht gemappt.
- bei Wassergräben ist die meist vorhandene Böschung meistens grasbewachsen - da könnte man landuse=grass (bevorzugt bei Straßengräben) oder landuse=grassland nutzen, wenn man es so detailliert haben möchte. Den waterway des Grabens kann man mit Angaben zur Breite versehen, vielleicht berücksichtigt das mal ein Renderer und rendert den Graben so breit, dass keine Lücken mehr entstehen. Alternativ könnte man auch die Wasserfläche mappen, dass wäre aber selbst mir (selbst oft detailversessen) zu viel des Micromappings.
- bei Hecken war es mal so, dass man breite Hecken flächig mit einem area=yes mappen konnte. Das hat man aber leider zu meinem Unverständnis abgeschafft. Im Moment blicke ich in dem Chaos von Taggingvarianten bei Hecken, Knicks und Zierhecken nicht mehr durch, ist mir zu kompliziert geworden und deshalb lasse ich es meistens sein. Aber auch bei barrier=hedge lässt sich deren Breite mappen, bis irgendwann mal ein Renderer das auswerten und entsprechend breit rendert.

Mrvn9 wrote:

das ist meiner Ansicht nach nicht sinnvoll und entspricht ja genau genommen auch nicht wirklich der Realität

Ich finde das so ok wie es ist.

Mrvn9 wrote:

Diese Arbeitsweise erleichtert natürlich auch nachträgliche Änderungen.

+1

Mrvn9 wrote:

Ich finde es mittlerweile allerdings schöner, die entsprechenden Begenzungslinien direkt mit den Nodes der Flächen zu verbinden. Gibt es gravierende Gründe, die dagegen sprechen? Wie sehr ihr das?

Ja, es gibt gravierende Gründe, die dagegen sprechen - nämlich das Gegenteil von:

Mrvn9 wrote:

Diese Arbeitsweise erleichtert natürlich auch nachträgliche Änderungen.

Mach Dir doch einfach mal den Spaß: mappe die Gräben, mappe dazwischen die Äcker und verbinde diese mit den Gräben. Lege das ganze für 4 Woche beiseite und dann überlege Dir, dass ja der Bauer das Feld nicht bis zur Mitte des Grabens beackert, sondern nur bis zum Rand der Böschung. Und dann kommst Du zufällig auf die Idee, dass Du zwischen Graben und dem eigentlichen Feld noch Grasland einfügen könntest. Probiere es aus, alle gemeinsamen Knoten voneinander zu lösen, zu verschieben und dann das Grasland dazwischenzuquetschen.

Und dann haben wir natürlich noch andere Arten der Auswertung. Es könnte ja mal jemand wissen wollen, wieviel Hektar Ackerfläche sich in einem Landkreis befinden. Das Ergebnis wird natürlich um so genauer, je genauer gemappt wurde.

PS: Mut zur Lücke!

Hallo,
willkommen im Forum, mit was editierst du?

Mrvn9 wrote:

...dass auf der gerenderten Karte dann weiße Lücken zwischen Feld und Knick auftauchen...

Wenn du z.B in ID reinzoomst und beim Verschieben der Nodes die Alt-Taste gedrück hälst rastet der Knoten am anderen Knoten nicht ein und du könntes mit deinen Knoten näher zusammenrücken und hättest so dünnere Lücken

Gruß
Danfost

ich finde es auch ok, die Knicks werden halt viel dünner gerendert als sie eigentlich sind, und darum gibt es die Lücke, ist mE auch richtig so, wie bei den Wegen ja auch.

Danfost wrote:

Wenn du z.B in ID reinzoomst und beim Verschieben der Nodes die Alt-Taste gedrück hälst rastet der Knoten am anderen Knoten nicht ein und du könntes mit deinen Knoten näher zusammenrücken und hättest so dünnere Lücken

BITTE NICHT! Der nächste, der die Linie bearbeiten will, muss dann deine Flächengrenzen erst umständlich wieder wegschieben, bevor er an der Linie was machen kann! Ich habe deshalb schon (eigentlich nötige) Bearbeitungen an Straßen unterlassen, weil mir das zu mühsam war.

Immer an den nächsten Bearbeiter denken und es ihm nicht unnötig schwer machen.

Entweder komplett verbinden (also gemeinsame Nodes) oder die Flächen da enden lassen, wo sie auch tatsächlich auf dem Luftbild enden, und die Lücke in Kauf nehmen (finde ich persönlich sauberer).

Mrvn9 wrote:

[...] Das führt allerdings dazu, dass auf der gerenderten Karte dann weiße Lücken zwischen Feld und Knick auftauchen - das ist meiner Ansicht nach nicht sinnvoll und entspricht ja genau genommen auch nicht wirklich der Realität:
[...]

@Mrvn9
in deinem Screenshot sind die "Knicks", also die Vegetationsflächen am Feldrand, wohl vereinfachend linear erfasst - dazu zwingt dich aber kein Mensch.
Derartige Vegetationsflächen können als natural=scrub/wood flächig erfasst werden - mit verklebten Nodes zur angrenzenden Vegetationsfläche.

Eine lineare Baumreihe natural=tree_row, die on the ground auf einer Wiese steht, darf auch in OSM *auf* einer Wiese stehen, will sagen da muss auch nicht zwingend was flächiges "darunter freigehalten werden".

es grüßt die
Masse

Mrvn9 wrote:

dass auf der gerenderten Karte dann weiße Lücken zwischen Feld und Knick auftauchen - das ist meiner Ansicht nach nicht sinnvoll und entspricht ja genau genommen auch nicht wirklich der Realität:

Das kann man so oder so sehen. Ich finde durchaus, dass das der Realität entspricht, denn "weiß" heißt ja nicht "hier ist gar nichts" und auch nicht "hier ist was Weißes", sondern "hier ist nichts Flächiges erfasst". Dass ein nur linear erfasster Knick (gilt genauso für Wege) in hohen Zoomstufen nicht in der wirklichen Breite, sondern viel schmaler gerendert wird, ist ein Problem des Renderers und nicht der Datenerfassung. Das gerenderte Kartenbild hat ja nicht den Ehrgeiz, das Luftbild originalgetreu nachzubauen.

Insofern vermittelt der Übergang "Wiese zu Weißfläche" schon die vollkommen richtige Bedeutung, dass da die Wiese aufhört und eine andere Fläche anfängt, die lediglich nicht flächig, sondern nur als Mittellinie dargestellt wird.

Und wenn wir schon danach gehen, dann entspricht das Verkleben der Wiesenränder mit dem Knick noch weniger der Realität, denn dann sind die Grenzen von Wiese zu Nicht-Wiese vollkommen verschwunden, als seien sie gar nicht da und der Knick hätte null Breite.

Ein Knick wird mit barrier=hedge + hedge=hedge_bank erfassen das war ja das ergebniss meiner frage zum erfassen hier:
https://forum.openstreetmap.org/viewtopic.php?id=74530
Da dort nach #9 auch keine einwende mehr zu gekommen sind habe ich das seit dem auch so mit Tausenden von knicks gemacht. (hatte im Winter viel zeit)

Als ich Monate davor selber mit Landnutzung erstellen angefangen habe wurden von mir aus nicht wissen leider erst alles mit einander verklebt.

Zum glück wurde ich von mehreren mappern drauf hingewiesen wie das richtig zu erfassen ist. Die damals verklebten Gebiete habe ich zwischendurch auch nochmal überarbeitet und bei dem seit dem neu erstelle Landuse wird dann so vorgegangen:

1. Grenzen ausblenden um die nicht mit andren Objekten zu verkleben.
2. Die Landnutzung mit dem abstand zu Straßen + Flüssen erstellen den es auch in echt hat.
Dabei wird die Landnutzung mit Landnutzung verbunden und die linien von Zäunen oder Knicks auf den randlinie der Landnutzung erstellt also damit auch verbunden.

FraukeLeo wrote:

Und wenn wir schon danach gehen, dann entspricht das Verkleben der Wiesenränder mit dem Knick noch weniger der Realität, denn dann sind die Grenzen von Wiese zu Nicht-Wiese vollkommen verschwunden, als seien sie gar nicht da und der Knick hätte null Breite.

Als Knick bezeichnet man dabei schon den Teil vom Ende des einen Feldes über den Bewachsen knickteil welcher meist auf ein kleiner erdwall liegt bis hin zum Anfang des neuen Feldes.
Das ganze ist dabei meist so ca. 2 meter breit.
Aber es gibt dabei vor ort keinen abstand zwischen knick und wiese oder Acker das geht in eins über.
Ein abstand gibt es nur zum Graben und zu den Wegen.

Jo Cassel wrote:

@Mrvn9
in deinem Screenshot sind die "Knicks", also die Vegetationsflächen am Feldrand, wohl vereinfachend linear erfasst - dazu zwingt dich aber kein Mensch.
Derartige Vegetationsflächen können als natural=scrub/wood flächig erfasst werden - mit verklebten Nodes zur angrenzenden Vegetationsfläche.

Eine lineare Baumreihe natural=tree_row, die on the ground auf einer Wiese steht, darf auch in OSM *auf* einer Wiese stehen, will sagen da muss auch nicht zwingend was flächiges "darunter freigehalten werden".

es grüßt die
Masse

Bitte nicht anfangen die bereits erfassten Knicks als mini natural=scrub/wood flächig zu erfassen.
Das war schon vorher die ungenauere möglichkeit knicks zu erfassen.
natural=scrub kann mann zusätzlich nutzen wen es neben dem knick noch ein bewasenen streifne gibt oder das deutlich breite rist als ein normaler knick.

Info für alle die sich fragen was ist ein Knick? Wikipedia Wallhecke: https://de.wikipedia.org/wiki/Wallhecke

Übrigens rein rechtlich darf der Streifen neben dem Knick auch nicht genutzt werden:

(5) Auf Ackerflächen an Knicks darf ein 50 cm breiter Schutzstreifen, gemessen ab dem Knickwallfuß, nicht ackerbaulich genutzt, mit Kulturpflanzen eingesät oder bestellt, gedüngt oder mit Pflanzenschutzmitteln behandelt werden. Die Bepflanzung mit nicht heimischen Gehölzen und krautigen Pflanzen sowie die gärtnerische Nutzung des Schutzstreifens sind unzulässig.

Der Streifen ist aber trozdem ein Teil der Wiese oder des Ackers.

Quelle ist das Landesnaturschutzgesetz von Schleswig Holstein §21 Gesetzlich geschützte Biotope: https://www.gesetze-rechtsprechung.sh.j … H2010V3P21

puma515 wrote:

Das ganze ist dabei meist so ca. 2 meter breit.
Aber es gibt dabei vor ort keinen abstand zwischen knick und wiese oder Acker das geht in eins über.

Das hat FraukeLeo weder geschrieben noch gemeint. Natürlich grenzt der Acker mehr oder weniger an den Knick. Der Knick wird aber in den Daten i. d. R. nicht als Fläche erfasst, sondern als Linie. Diese Linie ist datentechnisch gesehen nur die Verbindung von 2 oder mehr Punkten und hat ohne weitere Angaben keine Breite und wird normalerweise in etwa der Mitte des realen Knicks gemappt.
Du schreibst selbst, dass Knicks i. d. R. 2m breit sind (was ich so pauschal auch nicht sehe, ich kenne breitere und schmalere). D. h. rechts und links der Datenlinie "Knick" befindet sich jeweils ca. 1m Fläche, die nicht Acker oder Wiese ist, sondern Knick, und diese Fläche sollte freigelassen werden.

Wenn osm-carto irgendwann mal wieder zulasst, ein eigentlich implizit lineares barrier mit explizit gesetztem area=yes auch als Fläche zu interpretieren, dann kann man breitere Knicks und andere Hecken auch wieder flächig mappen. Dann wäre auch ein Verkleben angrenzender Flächen ok.

puma515 wrote:

Bitte nicht anfangen die bereits erfassten Knicks als mini natural=scrub/wood flächig zu erfassen. Das war schon vorher die ungenauere möglichkeit knicks zu erfassen.

Es ist im Gegenteil die genauere Möglichkeit, die Fläche zu erfassen statt eine Linie. Ich mappe viele Knicks, und die wenigstens sind "ca. 2 m breit", meistens variiert die Breite über eine gewisse Strecke, es gibt Lücken und schmale Stellen, Rundungen und Ecken, oft sind Knicks auch dreieckig oder trapezförmig. Bei flächiger Erfassung stellt sich die Frage nach den "weißen Lücken" rund um Linienobjekte nicht, auch wenn ich die nicht störend finde.

Mammi71 wrote:

puma515 wrote:

Das ganze ist dabei meist so ca. 2 meter breit.
Aber es gibt dabei vor ort keinen abstand zwischen knick und wiese oder Acker das geht in eins über.

Das hat FraukeLeo weder geschrieben noch gemeint. Natürlich grenzt der Acker mehr oder weniger an den Knick. Der Knick wird aber in den Daten i. d. R. nicht als Fläche erfasst, sondern als Linie. Diese Linie ist datentechnisch gesehen nur die Verbindung von 2 oder mehr Punkten und hat ohne weitere Angaben keine Breite und wird normalerweise in etwa der Mitte des realen Knicks gemappt.
Du schreibst selbst, dass Knicks i. d. R. 2m breit sind (was ich so pauschal auch nicht sehe, ich kenne breitere und schmalere). D. h. rechts und links der Datenlinie "Knick" befindet sich jeweils ca. 1m Fläche, die nicht Acker oder Wiese ist, sondern Knick, und diese Fläche sollte freigelassen werden.

Wenn osm-carto irgendwann mal wieder zulasst, ein eigentlich implizit lineares barrier mit explizit gesetztem area=yes auch als Fläche zu interpretieren, dann kann man breitere Knicks und andere Hecken auch wieder flächig mappen. Dann wäre auch ein Verkleben angrenzender Flächen ok.

Ok habe ich FraukeLeo wohl falsch verstanden.
Aber meine ausage zur breite ist zumindest hier in meiner umgebung richtig denn hier sind die meisten knicks ca. 2 bis 3 meter breit.

Das neben der Datenlinie Knick ein 1m Streifen ist der nicht bewirtschaftet wird ist richtig aber für mich ist das ein Teil der Wiese oder des Ackers der eben nur nicht bewirtschaftet wird. Aber trozdem ist das immer noch ein Teil der Landnutzung.

vademecum wrote:

Es ist im Gegenteil die genauere Möglichkeit, die Fläche zu erfassen statt eine Linie. Ich mappe viele Knicks, und die wenigstens sind "ca. 2 m breit", meistens variiert die Breite über eine gewisse Strecke, es gibt Lücken und schmale Stellen, Rundungen und Ecken, oft sind Knicks auch dreieckig oder trapezförmig. Bei flächiger Erfassung stellt sich die Frage nach den "weißen Lücken" rund um Linienobjekte nicht, auch wenn ich die nicht störend finde.

Sehe ich nicht so das das mit scrub genauer zu erfassen geht. Wenn ich als beispiel diese Fläche von dir betrachte:
https://www.openstreetmap.org/way/987511620

Hier bedecken die knicks gleich die ganze Straße mit. Ich kenne das so das Natur Flächen nicht über Straßen gemappt werden da auf den Straßen ja keine Natur ist.
Die Knicks sind ja immer nur links und rechts von der Straße inklusiv Lücken wo die Zufahrten sind den dort gibt es ja auch keinen Knick.

Zum vergleich mit Linien erfasste Knick bereiche, dabei kann man dann auch gleich so genau erfassen das die Feldzufahrten frei bleiben.
Dazu 2 Beispiele
1. Ein Bereich von mir erstellt: https://www.openstreetmap.org/way/1078929784
2. Ein Bereich wo ein andrer mapper die Knicks als Linien mit Lücken zur Fläche erstellt hat: https://www.openstreetmap.org/way/76649 … 57/9.51795

Wen ich dabei neben einem Knick noch zusätzliche eine Flächen habe die breiter mit Büschern bewachsen ist erstelle ich dort auch neben dem Knick noch eine Landflache scrub.

Mit den Knicks ist das aktuell auch so wie bei vielen andren dingen in OSM.
Es gibt mehrere Varianten wie man was erfassen kann. Jeder findet eine andre besser.

Ich finde mit einer Linie mit barrier=hedge + hedge=hedge_bank geht es am besten da man damit sehr genau erfassen kann und durch den zusatz hedge=hedge_bank ist mann auch in der lage das per overpass zu prüfen wo noch was fehlt das geht mit scrub so nicht.

EDIT:
Ob der Fragensteller die Nodes der Hecken nun verbinden sollte, würde ich mit Ja beantworten.

Der vorgebrachten 1m am Knick / Feldrand Rand zählen nicht da die nur aufgrund der Naturschutzverordnung in Schleswig Holstein nicht bewirtschaftet werden. Das ist aber trozedem ein Teil der Fläche. Der Knick selber Zählt genau genommen zur Landwirtschaftlichen Flächennutzung und dient der Brennholzproduktion der wird bis auf einige Bäume ca. alle 10 Jahre abgesägt.

Die Linie vom Knick sollte man so betrachten das sie die breite des knicks darstellt.
Normale knicks sind hier nicht sehr breit. Die 2 oder 3 meter waren von mir nur ein vorschlag nach was man sich richten kann um zu entscheiden ob man nur ein normaler Knick mappen sollte oder eine breitere Busch Fläche oder befindet sich dort ein Knick und daneben noch eine Buschfläche.
Das kommt dabei immer auf die lage vor ort an.

Die erfassung ist so ja schon so sehr genau da muss man doch nicht noch mehr zeit investieren um die eine Linien 1 mm neben die andre line zu legen in echt gibt es OTG zwischen dem Knick und den Fläche doch auch kein abstand.

puma515 wrote:

Das neben der Datenlinie Knick ein 1m Streifen ist der nicht bewirtschaftet wird ist richtig aber für mich ist das ein Teil der Wiese oder des Ackers der eben nur nicht bewirtschaftet wird. Aber trozdem ist das immer noch ein Teil der Landnutzung.

Du hast das Datenmodell leider immer noch nicht verstanden. Die linie, die Du in die Datenbank einzeichnest ist dünn, genaugenommen unendlich dünn. Völlig unabhängig davon, mit wieviel Pixel Breite diese Linie im Editor oder auf der gerenderten Karte dargestellt wird. Mit dem Meter rechts und links der Linie meine ich nicht den unbewirtschafteten Teil des Ackers neben dem Knick. Vielmehr ist der Meter beidseitig der Mittellinie in Realität noch der Knick selbst und eben gerade nicht Ackerfläche, wie es die Daten suggerieren würden, wenn man die Ackerfläche mit der Mittellinie des Knicks verbindet.

puma515 wrote:

Sehe ich nicht so das das mit scrub genauer zu erfassen geht. Wenn ich als beispiel diese Fläche von dir betrachte:
https://www.openstreetmap.org/way/987511620

Hier bedecken die knicks gleich die ganze Straße mit.  Ich kenne das so das Natur Flächen nicht über Straßen gemappt werden da auf den Straßen ja keine Natur ist.
Die Knicks sind ja immer nur links und rechts von der Straße

Da haste Dir jetzt genau das schlechteste Beispiel herausgesucht. Ja, diese Variante mit der Fläche über die Straße hinweg ist auch nicht die Idealvariante. Dabei hättest Du einfach nur am südlichen Ende die Straßenseite wechseln müssen. Das geht in die Richtung wie es gemeint ist. Und wenn man hier noch Lücken übersehen hat, kann man dir ja noch ergänzen.

puma515 wrote:

Mit den Knicks ist das aktuell auch so wie bei vielen andren dingen in OSM.
Es gibt mehrere Varianten wie man was erfassen kann...
Ich finde mit einer Linie mit barrier=hedge + hedge=hedge_bank geht es am besten da man damit sehr genau erfassen kann

Dieses Chaos hat osm-carto verursacht, seit dem es barrier=hedge + hedge=hedge_bank + area=yes nicht mehr als Fläche rendert.

Das neben der Datenlinie Knick ein 1m Streifen ist der nicht bewirtschaftet wird ist richtig aber für mich ist das ein Teil der Wiese oder des Ackers der eben nur nicht bewirtschaftet wird. Aber trozdem ist das immer noch ein Teil der Landnutzung.

für mich ist die Tatsache dass es nicht bewirtschaftet wird der springende Punkt, evtl. könnte man aus finanzieller Sicht sagen sie sind Teil des Ackers oder der Wiese, aber gerade die Flächennutzung ist anders (außer man nimmt das Flurstück als Einheit und schaut nicht so genau, aber Flurstücke mappen wir nicht und deren genaue Grenzen kennen wir in der Regel auch nicht)

Mammi71 wrote:

Dieses Chaos hat osm-carto verursacht, seit dem es barrier=hedge + hedge=hedge_bank + area=yes nicht mehr als Fläche rendert.

Ja, laut Wiki ist es aber erlaubt und wäre somit die beste Lösung für's Lückenfüllen gewesen.

Okay, vielen Dank für die Antworten! Es scheint ja tatsächlich unterschiedliche Herangehensweisen zu geben.

Ich nehme daraus jetzt folgendes mit:
- Schmale Wassergäben, kleine Knicks und Hecken werden nicht mit den Nodes der Felder verbunden und die weißen Zwischenflächen beim Rendern werden "einfach so hingenommen". Einfach weil es übersichtlicher ist und besser zu Bearbeiten ist.
- Kleine Knicks und Hecken werden als Linie mit barrier=hedge und hedge=hedge_bank getaggt.
- Breite Knicks und Baumreihen werden manchmal auch als Fläche ausgewiesen und mit natural=scrub/wood getaggt. Diese Flächen werden dann auch direkt mit der Fläche verbunden (meiner Erfahrung nach aber extrem, extrem selten)
- Angrenzende Flächen wie bspw. Waldflächen werden direkt mit den landwirtschaftlichen Flächen verbunden, weil diese ja auch in der Realität ineinander übergehen.

chris66 wrote:

Ja, laut Wiki ist es aber erlaubt und wäre somit die beste Lösung für's Lückenfüllen gewesen.

Ja, "wäre", aber irgendjemand war der Meinung, barrier dürfe ausschließlich linear sein und es gäbe ansonsten Konflikte und falsch gerenderte Dinge. Alle Beispiele, die ich überprüft habe, waren aber schlechtes oder falsches Mapping und hatte mit dem area=yes eigentlich nichts zu tun. Ist bei barrier=wall auch nicht anders - dicke und vorallem unregelmäßig dicke Mauern (typischerweise Burgruinen) lassen sich nicht mehr vernünftig darstellen.

Ja, früher wurden Hecken in der Standard-Karte auch als Fläche dargestellt. Ich fand es auch einen großen Rückschritt, als dieses geändert wurde. Aus meiner Sicht müsste es gerade für das zunehmende Detailmapping möglich sein, auch Objekte wie Mauern und Hecken als Fläche einzutragen und dieses sollte dann auch von der Standard-Karte so angezeigt werden.

Galbinus wrote:

Ja, früher wurden Hecken in der Standard-Karte auch als Fläche dargestellt. Ich fand es auch einen großen Rückschritt, als dieses geändert wurde. Aus meiner Sicht müsste es gerade für das zunehmende Detailmapping möglich sein, auch Objekte wie Mauern und Hecken als Fläche einzutragen und dieses sollte dann auch von der Standard-Karte so angezeigt werden.

+1

... trage Hecken seit meinem OSM-Einstieg flächig ein - per natural=scrub - und kann von keinen Problemen berichten.
barrier-Tags sind halt tendenziell für lineare Objekte gedacht, und sollten bei Hecken eben nur bei "linienartig-beschnittenen" Hecken verwendet werden - das kann die Buchsbaumhecke am Haus von Familie Müller sein (vgl. https://forum.openstreetmap.org/viewtop … 49#p850249 ), oder auch sowas:
https://www.openstreetmap.org/#map=19/51.31214/9.40875

Jo Cassel wrote:

(vgl. https://forum.openstreetmap.org/viewtop … 49#p850249 )

Ja das war dort meine frage im letztes Jahr. Die Linien erfassung barrier=hedge + hedge=hedge_bank war dann dort das ergebniss.
Viele von euch haben dort auch danach noch was geschrieben und keiner hatte damit ein problem.

EDIT: Schreibfehler behoben.

🙄 Doppolpost gelöscht