Multipolygonwahnsinn - oder: Durchblick war gestern!

Immer nach dem Motto:

Es gibt gibt manchmal schon Gründe für ein MP (geografisch getrennt, outer/inner, etc), aber wie obiges Beispiel zeigt eben auch nicht. Ich bin dafür, dass solche MPs umgebaut werden.

Ich glaube jedoch, die MP-Seuche liegt im Wiki begraben. Solange dort nicht expliziert gesagt wird, dass MPs nur dort verwendet werden sollen, wo es nicht mit einem einfachen Weg geht, werden immer wieder Mapper solche Konstrukte kreieren. Das müsste im Wiki geändert werden.

Und falls noch jemand mit dem Argument Datenreduktion durch Mehrfachverwendung der Wege kommt, der zeigt nur dass er keine Ahnung von Datenbanken hat. Jeder Datenrecord hat soviel Overhead, dass jede Mehrfachverwendung spielend durch die grössere Anzahl Datenrecords aufgehoben würde.

Dass abschreckend komplexe (wenn auch “spezifikationsgemässe”) Multipolygone das Detailmapping bestimmter Gebiete zuverlässig verhindern können, weil sie völlig unnötigerweise oder verfrüht eingeführt werden, oder manchmal auch mit dem Zweck, andere Mapper vom mappen abzuhalten (“das ist mein Revier”).

Dass Regionen auf Entwicklungsland-Niveau verharren weil es Mapper gibt die mit ihren Konstrukten die Arbeit anderer behindern, oder verhindern.

Du kannst das im Taunus übrigens sehr schön studieren. Je “brauner” die Landuse-Flächen (=komplexe Multipolygone) desto weniger topografische Details sind gemappt. Das Mapping sieht noch auf Zoomlevel 8 gut aus aber mehr nicht. Im Hochtaunus, wo ich zuhause bin, gibt es keine komplexen Polygonkonstrukte, und das Mapping sieht noch bei Level 13 gut aus. Und jeder kann weiterarbeiten und verbessern. Darum wird die Karte bei uns auch immer noch besser. Alle mappen gleich, keiner hat es nötig durch “individuellen Stil” auffallen. Ohne dass man sogar miteinander darüber redet. Sondern nur guckt: was ist denn da schon gemappt. Erstaunlich!

Die Spezifikation ist das Problem. Wie manche technikverliebte sie lesen und anwenden ist das Problem. Wie sie ihren Kram verteidigen. Dass manche meinen, nur “Spezialisten” die all den (widersprüchlichen, unvollständigen) Kram gelesen haben sollten mappen dürfen, ist das Problem. Dass dieser Elitarismus hier eine Plattform findet ist das Problem.

**Vor rund 200 Jahren **gab das erste Mal in der Geschichte Karten an denen **viele **mitarbeiteten. Nicht alle davon waren Ingenieurgeographen. Manche konnten gerade lesen, schreiben und die Grundrechenarten. Damit diese alle an einem Kartenwerk mitarbeiten konnten und das Ergebnis von guter Qualität war, brauchte es einfach anwendbare Kartierungsregeln. Es konnte nicht jeder mappen wie er grad lustig war. Es gab kein Forum wo jeder seine Meinung kundtat es am besten zu wissen. Wissen wir mehr als diese Leute damals? Können wir auf sie herabblicken? Können wir selber trigonometrische Messungen machen? Laufen wir vom Sonnenauf- bis Sonnenuntergang draußen rum und zeichnen? Und machen in der Nacht dann noch Korrekturen? Nein.

Davon sind wir hier meilenweit entfernt. Aber hier gibt es Leute, die sonst sehr vernünftige Sachen posten, und die sogar einfach “Fußweg” umdefinieren, wie sie grad lustig sind, weil sie meinen “Fußweg sei nur was für den Sonntagsspaziergang”. Steht zwar nirgendwo im WIKI aber macht ja nichts. Sowas macht einen wirklich fassungslos.

100 werden das lesen und denken “ach ja ich kann taggen wie ich will”. Die ach so gelobte “Freiheit” zu taggen was man will oder “wichtig” empfindet… hier gibt es Leute die selbst abstruseste Sachen wichtig finden. Solange ihr Arbeiten keinen Einfluss auf das anderer Leute hat, ist das tolerabel. Aber:

