das System der Schlüssel

Ich versuche grad das System der Schlüssel zu verstehen: Zur Beschreibung von realen Objekten wird ein Schlüssel und ein Wert verwendet Beispiel: highway=residental Die meisten Haupt-Schlüssel haben noch Unterschlüssel Beispiel: name=* Was eine Strasse ist, ist klar. Aber schon der Unterschied zum “Weg” oder gar “Fahrradweg” ist fragwürdig. Völlig konfus wird es bei “amenity”, “leisure” oder “touristic”. Mir ist unverständlich, wozu diese wischiwaschi-“Über”-Kategorien sinnvoll sein sollen? Sinnvoller fände ich, wenn den Haupt-Schlüsseln mehrere Kategorien zugeordnet werden könnten. Dann kann eine Strasse sowohl als Fahrradweg, als auch als Strassenbahntrasse oder Abwassergraben genutzt werden. Dann bräuchte man sich auch nicht mehr streiten, ob nun ein Schlüssel hier *oder *dort hin gehört. - - - - Nun brauche ich einen Schlüssel zur Bezeichnung von Müllentsorgungsstellen in Häfen. Dazu finde ich: {{Tag|amenity|recycling}} {{Tag|waterway|waste_disposal}} {{Tag|amenity|waste disposal}} Ich brauche aber: - Müllcontainer (alles durcheinander) - Öl, Diesel Emulsion - Fäkalienabsauganlage Wo baue ich das nun wie ein oder zusammen? Einen Versuch habe ich bei Tag:amenity=waste disposal gestartet, weiss aber nicht wie das funktionieren soll, wenn an einer Müllentsorgungsstelle mehrere verschiedene Müll-Arten entsorgt werden können? Gruss, Markus PS: und was Müll mit “Anmut” und “Annehmlichkeit” zu tun hat verstehe ich sowieso nicht - für mich ist Müll eher stinkig und dreckig, vor allem wenn das mit der Fäkalienabsaugung daneben geht…

Darf ich nochmal nachfragen: wer kann mir das *System *der Schlüssel erklären? Danke Markus

Hi, ich denke aus physikalischer Sicht kommst du mit einem chaotischen System am nähesten an das von OSM. Jeder dem ein Tag fehlt denkt sich halt eins aus und steckt den Wert in irgendeinen Schlüssel. Gerade bei leisure und amenity gehts da drunter und drüber. Für was ist eigentlich man_made gut? So kommst dann auch manchmal zu gleichen, bzw. ähnlichen Tags in verschiedenen Kategorien. Gruß zorque

Hallo Zorque,

lach - ja, so sieht es aus! Aber wie machen das die Renderer? wie gehen die damit um? Ein Renderer arbeitet ja nach Regeln: er nimmt Daten aus den Schlüsseln und ihren Werten, “überlegt” sich, was der Kartograf wohl gemeint hat, und macht daraus - unter Berücksichtigung der benachbarten Objekte und des Gesamtbildes - eine hübsche Darstellung. Der Kartograf ist über das Ergebnis erfreut - oder entsetzt. Er versucht zu “verstehen”, nach welchen “Regeln” der Renderer wohl arbeitet. Seine Vermutungen nimmt er dann als Basis bei künftigen Objektbeschreibungen. Da setzt er dann mal einen Schlüssel dazu oder lässt einen weg, oder erfindet einen zusätzlichen - alles in der Hoffnung, dass ihn der Renderer jetzt so versteht wie er es eigentlich gemeint hatte. Und der Renderer denkt sich auch zu den neuen Schlüsseln irgendwelche Regeln aus. Also der eine denkt dass der andere denkt, dass der eine wohl gedacht hatte dass der andere gedacht hätte… Da hilft auch das Mantra: “wir arbeiten nicht für den Renderer” ziemlich wenig. Wäre es da nicht einfacher, die Regeln zu veröffentlichen? Beispielsweise zentral in der Liste der Objekte? Oder noch besser: die Regeln gleich fest in den Vorlagen der Editoren abzubilden? (und die Vorlagen automatisch bei jedem Login zu überschreiben?) Gruss, Markus

