Entzerren von Kartenscans

Nahmd,

Schmollhöhle? Schön wärs ja. Eishöhle!
Hab heute morgen beim überstürzten Aufbruch verpennt, das Fenster zu schließen. :confused:

Wegen des Tilers: die Kritik war berechtigt. Das Teil ausgehfein zu machen braucht aber was Zeit.

Gruß Wolf

Windows-Nutzer können bis dahin vielleicht mit maptiler was anfangen.

Ich würde wohl auch sagen, dass ein Copyshop zunächst mal die erste Anlaufstelle wäre, wie r-michael schon gesagt hat, die machen mal den ersten Schritt professionell. Danach würde ich auch versuchen mit Photoshop oder Gimp (da weiß ich aber nicht wie die Funktionen genau heißen, finde das Programm etwas verwirrend) alles nach zu bearbeiten. Da kann man ja viel machen!

Papierverzug ist nicht ganz was für Laien, die Hardware ist nicht allein entscheidend,
hier ist gemäß http://de.wikipedia.org/wiki/Papierverzug eine Berechnung und die Einrichtung diverser Passpunkte erforderlich. Mit der geeigneten GIS-Software lassen sich dann erstaunlich genaue digitale Karten erzeugen.
Mit Photoshop ist es sicher möglich aber ein Glücksfall, wenn es klappt.

Fragt mal beim nächsten Vermessungsamt nach, manche sind erstaunlich hilfreich.

Kartenscans entzerren kann man auch mit der Freeware Shift-N. Die wird üblicherweise von “Pedanten” benutzt um stürzende Linien auf Kirchturmfotos u.ä. zu beseitigen, wodurch die Perspektive hinterher oft völlig unnatürlich wirkt. Für den Hausgebrauch taugt die auch zum Rechteckigmachen von Kartenscans. Wie gesagt, das muss man nur machen muss wenn man mehrere, nicht überlappende Kartenblätter eines größeren Werks zusammensetzen will. Korrekt georeferenzieren kann man auch ein nichtreckiges Bild, nur wird es in der Darstellung in der Kartenansicht dann umso verzogener und unschärfer wirken je nichtrechteckiger es war.

**EDIT:: BESSER MIT GIMP! (Werkzeuge → Transformation → Perspektive) **

Bei schon im Original welligen, evtl. ohne Lineal gezeichneten Kartenrändern braucht man aber ein echtes Grafikmanipulationsprogramm zum “Beulen entfernen”. Ohne die scheitert auch jede mathematisch noch so korrekte Rückprojektion von Mercator, Kegel oder wasweissich.

Im Arbeitsablauf davon unterscheiden muss man das georeferenzieren/kalibieren - trivial bei diesen Karten mit “gängiger” Längen+ Breitenangabe - und das Tilen, also Zerstückeln der Großblätter von vielleicht 5000x3000 Pixel in “handliche” (wiederum georeferenzierte) Abschnitte. Hierfür verwende ich wie gesagt Glopus Map Manager, weil der entsprechend mächtig ist und Glopus mein PDA (bzw. PC) Kartenviewer.

Die wirklich alten Karten aus der zeit der ersten trigonometrischen Landesaufnahme sind durch das grobmaschige Aufnahmegitter sowieso alles andere als präzise (dafür aber durch den erst in Ansätzen erfolgten Kunststraßenbau umso wertvoller als Quelle). Ich habe jetzt zusätzlich zu Reymann die Preußischen Generalstabskarten/PGK 1:86.400 (Reduktion der Tranchot-Müfflingschen Karten 1:20.000) meiner Heimatgegend georeferenziert, mit anderem Blattschnitt, und (beim Wiederzusammenfügen/Graderichten) anderen Fehlerquellen. Und siehe da, Reymann hat Orte wie Naurod und Niedernhausen bei Wiesbaden etwa nicht selber so “phantasievoll” eingezeichnet, es ist auch nicht Fehlerquelle meiner Scans, sondern er hat einfach die Lage aus der PGK abgekupfert, wo die Ungenauigkeit (etwa 800-1000m; 100m und darunter ist bei diesen Karten genau) wegen des kleineren Maßstabs natürlich viel stärker ins Gewicht fällt.

Nein, diese “Beulen” dürfen entfernt, da schon im Original vorhanden.
Ein “Entzerrung” würde hier eine Verfälschung einführen!