Es arbeiten Leute am Projekt mit, die lesen einen WIKI Artikel über Polygone und dann fällt ihnen was ein wie sie mappen können. Dass die Straßen eckig sind und Anschlüsse fehlen, die Waldgebiete ungenau, dass Wege, Bauernhöfe und sämtliche Bäche fehlen, dass noch keine Häuser eingezeichnet sind, dass Wohn- sich nicht von Gewerbe- u. Industiegebieten unterscheiden,… : all das fällt ihnen **nicht **auf. Jeder der OSM als eine KARTE benutzen würde, dem würde das eine oder andere davon auffallen. Nein, auf diesem primitiven Mappingniveau (Level 8) meinen sie aufgrund des Lesens des WIKI Artikels, dass es doch jetzt mal nett wäre alles was nicht schon grün oder grau ist (Wald oder Siedlung) der Abwechslung halber doch mal braun einzufärben… schlimmer: sie finden sogar eine pseudorationale Begründung für ihr Tun (“irgendwie Farmland”) und meinen sie hätten die Karte irgendwie weitergebracht!

Ich mach es aber künftig ganz einfach: Ich schmeisse jede Farmland Relation die beim Weitermappen behindert einfach raus, soweit ich irgendwo ein nettes kleines Wiesental sehe das als farmland gemappt ist.

Auf diese Art werde ich auch hinterher am wenigsten von Leuten wie Radeln oder Wambacher angemotzt dass “meine” Polygone (notwendigerweise komplexer und fehleranfälliger geworden als zuvor) in irgendwelchen MP-Überwachungstools Fehler oder Warnungen ausspucken. Denn wo es weniger von ihnen gibt, gibt es auch weniger Fehlermeldungen.

Gruss, T.

Ich habe es schon öfter bei anderen Themen gesagt: OSM kommt langsam in eine extrem kritische Phase. Die ganzen unendlichen Diskussionen der letzten Zeit zeigen eins: es gibt kaum noch einen Konsens zu irgendeinem Thema.

Die Art und Weise wie OSM sich bisher entwickelt hat ist einmalig für ein solches Projekt, und die Prinzipien und Regeln (bzw eher die Regel dass es im Grunde gar keine Regeln gibt) haben bisher eigentlich überraschend perfekt funktioniert.

Allerdings war das bisher noch weitgehend die Phase, wo im Grunde erstmal Gebiete überhaupt erfasst werden, dabei ging es um einfache, grundsätzliche Sachen. Solche einfachen Gegebenheiten erfordern nur einfache gemeinsame Grundregeln, auf die man sich leicht einigen konnte.

Diese Phase des Erfassens der grundlegenden Sachen ist nun in den meisten Gebieten (zumindest in Europa) weitgehend abgeschlossen und OSM kommt nun in eine andere Phase, wo alles sehr viel spezieller und damit auch komplizierter wird. Das gilt sowohl für die Mapper als auch für die Auswerter und Anwender der Daten. Auch kommen immer mehr ganz spezielle Anwendungen und Mapper hervor, denen es um ganz spezielle Dinge geht, die auch dementsprechend nur noch einen kleinen Kreis interessiert. Das Mapping dieser Sachen kommt dabei oft dem Mapping anderer Sachen in die Quere.

Ich behaupte mal, für diese neue Phase kann man einfach nicht mehr die gleichen Prinzipien und Vorgehensweisen wie bisher anwenden.

Ohne eindeutige Regeln wird es schwierig werden in Zukunft. Auch eine eindeutige Zielsetzung bräuchte OSM dringend. Manchmal habe ich das Gefühl, OSM soll eine nicht machbare universelle GEO Datenbank werden, wo jede noch so kleine Nieschen Interessensgruppe ihre Sachen eintragen will. Da natürlich spezielle Interessen und das Tagging dieser nicht immer mit dem Tagging anderer Interessensgruppen übereinstimmen, könnte OSM ohne klare Regel und Einschränkungen was alles gemapped werden soll, bald in einem großen Chaos enden, das kein Anfänger und kaum ein Anwender und Auswerter noch handeln kann.

Ich frage mich, was die Polygone mit der Darstellung und den Zoomlevel zu tun haben?

Ob das jetzt auf der Karte genau dargestellt wird, hängt vom Mapper ab und nicht von den MP´s!
Man kann auch eine Fläche ohne MP´s extrem ungenau darstellen und Flächen aus MP´s dargestellt sehr detailgetreu mappen, das eine hat mit dem anderen nichts zu tun.

