Was stimmt? Für das Flachland z.B. Uferregion des Bodensee ist alles gut deckungsgleich, aber wenn es etwas Hügelig wird, passt überhaupt nichts mehr.
Die Abweichung beim LVA Bayern und Geoimage.at betragen runde 1-2 m… die zu Bing 6-8m
Und der GPS Track? Der passt PI mal Daumen zu allen drei.
6-8 Meter sind immernoch halbwegs genau, verglichen mit der Genauigkeit von GPS-Empfängern. Also such dir eins aus und nimm das, was dir am besten gefällt 
Oder wie bei GPS-Tracks machen und mitteln.
ich hab mal versucht, das auch für mich klarer darzustellen:
in groß: http://250kb.de/u/101204/p/JmVWhyFlvyKO.png
das ist zumindest aus meiner sicht die erklärung.
walter
Hallo Walter
Eine sehr anschauliche Darstellung der Problematik.
Wenn man weiter denkt, kann man auch erkennen, warum höhere Gebäude ebenfalls korrigiert werden müssen.
Edbeert (EvanE)
@Walter,
dem schliieße ich mich an. Danke.
@Edwin,
da würde das “Trimble” jetzt Licht in Dunkel bringen. 
Aber bei Gebäuden zeichnet man doch sowieso den Grundriss nach, nicht den Dachumriss (eben weil kaum ein Bild direkt von oben fotografiert ist). Dann sollte es doch stimmen.
Der Grundriss ist bei Gebäuden fast nie mit dem Dachumriss identisch, der Dachunmriss ist meistens grösser und vereinfacht. Das sieht man gut wenn man Katasterpläne und genau lotrechte Luftbilder überlagert.
Richtig, man sollte soweit möglich den Grundriss erfassen.
Leider kann man den fasst nie auf einem Luftbild sehen.
(Ausnahme Flachdach ohne Überstand und Aufnahme genau senkrecht.)
Wambachers Grafik zeigt unter anderem, warum das im Luftbild, in dem man vor allem das Dach gut sehen kann, so ist und wie man das korrigieren kann. Sieh dir mal als Beispiel die Kreuzbauten in Bonn an. Am einfachsten geht das mit Potlatch 2, da man dort zwischen Yahoo, womit die Gebäude erfasst wurden und Bing umschalten kann. Man kann es aber bei jedem anderen Hochhaus (ausser es ist zufällig genau senkrecht fotografiert) erkennen.
Edbert (EvanE)
Meiner Meinung nach kann man das mit OSM-Mitteln am besten dadurch darstellen dass man landuse und building kombiniert: landuse=residential für das grössere Dach und building=yes für den Grundriss.
Das ist nun - ääähhh - etwas daneben.
landuse=residential ist für besiedelte Gebiete gedacht.
Also mindesten inklusive des Grundstückes, auf dem das Gebäude steht, einzutragen.
Edbert (EvanE)
Es stört sich kein mir bekannter Renderer oder Auswertung daran wenn landuse-flächen übereinander liegen.
OMM…
Was hat diese Aussage damit zu tun, dass landuse=irgendwas unsinnig für ein Dach ist?
Und um das OMM… von wambacher zu erkären:
*** Wir mappen nicht für Renderer ***
Edbert (EvanE)
Ganz genau. Aber um das mal noch etwas zu erläutern: Wir mappen so, dass die gesetzten Tags mit den in der Community vereinbarten Bedeutungen übereinstimmen. Ein landuse=residential ist also kein Dach oder ein einzelnes Grundstück, sondern ein Wohngebiet. Der Renderer macht dann aus der Information, dass es ein Wohngebiet ist, die Fläche mit der entsprechenden Farbe.
Wenn man nun landuse=residential für etwas anderes benutzt (also z.B. das Dach), dann mag das mit einem Renderer oder Kartenstil vielleicht gut aussehen. Mit einem anderen werden vielleicht überhaupt keine Wohngebiete angezeigt und schwups sind auch die Dächer weg.
Damit Programme, welche die Daten irgendwie verarbeiten und nutzen wissen, was sie da vor sich haben, muss man sich eben auf bestimmte Tags für bestimmte Objekte festlegen. Das gilt auch für andere Mapping-Techniken, wie übereinandergelegte Flächen oder gemeinsam genutzte Nodes. Es muss sichergestellt werden, dass es nicht nur “zufällig” gut aussieht (was sich dementsprechend schnell ändern kann), sondern vom Renderer bewusst so dargestellt werden kann, wie es für das jeweilige Objekt vorgesehen ist.
Gruß
Vor allem würde so ein falsches Benutzen eines Tags, zu extremen Performanceproblemen bei Vektorkarten führen…
landuse=residential ist ein Tag für zumindest halbwegs großflächige Gegenden. Es gibt ja noch landuse=farm für ein paar einzelne Häuser…
Naja, im Allgemeinen machen wir uns keine Gedanken über Performance. Dass sie mit unseren Datenmengen zurechtkommen, ist die Sache der Programme, nicht unsere. Du hast aber insofern Recht, als dass das hauptsächlich dadurch geschieht, dass eben in niedrigen Zoomstufen nur Elemente ausgewertet werden, deren Tags auf eine große Ausdehnung (highway=motorway, landuse, etc.) und es deshalb zu Problemen kommen könnte, wenn man sie fälschlich für Dinge mit sehr kleiner Ausdehnung einsetzt. Trotzdem: Tags nicht für Dinge verwenden, für die sie nicht gedacht sind.
Die Renderer stören sich nicht, nein. Aber Du Dich vielleicht, wenn die Stapelreihefolge nicht der Render-Reihenfolge entspricht. Und tut sie es trotzdem, rendert der nächste Renderer vielleicht mit einer anderen Reihenfolge. Das ist eher ein Glücksspiel
Wenn ich allerdings einfach ein Tagging für Dächer einführe ist der Aufstand noch viel grösser. Ich habe mir bei OSM angewöhnt meine Daten so in der Datenbank unterzubringen dass sie niemand anderen stören. Das diese Landuse-Flächen vom Renderer nicht dargestellt werden ist dabei Sinn der Sache.
Beispiel Auswertung Landnutzung/versiegelte Fläche: Ein Dach versiegelt nicht aber benutzt das Land für Residentials.
Es stoert am wenihgsten, wenn fuer eine Sache, die bisher nicht erfasst wurde, ein neues Tag erfunden wird. Denn alle unbekannten Tags werden prinzipiell ignoriert => alles bleibt beim alten.
Wo sich andere Mapper immer (zu Recht?) aufregen, ist, wenn fuer ein bereits ueblicherweise erfasstes Objekt ein komplett neues, inkompatibles Tag erfunden wird (meist um eine Untermenge besonders zu betonen). Das bringt dann naemlich die bestehenden Auswertungen durcheinander, weil das Schema dann nicht mehr passt.
Ich hoffe, dir faellt noch ein besseres Beispiel ein. Obige Aussage ist eine bemerkenswerte Kombination von Widerspruechlichkeit (selbstverstaendlich versiegelt auch eine Ueberdachung und ein Dach muss nicht zu einem Wohngebaeude gehoeren) und Beliebigkeit (es gibt noch Tausende anderer “Nutzung” für residentials, die keine Daecher sind).
Gruss
Torsten
Wegen dieser Beliebigkeit kann ich für diese Auswertung das auswerten was ich möchte ohne mit neuen Tags andere mapper zu verwirren.