Ich hatte das Gefühl, dass Dir nicht ganz klar ist, dass die Karte bereits in einer Projektion vorliegt, hier lcc.
Die will man aber auch nicht “entzerren”. Was man ggf. will, ist eine Trafo von lcc nach latlon.

Wir haben hier eine Karte mit Maßstab 1:1 Mio, “100 m” sind hier “gar nichts”.

die Preußischen Generalstabskarten/PGK 1:86.400 (Reduktion der Tranchot-Müfflingschen Karten 1:20.000)
gibt es die online auch zum Anschauen?

Danke.

Hier z.B.:
http://www.lgn.niedersachsen.de/portal/live.php?navigation_id=11097&article_id=51345&_psmand=35
http://www.kammertoens.genealogieonline.de/1005779b811480857/9814889d9e0da7901/index.html

Gruß,
ajoessen

Mir wäre schon viel weitergeholfen wenn gewisse Experten sich etwas klarer ausdrücken könnten anstatt nur Brocken hinzuwerfen.
So sind diese Empfehlungen nicht wertvoller als die, Photoshop zu kaufen oder GIMP zu lernen (was man sowieso hin und wieder muss)

Und ich habe den Eindruck, einige bringen das Entzerren, verzeihung Umprojizieren mit dem Georeferenzieren und Tilen durcheinander.
Was darf man mit den Beulen machen, oder nicht?
Ja, es ist mir klar, dass es sich um eine Projektion handelt. Die Karten sind ja nicht gewölbt.
Es geht darum, die trapez- oder kegelförmige Projektion in ein perfektes Rechteck zu verwandeln, dessen Ränder man abschneiden kann, damit sie, wenn in tiles verwandelt, randlos an das Nachbarblatt passen. Der von Dir eingestellte Grafiklink war ebensowenig ein Rechteck wie das Original wie Geogreif. Dieser Schritt ist unnötig beim Georeferenzieren bloss einer einzigen Karte, wo hinter den Rändern “Ende” ist… Das Georeferenzieren oder Kalibrieren kommt als Zwischenschritt nach der Entzerrung, verzeihung Umprojektion, und vor der Umwandlung in tiles.

Nein, es geht um 1:86.400 bzw. 1:200.000, nicht um 1:1.000.000, und wie schon beschrieben, um mehrere Blätter, ohne Überlappung.

Im Moment fotografiere ich diese Karten ab, weil sie nicht sonderlich scantauglich sind (mit einem Makroobjektiv mit 43° Bildwinkel). Mir ist schon klar dass alleine damit eine Verzerrung gegeben ist, und jede Karten an den (georeferenzierten) Ecken genauer sein müsste als in der Mitte, die ja näher zum Objektiv ist. Das ist bei Reprojobs im Copyshop aber genauso. Immerhin ist es kein Laienobjektiv wo einem die spherischen Fehler bei solchen Reprojobs schon ins Auge springen. Inwieweit diese Ungenauigkeit praktische Relevanz hat, genau wie meine laienhafte “Rechteckigmachung” mit einem unbekannten, möglicherweise nicht exakten Algorythmus, zwecks Randentfernung, muss sich zeigen. Da aber die Karten, wie schon festgestellt wurde, eh “fast” reckeckig sind (Abweichung von unter 1%) schätze ich den Fehler auf max. 300m. Das ist “im Feld” nicht schlimm, addiert sich aber zu den anderen Fehlern hinzu und macht es unmöglich sie zuzuordnen, es sei denn man hat eine Vergleichskarte aus einem anderen Blattschnitt, wo der Fehler möglicherweise identisch ist.

Mea culpa, natürlich 1:200000, hatte noch die ONC vom anderen thread im Kopf :wink:

So, hier eine Kurzanleitung:
A)
Wir schauen uns die obere linke Ecke an und bestimmen deren Koordinate:
Recht grob: 50 Grad 45,2 Minuten nördlicher Breite, 25 Grad 12,2 Minuten östlicher Länge.
Ein Blick in osm auf das heute Koblenz: Da kann doch was nicht stimmen? :wink:
Damals (so 1850) hat man nicht Greenwich sondern Ferro benutzt und so müssen noch 17 Grad 40 Minuten “abgezogen” werden:
25° 12,2’ ö. L. - 17° 40’ Ferro-Offset = 7° 32,2’ ö. L.