Dass die Karte bei Euch immer besser wird, liegt wohl daran, dass Ihr einfach gute und fleißige Mapper im Bereich habt, aber auch das hat nach meiner Meinung nichts mit MP´s zu tun.

Denn wenn ich nun z.B. eine Waldgrenze verfeinere und genauer zeichne, dann muss ich das genauso bei einer einfachen Fläche machen wie bei der Grenze eines MP´s.

Und den sogenannten “individuellen Stil” kann ich auch wieder ohne MP´s umsetzen :smiley:

Moin alle,

letztlich eiern wir hier alle mit den Unzulänglichkeiten von OSM herum. Ich gebe die Hoffnung ja noch nicht auf dass wir irgendwann mal saubere Geometrien wie für GIS üblich verwenden können. Da muss mal ein sauberer Schnitt her und dagegen in die ODbL-Umstellung noch Pipifax. So lange müssen wir uns mit dem Murks irgendwie behelfen, schön wäre wenn Editoren den Murks in der OSM vom Anwender fernhielten, man also sauber arbeiten könnte mit Punkten, Linien und Polygonen. Wie das dann in der Datenbank gespeichert wird kann dem Anwender dann egal sein.

LG,

-moenk

Mahlzeit,

in der Mittagspause habe ich mir folgende Fragen gestellt:

Ich setze mich an den Schreibtisch und zeichne mit Lineal und Stiften einen Plan, z.B. von einem Haus oder von einer Wohnung.

Zuerst zeichne ich den Umriss vom Haus mit einer Linie. Dann kommen die Innenwände an die Reihe, wieder mit einer Linie. Und dieser Umriss vom Haus und die Innenwände ergeben nun für mich bereits den Teilumriss von einem Raum. Eine weitere Innenwand gezeichnet und schon erscheint der Hausgang in kompletten Umfang (etwas abgekürzt dargestellt :D)

Möglicherweise stellt eine Linie auch noch die Grenze für die verlegten Fliesen dar, da habe ich nun schon eine Linie und drei Grenzen durch diese, aber ich zeichne sie garantiert nicht 3 mal, das würde mit der Zeit einen ziemlich dicken und unsauberen Strich ergeben.

Dann ergibt eine Linie die Grenze für Aussenmauer, Küche, Fliesen und Küchenmöbel, sind wir schon bei vier Grenzen an einer Linie, nur einmal gezeichnet!

Ich zeichne keine Linie mehrmals! Und da können PlugIns oder ShortCuts das Ganze noch so einfach machen.

Wenn z.B. ein Bach direkt an der Grenze von einem Wald zu einer Wiese verläuft und dieser Bach nun auch noch Gemeinden, Landkreise, Bundesland und Länder trennt, dann hätten wir hier, Moment ich muss nachrechnen, 7 Linien übereinander gelagert, wo macht das noch Sinn, bzw. ist übersichtlich?

Ich werbe seit längerem dafür, Relationen nur dann einzusetzen, wenn ohne diese ein Objekt nicht sinnvoll abgebildet werden kann, und ansonsten möglichst drauf zu verzichten. Für mich sind das
a) Flächen mit Löchern (See mit Insel etc., Gebäude mit Innenhof)
b) Flächen, deren begrenzende Wege zu viele Knoten enthalten, um zu einen Weg zusammengefasst zu werden
c) auch Routen- und Grenz-Relationen haben m.E. eine gewisse Berechtigung im OSM-Kosmos, hier erscheint die Alternative “gestapelter Wege” wohl auch niemandem allzu attraktiv
d) (erst nicht daran gedacht) auch Abbiegebeschränkungen lassen sich wohl ohne Relationen schwer modellieren, und es mag da auch noch weiteres geben.

Ich lösche keine Sachen, die andere anders machen, aber ich korrigiere fehlerhafte Geometrien, wenn ich kann, oder ich ignoriere sie, wenn es zu frustrierend wird.

Und Konsens, naja, ist ja schon erfreulich, wenn es wenigstens manchmal einen gibt. Wirklich konsistente, sowohl inhaltlich fehlerfreie als auch formal einheitliche Daten und möglichst auch eine global einheitliche Detailtiefe kann ein Projekt wie OSM m.E. aufgrund seiner Struktur gar nicht haben.

Nachdem wir hier grade ein überwältigendes Votum zu mehr Mäßigkeit bei Multipolgonen haben und sich das Wiki nicht von selbst ändert, habe ich mal einen entsprechenden Hinweis ins Wiki aufgenommen, mit Link auf diese Diskussion.