Hiho, der Renderer denkt ja nicht von alleine, da sitzen Menschen dahinter. Bei Osmarender ist das oft der Kartograph selber, der gleich festlegt wie seine neuen Tag gerendert werden sollen. Bei Mapnik sind das die Engländer, die (mehr oder weniger) machen was sie wollen. Wenn irgendwas gerendert wird siehts jemand und denkt sich, das nimmt er so mit diesem Tag auch auf. Andere haben neue Sachen mit neuen Tags, bauen sie aber nicht in die Renderregeln mit ein. Dann siehts vielleicht auch jemand oder fragt wie er ein ähnliches Problem mappen könnte oder schaut auf Tagwatch. Und wenn es sinnvoll ist das zu rendern und auch häufig verwendet wird tauchts auch irgendwann auf den Karten auf. Gleiches beim Routing, bsp. openrouteservice. Wenn ein einzelner dahinter steht, nimmt man einfach Kontakt auf und sagt ihm, dass man es gern hätte, dass access=delivery genauso gehandhabt werden soll wie access=destination, weil man Kurierfahrer ist. Und dann baut ers ein oder nicht, wenn ers nicht für sinnvoll hält. Gruß

Markus, ich habe hier ziemlich schnell gelernt daß die Frage die Du hier aufwirfst ein spezifisch deutsches Problem ist. Es scheinen tatsächlich im Wesentlichen die deutschen Mapper ein Problem damit zu haben daß der Regelkatalog nicht eindeutig und voll-systematisch ist. Es geht hier aber nicht darum, den Katalog so lange umzumodeln bis er dei Welt an sich abbilden kann (was sowieso zum scheitern verurteilt ist), sondern es geht darum, ganz pragmatisch eine Karte zu bauen. Dazu taugt das chaotische, weil organisch gewachsene System ganz gut und also solltest DU es einfach mal so nehmen und nutzen wie es ist, bzw Ergänzungen vorschlagen, wozu es ja schließlich Abstimmungsmechanismen gibt. Die Alternative wäre daß Du ein eigenes Projekt startest dem Du einen systematischen Schlüssel nach DSeinen Vorstellungen zugrundelegst. Also: Willst Du mappen, dann mappe mit dem was Du hast und lamentiere nicht über die Unvollkommenheit der Welt. Willst Du eine besere Welt, dann bau sie und such Dir Mitstreiter dafür. Stefan

Hi Stefan, sehr scharf erkannt und gut zusammengefasst finde ich. Meiner Meinung nach ist Evolution des bestehenden Systems die (durchsetzbare) Lösung. Gruß zorque