B)
Nun berechnen wir diesen Punkt - ausgehend von longlat - in den Koordinaten des lcc-Systems mit dem CommandLineTool “cs2cs”:

$ cs2cs +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +to +proj=lcc +ellps=bessel +datum=potsdam +lon_0=12d20 +lat_0=0 +lat_1=47d16 +lat_2=54d54 +no_defs
7d32.2 50d45.2
-337409.31 6348684.69 -1.81

Note:
lon_0=12d20 ergibt sich aus 30° - 17°40’, da Reymann den 30° (nach Ferro) als Mittelmeridian verwendet haben soll.
lat_1 Lat. des südl. Punkt Deutschland
lat_2 Lat. des nördl. Punkt Deutschland

C)
Mit einem Graphikprogramm wird die Karte ohne Rand ausgeschnippelt. Alsbald erstellen wir ein sog. World-File namens 161.wld mit den eben ermittelten Koordinaten sowie den - nach einigem rumspielen - “Streckungsfaktor” 25:
25
0
0
-25
-337409.31
6348684.69

D)
Dem Ergebnis wird obiges lcc-System verpasst (georeferenzieren :wink: :
$ gdal_translate 161.jpg lcc.tif -a_srs “+proj=lcc +ellps=bessel +datum=potsdam +lon_0=12d20 +lat_0=0 +lat_1=47d16 +lat_2=54d54 +no_defs”

E)
Nun transformieren wir unser Bildchen von lcc nach longlat:
$ gdalwarp lcc.tif longlat.tif -t_srs “+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs”

F)
Last but not least wird noch getilet:
$ gdal_translate longlat.tif a.jpg -of JPEG ; java -jar MercatorTiler.jar --image a.jpg --bounds 7.5,50.3,8.5,50.8 --tiledir Coblenz

Wichtig:
Das Endergebnis ist nicht rechteckig (darfs gar nicht sein), da aber die anderen, z. B. “160 Andernach” auch diese Form bekommen, passt das “Puzzle” wieder :slight_smile:

EDIT:
Als Reymann seine Karte 1806 angefangen hat, gab’s weder “bessel” noch “potsdam”, dies und die wahren lat_1/lat_2 überlass ich den Experten.

Nahmd,

“Ich höre euch zwar nicht zu und weiß sowieso alles besser, aber macht mir mein Problem weg”

Die korrekten Begriffe zu benutzen hilft beim Verstehen des hier notwendigen Ablaufes. Du gehst immer noch davon aus, dass die Karten irgendwie verzogen sind und irgendwie verrechteckt werden müssen.

Dieser Ansatz ist falsch.

Was Du bei der Einzelkarte noch nicht siehst: die Blattschnitte oberhalb der hier vorliegenden Teilkarte decken in der Breite mehr Längengrade ab, und die darunterliegenden Teilkarten ** weniger**.

Desweiteren musst Du, wenn Du auf eine Projektion mit waagrecht verlaufenden Breitenkreisen wechselst, die Karten gegenüber dem Scan verdrehen. Je weiter von dem von kellerma angesprochenen Mittelmeridian entfernt, umso mehr.

Weiterhin: Du sagst, dass die Blätter keinen Überlapp haben. Dann kannst Du die nur im Original zusammenkleben (was ich auch empfehle). Wenn Du Rechtecke kleben willst.

Wenn Du eine einzelne Karte umprojizierst (mit Deinen Worten: entzerrst), so dass die Meridiane aufgerichtet werden, so wird die Karte als ganzes trapezförmig (genauer: ein Trapez mit Kreisbögen (sehr) großer Radien als Seiten). Außerdem werden die Einzelblätter dabei unterschiedlich gedreht. Du kannst natürlich diese Trapeze zusammenkleben. Die passen genau so gut wie die Original-Rechtecke. :slight_smile:

Wenn Du allerdings die Trapeze auf rechteckig beschneiden willst (wohlgemerkt, das ist nach der “Entzerrung”, die "Entzerrung besteht gerade darin, die Karte zu manipulieren), gehen Teile jedes Blattes vorloren. Und wenn die Blätter keinen Überlapp haben, ist das endgültig: Du hast Löcher in der Gesamtkarte.

Zusammengefasst: Du willst:

  1. senkrechte Meridiane und waagrechte Breitenkreise (die brauchst Du, wenn Du die Karte als Overlay über OSM/Google/Bing/you name it-Slippymaps legen willst.
  2. aus den Einzelblättern zusammenklebbare Rechtecke bekommen, und
  3. keinen Verschnitt (weil Du keine Löcher in der Zielkarte haben willst)

Das sind ja gleich drei Wünsche auf einmal… doch Du bekommst nur zwei erfüllt. Ätsch! :wink:

Doch warum soll es Dir besser ergehen als den Kartographen und Mathematikern der letzten Jahrhunderte?

Meine Empfehlung: klebe die Karten im Original zusammen – wenn nötig bei einem Graphiker mit entsprechend ausgestattetem Rechner. Der kann Dir auch optische Verzeichnungen “wegmachen”. Aber er soll die Finger von Meridianen&Co lassen. Auf das Ergebnis wendest Du dann das von kellerma detailliertest beschriebene Verfahren an. Bingo.

Das Gesamtergebnis ist natürlich ein Trapez. Das aber kannst Du beliebig beschneiden – oder auch einfach trapezförmig lassen.

Gruß Wolf

Ich will mich gar nicht groß einmischen oder Verwirrung stiften, aber mit dem Programm “PTLens” kann man die Krümmung des Objektivs (bei einer Fotografie) herausrechnen lassen. Dazu braucht man allerdings die Kamera- und Objektivdaten.
http://epaperpress.com/ptlens/

@MasiMaster

Das Problem ist nich die Vingettierung und Chromatische Aberation…
Da sollte bei guten Cameras (Spiegelreflex) ein Programm beiliegen das dies ausgleicht.
Auch das Drehen wenn es etwas schief aufgenoimmen ist ist hier nicht das Thema

@ Beitag von Kellerma
Bis Punkt “F” ist das so in Ordnung (= nee gedrehte und gezerrte Karte)
Das Problem und da will ja evtl. der Themenstarter hin ist das MercatorTiler.jar immer nur eine Karte bearbeitet - es währe purer Zufall wenn die Kartengrenze zufällig mit einer Tilegrenze zusammenfallen würde(= irgendwo müssen in einem Tile 2 Kartenteile rein).

Im prinzip muß aus den überlappenden/angrenzenden [wenn die unten aneinandergrenzen müssen sich diese oben überlappen] Karten (mindestens 2) eine gemacht werden.
Ich kenne eigentlich nur ein Programm das etwas ähnliches macht wenn auch eigentlich in die andere Richtung ( 1 bis mehrere große Karten viele kleine Karten). Für hinweise für Programme die sowas machen können hät ich nichts dagegen.

Ich danke für Euer Feedback.

Ich werd am Wochenende mal versuchen Deine Beschreibung, Kellerma, nachzuvollziehen - bis “A” war es mir schon mal nicht neu :slight_smile: - soweit mir das als Commandline Dummi gelingt. Ich muss zuvor einige der Karten neu abfotografieren die mir noch zu unsauber sind (die Probleme gehen noch weiter: die Karten enthalten Knicke, die das Bild wölben, sie sind auf schlechtem Papier gedruckt und kontrastschwach… und und und)

Ich hab den Eindruck dass der Glopus Map Manager, den hier keiner zu kennen scheint, mir die Ausrichtung der Karten anhand des Mittelmeridians des Kartenwerks abnimmt, und auch die Umprojektion der Rohkarten überflüssig machen müsste, weil Glopus die Karten nicht bloss oben links sondern an 4 beliebigen Punkten der Grafikdatei, sinnvollerweise Kartenecken, georeferenziert und man die Art der Projektion einstellen/auswählen kann. World-files benötige ich am Ende nicht; Glopus hat da eine eigenen Kalibrierungsstandard, der sich mit ein paar Hilfsprogrammen aber in gängige Formate umrechnen lässt, sicher auch world-files. Soweit bin ich noch nie durchgestiegen denn ich verwende weder Google Earth noch erstelle ich (bisher) meine eigenen Karten. Obwohl ich das, was Netzwolf an historischen Karten gezeigt hat schon sehr nett finde.

Was leider fehlt beim Glopus Map Manager, ist die Funktionalität des Abtrennens der Papierränder einer Rohkarte, sozusagen alles abzuschneiden was außerhalb der Eck-Referenzpunkte der Rohkarten liegt, und erst hinterher zu tilen. Das macht zwar keine Schwierigkeiten mit der Kalibrierung, aber bewirkt eben dass auf den berechneten Tiles diese Ränder die Inhalte der benachbarten Tile verdecken, auch wenn es nur 7mm sind. Und das sieht halt hässlich aus und es “fehlt was”. Vielleicht hab ich die Frage auch im falschen Forum gestellt und jemand anders der Glopus benutzt kennt den Trick.

Für mich ist die Beschäftigung mit dem Thema noch recht neu, weil es mir erstmals überhaupt gelungen ist die hier genannten Karten in befriedigender Qualität zu digitalisieren. Das ist sicher erst der Einstieg. Ich hab, seit fast 20 Jahren, noch eine Sammlung von A4-Handscans von KDR Karten (1:100.000) aus der Zeit 1875-1945 in befriedigender Qualität, die stehen dann hinterher an. Diese Karten haben mir in der Altstraßenforschung schon gute Dienste geleistet und sind verglichen mit den PGK und Reymann topographisch sehr präzise; aber um etwas von ihnen zu haben müssen diese Probleme gelöst sein…

Das mit dem Glopus Map Manager dürfte einigen schon bekannt sein.
Nur habe ich es noch nicht damit geschaft die Projektion zu ändern.
Normalerweise stört das nicht (bei kleinen Zoomstufen) weil mach aus großen Karten viele Kleine und durch die 4-Punktkalibierung ist der Fehler normalerweise unter 1 Pixel.

Deshalb erstmal wie von Kellerma umprojektieren und dann mit Glopus Map Manager (alle Karten auf einmal) Neu Berechnen lassen und als 4000*4000 Pixel-Karten ausgeben. Diese kann man ja weil GEODETIC in einem Graphikprogramm zusammenstitchen.

Und da der MercatorTiler.jar auch mit großen BMP’s umgehen diese dann als Tile ausgeben.

Ja Noch: Bei dem Kartenrand sollte doch einfach ein Abschneiden der Ränder des Orginalfotos reichen oder sehe ich da was falsch?

Nahmd,

Das aber kann doch jede Bildverarbeitung? Polygon aus 4 Punkten setzen, clippen (Fläche außerhalb wird transparent), speichern, done.

Wir haben hier (Köln) einen kalibrierten A3-Überformat Heidenhein-Scanner stehen. Damit ist die AV von 1885 gescannt. In vernünftigem Umfang können wir da auch Deine schweren Fälle drauflegen. Das Gute ist die große Fläche, da braucht man die alten Karten nicht zu quälen. Und ich glaube, die Kiste weiß noch nicht einmal, wie man “Verzeichnung” schreibt.

Glücklicher!
Ich bin immer noch auf der Suche nach antiquarischen AV-Karten; die werden aber oft nur zur horrenden Preisen angeboten. :frowning:

Gruß Wolf

“Nachdem” sie im GMM kalibriert ist, meine ich. Sozusagen in der (rechteckigen) Bildschirmansicht…

Die einseitige 0,7% Verzerrung habe ich jetzt mit GIMP rausgekriegt (Perspektive korrigieren) und konnte die Ränder grade abschneiden. Das mit den “Beulen” beschäftigt mich noch.

Der wäre für die alten KDR-Karten mit ihren ungeheuer feinen Details wohl genau richtig, die haben annähernd A3. Die PGK hat denselben Blattschnitt und ist leider etwas über A3. Meine PGK-Drucke sind allerdings wellig, total vergilbt, ein paar haben Knicke (weil ich sie mal versucht habe stückweise einzuscannen) und das Papier ist faserig und billig, der “antiken” Wirkung wegen. Ich muss sie wohl eh neu anschaffen (LV Hessen); sie sind nicht teuer.

Wenn Du Karten der Alpen suchst, hast Du’s schon mal an der nächsten Unibibliothek probiert? (wobei, wenn Du aus Köln bist…)

Zum Erzeugen von Tiles aus mehreren Kartenteilen hatte ich mal gdal2tiles zusammen mit dem GDAL VRT Meta-Format verwendet. gdal2tiles wird auch in dem bereits erwähnten MapTiler verwendet.

Beispiel für zwei Kartenteile (karte-1-0.png und karte-1-1.png):

  1. Kartenteile georeferenzieren (hier über Eckpunkt-Koordinaten), vrt XML Datei enthält Referenz auf png Datei

gdal_translate -of VRT -a_srs EPSG:4326 ^
-a_ullr 9.33164083610756 47.7346276156722 9.38562491608134 47.7159923753746 ^
karte-1-0.png karte-1-0.vrt

gdal_translate -of VRT -a_srs EPSG:4326 ^
-a_ullr 9.33189174563309 47.7175022162899 9.38585813297247 47.6988579268 ^
karte-1-1.png karte-1-1.vrt

  1. vrt Dateien der Kartenteile zu einer Datei (karten.vrt) mergen (nur virtuell im XML, pngs weiterhin separat)

gdalbuildvrt karten.vrt karte-1-0.vrt karte-1-1.vrt

  1. gemeinsame Tiles für alle Kartenteile erstellen

gdal2tiles -z 8-16 karten.vrt tiles

Die Tile-Nummerierung erfolgt allerdings nach dem TMS Schema mit umgekehrtem y-Ursprung. Das kann man aber per Script umbenennen.

Bei rechteckigen Teilen mit leichter Überlappung hat die Methode gut geklappt, wie gut das in diesem Fall funktionieren würde, kann ich aber nicht sagen. Die gdal_translate aus obigem Beispiel müssten im Schritt F) der Anleitung von kellerma vermutlich in etwa so aussehen (nicht getestet):


gdal_translate longlat.tif -of VRT longlat.vrt

Gruß,
Norbert (ikonor)

Hi ikonor,

dass mit VRT und gdal2tile.py ist ein guter Hinweis!
Vgl. auch http://code.google.com/p/tilers-tools/

Oh, dann ist isse ja gar kein “+proj=lcc +lat_1=47d16 +lat_2=54d54”,
sondern ein “+proj=eqdc +lat_1=50 +lat_2=50”
oder so ähnlich :wink:

Die gute Nachricht: Es geht!
Die schlechte: Anders als erwartet :wink:

Bin gestartet mit “141 Cöln” und “161 Coblenz”.
Nota bene: Die beiden Karten stoßen “diagonal” zusammen, d. h.
lower right lr(141) = upper left ul(161)
A) + B) wie gehabt.
Statt wld-File mit “-a_ullr” georeferenziert, erspart das mühsame “Skalierungsfaktor rumgerechne”.
dann gdal_translate nach vrt mit ikinor-Methode, anschließen ge-warp-t.
Zum Anglotzen zurück ins jpg: Soweit so gut.