Dabei ist mir aufgefallen, daß die Aussage Multipolygone sei DER empfohlene Standard-Flächentyp nur in der deutschen Version enthalten war.

bye
Nop

Finde ich gut.

Ich würde noch anregen, darauf hinzuweisen, dass sich Multipolygone oft vermeiden lassen, indem Flächen kleinteiliger eingetragen werden. Dass also beispielsweise nicht 50 Quadratkilometer mit einer einzigen, großen Acker- oder Wiesen-Fläche überdeckt werden, was wegen der unvermeidlichen Inseln ein Multipolygon zwingend macht. Stattdessen kann man kleinere Gebiete als simple Flächen eintragen, die auch durchaus direkt aneinander grenzen dürfen. Auch bei Wohngebieten und dergleichen lassen sich MPs auf diese Weise oft vermeiden.

Ich denke mal da liegt dann wohl auch das Hauptproblem. Mir ist nicht erst einmal aufgefallen das sich die unterschiedlichen Übersetzungen zum Teil recht deutlich unterscheiden. Deshalb lasse ich inzwischen die Übersetzungen vollkommen links liegen und nutze nur noch das englische Original.

Ansonsten finde ich die im ersten Post aufgeführten Multipolygon Relationen aber auch nicht so schwer als Mensch zu verstehen. Selbst ohne Software kann man da recht gut erkennen was der Mappe wollte. Für Software ist eine Multipolygon Relation in meinen Augen auch sehr gut aus wert bar.

Nun ja, dein Bauplan funktioniert aber nur, weil dein Gehirn die Arbeit übernimmt, aus den Linien die Zimmer zusammenzusetzen. In einer Datenbank, sei es für einen Gebäudeplan oder in OSM, musst du das schon exakt definieren.

Um deine Analogie also weiterzuspinnen: Du gibst jeder deiner einfach eingezeichneten Linien eine Nummer. Dann nimmst du ein zusätzliches Blatt zur Hand und erstellst dort Tabellen, auf denen verzeichnet ist, dass die Mauern 1, 4, 5 und 7 die Küche bilden usw. Auf dem eigentlichen Bauplan ist nicht eingezeichnet, zu welchen Zimmern eine Mauer gehört. Das erfährt der Maurer nur dadurch, dass er die Tabelle auf dem Beiblatt auswertet.

So viel simpler und logischer erscheint mir das nicht.

Solche Extremfälle kannst du natürlich konstruieren, und die sind tatsächlich unschön. Aber erstens: Wie oft kommen die tatsächlich vor? Zweitens sollen Relationen ja nicht verboten werden, es besteht doch sicherlich Einigkeit, dass sie für Gebilde wie Grenzen sinnvoll sind. Damit fallen schon einige deiner 7 Linien weg. Wenn dich das Überlagern mehrerer Linien stört (ich mag das auch nicht), kannst du drittens etwas Mikromapping betreiben und Wald- sowie Wiesengrenze von der Bachmitte trennen und an den Bachrand legen. Dann hast du drei getrennte Linien - was zugegebenermaßen andere Nachteile hat, aber du musst halt die Methode wählen, die dir am besten gefällt.

Dazu ein Denkanstoß, vielleicht stimmt er dich ja ein wenig milder: Linien sind in OSM eigentlich auch ein logisches Konstrukt, die Relationen gar nicht so unähnlich sind. Sie definieren sich nämlich dadurch, dass sie über Punkte laufen. Und wenn zwei Linien über dieselben Punkte laufen, ist das doch nicht so ein konzeptioneller Unterschied gegenüber zwei Relationen, die das dasselbe Linienstück verwenden.

Hallo Zusammen,

unnötig unübersichtlich und kompliziert werden Multipolygone für mich, wenn dafür vorhandene Wege und Flächen verhackstückt werden.
Da braucht einer für sein MP hier ein Stück Weg, dort einen Waldrand und da einen Teil eines Baches oder eines Ortsgebiets. Das Ergebnis
ist, dass durchgehende Wege zerteilt und bereits vorhandene Flächen ebenfalls zu MP gemacht werden müssen, um sie wieder
zusammenzufügen. Je detaillierter das Mapping, um so kleiner werden die einzelnen Teilstücke.

Grüße

Ich wohne in Kufstein und bin auch in diesem Bereich tätig. Hier sind folgende Grenzbereiche vorhanden:

Deutschland/Österreich
Bayern/Tirol
Landkreis Rosenheim/Bezirkshauptmannschaft Kufstein
Tirol/Salzburg
Kufstein/andere Bezirkshauptmannschaften

um nur ein paar zu nennen :smiley:

Du musst mich nicht milder stimmen, denn das meiste von dem was ich schreibe ist nur ziemlich direkt und manchmal etwas forsch formuliert, trifft aber das was ich meine :wink:

Das beim Menschen das Gehirn das Zusammensetzen übernimmt ist mir klar und das man das Zusammensetzen einem PC erst beibringen muss ist richtig. Nur funktioniert das bei OSM ja schon hervorragend. Warum also nicht verwenden?

Ich befürworte die Verwendung von MP´s, denn wie mein Chef immer sagt, ich denke gerne akstrakt.
Und das ist bei MP´s von großem Vorteil, denn nichts anderes wird durch sie erreicht, wir abstrahieren die Infos.

Strecken mit Wegen als Teile einzelner Multipolygone werden auch für Routingprogramme und Firmware immer schwerer zu berechnen, da die IDs der einzelnen Abschnitte häufiger wechseln. Das äußert sich dann bei langen Touren in zeitigeren Routenberechnungsabbrüchen - oder in unverstandenen Umwegen, weil längere Streckenabschnitte gleichbleibender ID und somit weniger IDs über die Gesamtstrecke besser beherrschbar sind.

Grüße
Mario

Das Teil war ja schon faul. Wenn ich da was falsch gemacht habe, hätte man mich (auch hier) darauf hinweisen können.
Andererseits kontrolliere ich Änderung, die auf dem OSMI beruhen meistens hinterher in demselben. War hier nicht mehr möglich.

BTW, Danke an die Putzfrau.

Ich denke das würde dann langsam den Rahmen der Seite sprengen, die eigentlich ja definieren sollte, was ein Multipoly ist. Da müßte man dann weiter ausholen und eine Art Best-Practice Seite aufmachen, für den detaillierten Umgang mit Flächen und den häufigsten Usecases.

Eigentlich sind die IMHO anzustrebenden Grundregeln sehr einfach:

  1. So einfach strukturieren wie möglich, immer an Mapper ohne technische Ausbildung denken
  2. Keine bestehenden Tags mißbrauchen/umdefinieren

Was großflächige Objekte angeht, halte ich persönlich den aktuellen Multipolygon-Relation-Ansatz auch technisch für ungeschickt. Er versucht halt als Kompromiß mit vorhandenen Mitteln etwas auszudrücken, wofür die vorhandenen Mittel nie vorgesehen waren.

Als technische Lösung könnte ich mir eher vorstellen

  • entweder ein echtes API-Objekt für solche Flächen, so daß man direkt damit arbeiten kann und nicht immer alle Relationen durchsuchen muß bevor man weiß ob ein Way allein gültig ist oder nur Einzelteil einer Multipoly-Relation. Einen entsprechenden Vorschlag hab ich schon lange auf der API0.7 Seite eingetragen.

  • eine additive Multipoly-Relation, die übersichtlicher und weniger empfindlich gegen Fehler ist. Die Idee wäre, ein Multipolygon aus vielen Einzelpolygonen zusammenzubauen, von denen aber jedes für sich ein geschlossenes, gültiges Teilgebiet beschreibt (anstatt aus einzelnen Linienstücken, die jedes für sich sinnlos sind). Mit der Relation könnte man ebenso das Gesamtobjekt konstruieren, indem man die gemeinsamen Kanten entfernt. Aber ohne die Relation oder ohne Verständnis der komplexen Gesamtlage würde jedes Einzelpolygon immer noch in jedem Editor sichtbar, in jeder Karte angezeigt und von jedem Mapper verstanden und editiert werden können.

  • Den Mechanismus für die Abbildung von Löchern halte ich für verständlich, solange die Löcher auch wieder einfache, geschlossene Polygone sind. In vielen Fällen wären die Löcher bei einem additiven Ansatz aber auch komplett überflüssig, da man ja die Loch-Gegend mit mehreren Polygonen umgeben kann, die per Relation zu einer Einheit definiert werden. Dann ist kein Ausstanzen mehr nötig.

bye
Nop

Dann denke mal zurück, was Du teilweise für einen Mist produziert hattest.
Du beschwerst Dich ab und an über nicht vorhandenes Detailmapping. Da frage ich mich, weshalb manche Flächen die Du angefaßt hast, laut Bing danach genau so ungenau waren wie davor.

Also ich probier es mal mit Handfesten Argumenten und weniger Emotionen.

Hier ist eine Gegend, in der ca 100km^2 mit je EINER farmland, meadow und forrest Relation abgedeckt sind: http://www.openstreetmap.org/browse/relation/1918945

Versuche dort in der Gegend mal irgend etwas zu machen, um ein Gespür dafür zu bekommen. Ich habe frustriert aufgegeben!

PRO MP:

  • Redundanzvermeidung. Jede Grenzlinie nur 1x zeichnen, statt sie nachziehen zu müssen (und dabei womöglich einzelne Nodes zu übersehen).

KONTRA MP:

  • Ein kleiner Fehler und die Zuordnung innen/aussen schlägt fehl. 100km^2 Wald, Wiesen oder Felder verschwinden.
  • JOSM (und alle anderen Tools) versagen bei der zuordnung von innen/aussen, wenn sich nicht die GANZEN Relationen heruntergeladen haben. Versuche mal die Relationen der obrigen Region vollständig heruterzuladen.
  • Wenn man eine Kleinigkeit an einer Relation ändert, muss der Renderer die gesamte Relation neu zeichnen. Im obrigen Beispiel sind das jeweils 100km^2.
  • Das herunterladen der Relation 1918945 bricht bei mir in JOSM häufig mit einem Timeout Fehler ab. (mit “Download object”)
  • Es wird immens viel Platz verbraucht, da bei jeder kleinen Änderung die komplette Relation neu gespeichert wird. Die Relation hat etwa 360 Versionen mit je 1500 Wegen.
  • Es treten Probleme beim Schneiden auf, wenn nicht alle Teilstücke der Relation enthalten sind. Dann fehlen z.B. plätzlich Wälder auf Garmin.
  • Unerfahrene Mapper bauen schnell Fehler ein, die mit viel Aufwand nachbearbeitet werden müssen.
  • Eine Verfeinerung von einmal mit MP gemappten Gebieten ist mühselig und fehleranfällig.
  • Selbst erfahre Mapper meiden solche Gegenen. Zumindestens ich tu mir so etwas nicht an - da gibt es genug anddere Gegenden, die die auch auf Bearbeitung warten.
  • Wege werden unnötig oft zerschnibbelt und müssen vor der Verwendung in Routern und Renderer erst wieder zusammengesetzt werden.

Das Argument “Speicherplatz” habe ich nicht zugeordnet, da die zusätzlichen Wege und Relationen die Einspaarung durch weniger Refferenzen vermutlich mehr als zunichte machen.

Hat noch jemand Argumente für diese Liste, so dass man danach eine sachliche Diskussion starten kann?

Ja, die deutsche Version sollte eine Übersetzung der englischen sein, mehr nicht. Verbesserungen bitte immer erst in die englische Version einbringen. Ausnahmen sind sprach- oder länderspezifische Eigenheiten, z.B. habe ich auf de:access ein paar Anmerkungen zu Mopeds/Motorfahrrädern gemacht, weil eine 1:1-Übersetzung irreführend wäre.

Gar nichts halte ich davon, Empfehlungen für oder gegen komplexe MP ins Wiki reinzuschreiben. Denn darüber herrscht kein Konsens. Vielmehr sollte reingeschrieben werden, dass (bzw. in welchen Fällen) das ein Streitthema ist, und was die Pros und Contras sind.

Nun, mein Vater war Architekt. Um ein Haus zu bauen brauchst du Pläne für den Maurer, den Zimmermann, Elktriker, Installateur etc. Jeder bekommt seinen eigenen individuellen Plan. In der Zeit vor CAD und Plotter wurden die Pläne also manuell mit durchpausen jeweils von Hand gezeichnet. Dabei enthielt jeder der Pläne allgemeine Dinge (z.B. Mauern) und wurde danach um spezifische Informationen ergänzt.

Nach deiner Logik müsste man aber die Umrisse der Mauern nicht noch mal zeichnen, denn der Elektriker kann sich diese Informationen ja aus dem Plan der Mauerer holen. Auch in OSM gibt es ja relativ unabhänige “Pläne” mit Grenzen, Landnutzung und Strassen.