Nachdem ich das Ganze nun seit einigen Wochen beobachte, verdichtet sich mein Eindruck, dass im Chaos der Schlüssel viel Energie im Nirvana entfleucht… Der Durchschnitt-OSMer hat ja vermutlich vorwiegend zwei Interessen: 1. er möchte ein Gebiet als Karte nutzen (z.B. in eine Website einbinden, auf das Navi laden) 2. er möchte mit den Daten eine Anwendung verknüpfen (Routing, Layer) Daten als Karte Hier geht der OSMer folgendermassen vor: Er zeichnet Punkte, Linien und Flächen. Dann überlegt er, mit welchen Schlüsseln er die Eigenschaften des realen Objektes am besten beschreibt. Und jetzt entfaltet sich folgender Mechanismus: Der Renderer versucht, aus den verschiedenen Häufigkeiten von Sets von Schlüsseln zu erahnen, was denn der Vermesser damit gemeint haben könnte. Oder er mach, unabhängig von den Wünschen der Vermesser einen eigenen Plan. Aus dieser Interpretation, gemischt mit seinem eigenen “Plan” wählt er dann eine Darstellung. Der Vermesser sieht auf dem Bildschirm, dass mit dem Set an Schlüsseln, die er einem Objekt zugeordnet hat, dieses anders dargestellt wird, als er sich das wünscht. Also spielt er solange mit Veränderungen, bis das Bild in etwa dem entspricht was er will. Dieses wiederum verwirrt den Renderer, der frustriert beschliesst, sich nicht mehr um das chaotische Hin und Her der Vermesser zu kümmern, sondern nur noch nach eigenem “Plan” zu handeln. Der Vermesser ahnt, dass hinter den Darstellungen ein “Plan” bestehen könnte. Also versuchte nun seinerseits diesen zu erahnen, und sich bei der Wahl seiner Schlüssel an der Ahnung dessen was er glaubt was sein könnte zu orientieren. Eine direkte Kommunikation findet nicht statt. Alles erschöpft sich im “Orakeln”. Ein Neuling hingegen tut das scheinbar Vernünftige: er fragt, mit welchen Schlüsseln denn nun ein Objekt am besten zu beschreiben sei. Im Wiki findet er dazu widersprüchliche Informationen. Wenn er sich (irgendwann) zum Forum oder gar zur Mailingliste durchgehangelt hat, entfacht sich dort eine chotische Diskussion der erfahrenen OSMer darüber, wie diese es denn selbst handhaben (jeder anders!) und was denn nun “sinnvoll” oder gar “richtig” sei - mit dem häufigen Ergebnis, dass entweder a) nichts klar ist, oder b) man sich auf eine Variante einigt. a) hilft natürlich niemandem, und b) zumindest solange nicht, wie das Ergebnis nicht sowohl den Renderern mitgeteilt (und von diesen konsequent umgesetzt) wird, als auch im Wiki verständlich, eindeutig, umfassend und vor allem zentral und einfach wiederauffindbar dokumentiert wird. Folglich wiederholt sich dieselbe Schleife immer wieder. So, dass sogar die Erfahrenen manchmal keine Lust mehr haben, sich über die Schlüssel Gedanken zu machen. Die Folge: viele geben entnervt auf, einige beschränken sich auf die wenigen Schlüssel, die sie glauben verstanden zu haben (und überlassen den Rest “den Fachleuten”, dass die es “schon richten” werden). Das Chaos lebt weiter, wird vielfältiger und mit Zunahme der Datenmenge und der Akteure entsprechend undurchsichtiger. Daten in Anwendung Völlig chaotisch wird es aber, wenn jemand versucht, die Daten für eine Anwendung zu nutzen. Anwendungen sind immer regelbasiert. Ein Routing-Programm muss beispielsweise feststellen, welche Strassenabschnitte für welche Achslast und/oder Durchfahrtshöhe zugelassen ist, oder welche Wege für Fussgänger auch ohne Gummistiefel zur Benutzung geeignet sind. Und wenn diese Information nicht eindeutig aus den den Elementen zugeordneten Schlüsseln hervorgeht, dann kann das Programm eine entsprechende Frage eben nicht beantworten. Oder wenn ein anderes Programm die Waldflächen berechnen möchte, dieser aber mal als “Urwald”, mal als “Nutzwald” mit jeweils chaotisch wechselnder Zuordnung beschrieben ist, dann kapituliert jedes Programm. Ideologie Eine der OSM-Ideologien heisst: jeder darf machen was er will - was gut ist wird sich durchsetzen. “Alles dürfen” ist ein wesentlicher Motor für Kreativität und Entwicklung. Es ist die Grundlage für den rasenden Erfolg von OSM, für die gegenwärtige exponentielle Entwicklung. “Das Gute wird sich durchsetzen” ist hingegen eine recht undifferenzierte und eher “magische” Hoffnung. Damit sie sich erfüllt, muss Energie aufgewendet werden, und zwar gezielt in Richtung “gut” - was eine Definition dessen was man denn unter “gut” verstehen will voraussetzt. Sonst entsteht eher Chaos, undifferenzierter Einheitsbrei, Energieverlust und Energielosigkeit. Lösung Ein Ausweg könnte sein: 1. einen zentralen Ort festlegen, wo Erkenntnisse und Vereinbarungen abgelegt werden können 2. jede Vereinbarung dort verständlich, eindeutig, umfassend dokumentieren 3. jeder (Vermesser, Renderer, Entwickler) richten sich nach den dokumentierten Vereinbarungen “Evolution” erfolgt dann durch Entwicklung, Veränderung und erneute Dokumentation solcher Vereinbarungen. Gruss, Markus

Das versteht ich nicht so ganz. Der Renderer hat doch feste Regeln und versucht nichts zu erahnen. Es ist vielleicht nicht immer ganz klar welcher Tag denn was bedeutet, aber ansonsten ist es doch zumindest theoretisch klar geregelt. Jedenfalls weiß ich nicht was du mit ‘Häufigkeiten’ meinst.

Da kann ich jetzt natürlich nur für mich sprechen, aber ich habe bisher nicht mit Tags rumprobiert, damit etwas richtig gerendert wird. Letztendlich ist doch auch nicht wichtig ob der Renderer in diesem Moment schon alles richtig macht, sondern ob es überhaupt richtig getaggt ist. Aber genau das ist eben manchmal unklar.

Ist ein Renderer eigentlich keine Anwendung?

Einen zentralen Ort gibt es ja schon, das Wiki. Leider ist dort eben vieles entweder veraltet, nicht umfassend genug beschrieben oder (noch) nicht fertig diskutiert (soweit man überhaupt von fertig reden kann, seine Meinung kann man ja immer dazu abgeben). Dass sich jeder nach festen Vorgaben richtet widerspricht ja, wie du schon gemerkt hast, der ‘Ideologie’ von OSM. Allerdings habe ich den Eindruck, dass viele eigentlich lieber etwas Vorgegebenes benutzen, als sich selbst etwas auszudenken. Sich eigene Tags auzudenken erfordert zum einen, dass man sich damit beschäftigt was sinnvoll und zum anderen muss man damit rechnen dass es sonst von niemanden benutzt wird (und damit der Nutzen nicht allzu groß ist). Aber ich denke so streng muss man auch garnicht sein, in keine der beiden Richtungen. Ich bin dafür, dass schon vorhandene Tags gut dokumentiert und gewisse Standards festgelegt werden, damit sie jeder einfach finden und benutzen kann, sofern das gewünscht ist. Allerdings sollte auch jeder weiterhin die Möglichkeit haben, zusätzlich zu den dokumentierten Tags auch selbst ausgedachte nutzen zu können. Gruß

mit “Renderer” meinte ich: die Menschen, die sich die Regeln für das Renderingprogramm ausdenken. Gruss, Markus

Hiho, jetzt hab ich ne Weile überlegt, was ich hier für ein Statement bringen könnte und nach dem Lesen der Mailingliste von heute ist mir was aufgefallen. Die Diskussionen von denen du (richterweise) meinst, dass in ihnen Verallgemeinerungsgedanken verlaufen, werden meiner Meinung nach eben durch solche Intensionen ausgelöst. Die Welt da draussen ist einfach zu komplex um die durch wenige (!) Tags darzustellen. Zwei aktuelle Beispiele: Jemand bringt einen konkreten Feldweg als Beispiel und fragt wie man den Taggen könnte, ein paar Leute denken sich was aus und dann kommen 100 andere mit realen und teilweise auch konstruierten Beispielen warum das jetzt aber nich gehen könnte, weil es dann im Widerspruch zu einem anderen Weg in einer Ähnlichen Situation stehen könnte. Da kommen dann Beispiele teilweise von seltsamen Wegen, teilweise auch von Gegebenheiten die offensichtlich mit den offiziellen Regeln (also denen vom Staat) im Widerspruch stehen. Anderes Beispiel: Die Diskussion ob man nun Default-maxspeeds als maxspeed kennzeichnen soll oder nicht oder wie auch immer. Ich weiss nicht wieviele Paragrafen sich in der STVO der maximalen Geschwindigkeit widmen, dazu kommt sicher auch noch ein Stapel Gerichtsurteile. Wie soll das alles in ein einzelnes maxspeed-Tag zu verpacken sein. Meines Erachtens rührt daher auch das von dir sg. Chaos in den Tags. Die hat jemand erfunden um eine konkrete Situation damit zu beschreiben. Andere haben versucht ähnliche Fälle damit abzubilden, wieder andere versuchen Dinge damit zu beschreiben die nicht mal mehr ähnlich sind zu dem wofür die Tags geschaffen wurden. Keine Ahnung ob jemand nachvollziehen kann, was ich meine. Ich poste es halt mal Gruß zorque

Hallo Zorque,

Ja, das ist so. Das schafft nicht mal Wikipedia mit seinen 700.000 Artikeln. Aber wenn wir die OSM-Daten sinnvoll verwerten wollen, dann brauchen wir ein möglichst für alle gleiches eindeutiges Verständnis dessen, was einzelne Daten bedeuten sollen. Die Bezeichnung eines Schlüssels “Wald” beispielsweise ist erst mal eine sinnfreie Worthülse, deren Bedeutung erst durch die Beschreibung des Inhaltes definiert wird. Wenn der eine meint, “Wald” sei Urwald, ein anderer darunter aber Nutzwald versteht, dann reden sie so lange aneinander vorbei, bis sie das geklärt haben. Wenn der Eine sagt: “Urwald”={{Tag|natural|wood}} “Nutzwald”={{Tag|landuse|forrest}}, das aber nicht zentral so dokumentiert, dass Dritte Zugang haben, dann hilft das wenig. Wenn die Dokumentation genau andersrum übersetzt wird, entsteht Chaos. Genauso wenn einer sagt, man solle doch immer {{Tag|natural|wood}} und {{Tag|landuse|forrest}} *gleichzeitig *benutzen. Oder wieder ein anderer festlegt, man solle *keinesfalls *beides gleichzeitig benutzen. Wenn die Information darüber, was man denn unter “Wald” verstehen wolle, an beliebigen Orten verteilt wird, dann entsteht nie etwas Einheitliches und Verwertbares. Wenn ein “Punkt als Kirche” mit einem Symbol dargestellt wird, eine “Fläche als Kirche” aber weder als Symbol noch als Gebäude, und die Datensammler dann zusätzliche Schlüssel in beliebiger Reihenfolge dazuschreiben in der Hoffnung, dass jetzt wenigstens etwas erkennbar wird, dann entsteht Chaos. Zur Beschreibung von Objekten benötigen wir messbare Kriterien: “Nadelwald” wenn >x% Nadelbäume, “Laubwald” wenn <x% Laubbäume, “Mischwald” wenn… Oder Strassenbelag=Beton|Asphalt|…, Strassenbreite=#Meter, maximale Achslast=#Tonnen, etc. Und wir benötigen Rendererschreiber, die die Kirche sowohl als Punkt als auch als Fläche darstellen. Und die Rendererschreiber und die Datensammler müssen gegenseitig Pflicht-kommunizieren! Gruss, Markus PS: Relative Inhalte (Weg A ist besser als Weg B) und Inhalte ohne definierten Massstab (Grade 1…5) sind zur Beschreibung von Objekten nicht geeignet.

Hallo Zusammen, ich sehe auch die Bedenken von Markus und bin der Meinung dass es da nötig ist das ganze zu strukturieren und zentral zu dokumentieren. Wir sprechen hier von Geodaten und nicht von Fliesstexten wie in Wikipedia. Beim OMS geht es um eine Datenbasis und da kommt man mit einem Chaos nicht weiter. Ich programmiere jeden Tag Anwendungen zur Datenerfassung und späteren Auswertung. Wenn ich dem Anwender beim eingeben eines Betrages nicht ein klares Format vorgebe erhallte ich bei 5 Anwendern 5 unterschiedliche Möglichkeiten einen Betrag von € 2534.50 einzugeben: € 2534.50 2534.50 EUR 2534,50 € 2’534.50 € 2,534.50 Es wird alle Varianten von Komma und Punkt geben und solche mit der Währung vorn oder hinten und sogar ohne Währung. Jetzt programmiert mal eine Logik um diese Beträge zu summieren. Das braucht ein wenig Aufwand ist aber sicher möglich. Wesentlich einfacher ist es jedoch die Eingabemaske zu strukturieren und mit einer Prüfung zu versehen. Das währe in diesem Beispiel folgende Struktur. Ich habe zwei Felder: Betrag und Währung. Im Betrag lasse ich nur den Punkt als Trennzeichen zu das Tausender Trennzeichen darf somit nicht eingegeben werden. Im Währungsfeld prüfe ich auf eine Liste mit allen Währungen und zwar nach der ISO Norm, das währe dann EUR oder CHF. Adaptiert auf OSM geht mein Vorschlag also noch weiter: Einzig wenn beim Daten erfassen die Eingabe einer Prüfung unterstellt ist und der Erfasser direkt bemerkt dass er hier etwas gar nicht so eingeben kann haben die Daten am Schluss eine Qualität die brauchbar ist. Es wäre doch schade wenn wir in 2 Jahren bemerken, dass alle die Daten, welche mit viel Aufwand gesammelt wurden einfach unbrauchbar sind. Gruss Zapfen

Fäkalienabsaugung amenity=waste disposal+waste=excrement Müllcontainer amenity=waste disposal+waste=trash

waste=x waste=y waste=z Zu finden auf OSM für Segler und andere Seeleute. Den Link hab ich von einem gewissen Markus B. Viele Grüße und weiterhin viel Spaß beim endlos diskutieren Geomatika

Hallo Geomatika,

lach - ja, manchmal muss ich mir die Antworten halt selbst geben… Andere Frage: hast Du Beziehungen zum BSH? dann schick mir doch mal eine Mail… Gruss, Markus PS: hinter

tut sich m.E. ein weiteres Problem auf: ich fürchte, die Renderer können (noch) nicht mit multiplen Schlüssel-Wert-Paaren umgehen, bei denen der Schlüssel gleich ist…

Hallo, ich denke gerade auch über multiple Werte nach. Ich denke, soange keine bessere Alternative besteht, kann man analog zur Konvention des “ref”-Tags eine Wertliste (durch “;” getrennt) verwenden. Mir wurde aber mal geschrieben, dass diese Listen jedoch nicht vernünftig ausgewertet werden können. MfG Mark

Ich versuche mich immer noch in diesem chaotischen System von Schlüsseln zurechtzufinden. Sehr hilfreich ist mir dabei Howto Map A: die alphabetisch sortierte und mit Fotos illustrierte Liste der Schlüssel. Da suche ich nach “Bäcker” oder “Bahnhof” und finde wie ich den beschreiben kann. Und noch einfacher gehts in JOSM, da gibt es fertige Vorlagen, die ich nur anklicke und schon ist alles richtig. Was ich nicht verstehe sind die oft nichtssagende Hauptschlüssel, in denen ich keinen Mehrwert finde. Sie werden irgendwie als “Kategorie” missbraucht. Aber dafür sind doch die Relationen da… Wozu brauchen wir übergeordnete Schlüssel? Beispiel: “amenity” und “tourism”? Wäre es nicht sinnvoller, die Information als solche genauer zu spezifizieren? Wieso sagt man: amenity=Friedhof statt einfacher und aussagekräftiger: Friedhof=Westfriedhof ? Wieso sagt man: amenity=prison statt einfacher und aussagekräftiger: prison=Hochsicherheitstrakt ? Gruss, Markus

Nur ´ne kurze Anmerkung, ohne alles oben drüber gelesen zu haben: Eine Art von Kategorien ist meines Erachtens schon sinnvoll. Genaue Eigenschaften kann man dann über type oder name oder was auch immer hinzufügen. Zumindest nach jetzigem Stand wäre es ohne die Kategorien z.B. nicht möglich, sich zum Beispiel alle Friedhöfe einer Stadt runterzuladen. Zur Zeit gibst Du als Kriterium “amenity=grave_yard” oder “landuse=cemetery” an. Nach Deiner Nomenklatur hättest Du hier ein Problem. Dann müsste es heißen “tag=cemetery” oderso. Will damit nur sagen, dass da u.U. noch ein Rattenschwanz dranhängt.

Wahrscheinlich weil “Westfriedhof” oder “Hochsicherheitstrakt” in den “name” Schlüssel gehören. Den Name Schlüssel kann dann jeder Renderer Interpretieren und anzeigen. Würde der name nicht im “name”-Schlüssel gespeichert, würde er nur von Renderern angezeigt werden die den entsprechenden Schlüssel auch kennen. D.h. es wäre ein erheblicher Mehraufwand. Man könnte natürlich auch sagen prison=hochsicherheitstrakt + name=hochsicherheitstrakt, aber dann hätte man redundante Daten geschafft und die gilt es in einer Datenbank zu vermeiden, da redundante Daten potentielle Fehlerquellen sind. Anderer Grund ist, wieso man z.B. highway=construction + construction=residential und nicht highway=residential + state=construction schreiben soll, dass die renderer dann bei jeder einzelnen Straße immer noch nach dem “state”-schlüssel schauen müssten, was einiges an performace fressen würde. Den “highway”-schlüssel müssen sie sowieso auswerten, brauchen also nur für die straßen zusätzliche rechenzeit die ein “construction” im highway-schlüssel stehn haben. Könnte mir vorstellen, dass die restlichen Unterteilungen ähnliche Hintergründe haben. Es heisst zwar immer, wir mappen nicht für die renderer, aber das betrifft wohl nur das design, nicht den technischen Hintergrund der Schlüssel. Denn OSM würde sich selbst ins Fleisch schneiden, wenn es die Schlüssel nicht auch technisch vergeben würde um den renderern Arbeit ab zu nehmen, denn dann würde es so kompliziert und langsam werden, dass es bei Programmierern die einen Renderer programmieren wollten keinen großen Anklang finden würde. Und ohne die läuft halt nichts. Was nicht heisst, dass man die Sinnhaftigkeit einiger Unterteilungen nicht hinterfragen sollte, einiges ist sicher auch nur aus Unwissenheit oder aus der Geschichte heraus so gewachsen und bietet weder für die Renderer noch für die Mapper vorteile. Edit: Kreuzpost mit krza. Das ist natürlich auch ein gutes argument, das filtern würde wohl wesentlich schwerer fallen/komplizierter werden.