Jetzt “160 Andernach” mit ins Boot geholt, ergibt quasi “Karten-Dreieck” und
nun ist letzteres nicht mehr “tight” an den anderen beiden anliegend,
da ur(160) js nicht verwendet wird bei der 2-Punkte-Kalibrierung (nur ul(160) sowie lr(160).
Versucht via “gdal_translate -gcp” einen 3. Kalibrierungspunkt “reinzumogeln” (nämllich ur(160) was ja = lr(141) = ul(161) ist), aber nun steigt gdalbuildvrt beim mergen der 3 Teilkarten aus :frowning:

Zu guter letzt in qgis “3-Punkte-Kalibrierung” am 160er vorgenommen, und nun stoßen die 3 zusammen.
Bei 4er-Kalibrierung an jeder Teilkarte mit lr(n)= ll(n+1), ur(n) = ul(n+1), etc. und darunter/darüber entsprechend:
Alles wird gut ™

Zum Thema HISTORISCHE KARTEN ein gigantischer Link:

http://www.davidrumsey.com/blog/2011/4/10/karte-des-deutschen-reiches-1893

Diese Karten können für Glopus auf einfachste Weise kalibriert werden.
Die Auflösung dieser scans ist für “normale Kartenzwecke”, um es nicht übertrieben zu formulieren, mehr als hinreichend.

Muss ich zur KDR (Karte des Deutschen Reiches) etwas sagen? Ich denke, in einem so speziellen Forum sollte jedes Lob dieses Kartenwerks überflüssig sein weil jeder seine Bedeutung und sagenhafte Qualität kennt oder zumindest kennen sollte. :slight_smile: