derzeit beschäftige ich mich mit einer 3D-Visualisierung von in OSM erfassten Gebäuden (ways mit tag “building” = “yes”).
Rundungen werden ja bei den ways immer als facettierte Umrisse abgebildet. Es besteht nun also immer die Möglichkeit das
1.) der Umriss in Wirklichkeit eine abgerundete Form hat. Die einzelnen Nodes sind hierbei Punkte auf der Umrisskurve.
2.) der Umriss auch in Wirklichkeit facettiert ist. Die Umrisslinie in OSM entspricht also (mehr oder weniger) der Realität.
Meine Frage:
Gibt es für Nodes einen Tag, um zu definieren, dass der Node den Fall 1. abbildet (Fall 2. ist ja Standard)?
bei Strassen ist der Standard in der Tat wohl eher: “Wirklich rund”
Bei Gebäudeumrissen dagegen genau das Gegenteil.
Vielleicht wäre es ein sinnvoller Feature Request für die jeweiligen Ausnahmesituationen einen entspr. Node Tag zu implementieren?
Bisher werden runde Gebäude jedenfalls in OSM (Mapnik+Osmarender) recht unschön als Vielecke gerendert.
Halte ich durchaus für sinnvoll. Auch wenn “wir natürlich nicht für den Renderer taggen”, können allgemeine Hinweise an die Renderer durchaus notwendig sein. Ich fände z.B.
render:smoothing=yes | no
gut und leicht verständlich. Als default könnte man unterscheiden, für Gebäude no, für Straßen yes, aber für Straßenkreuzungen und Abzweige wiederum no.
(In dieser Form mit “render:” deshalb, weil es möglicherweise auch andere Hinweise an Renderer geben könnte, die man im Einzelfall kommunizieren möchte. Konkret fiele mir dazu ein “render:show_name=no” z.B. für manche Flußabschnitte, die durch einen See verlaufen, oder ähnliche Spezialfälle.)
OSM arbeitet mit Vektoren, also Geraden zwischen zwei Punkten
Das lässt sich auf absehbare Zeit vermutlich nicht ändern.
Ein Knoten hat keine Ausdehnung, dort wäre ein Hinweis auf
runde Form eher falsch.
Wenn du angenähert runde Formen willst, verwende mehr Knoten.
Übrigens ist auch ein mit einem Zirkel gezeichneter Kreis nicht wirklich rund.
Sieh dir einfach das Ergebnis mit ener starken Lupe an.
Die Teilchen des Schreibmittels begrenzen die Genauigkeit genau so wie die
Auflösung des Bildschirms oder Druckers.
Was Sascha meint (wenn ich es richtig verstanden habe) ist nicht, daß der Knoten selbst rund ist. Stattdessen könnte ein Tag für den Knoten die Information speichern, daß sich an diesem Knoten nicht zwei Strecken in einem stumpfen Winkel treffen, sondern daß dieser Punkt in Wirklichkeit auf einer durchgehenden Kurve liegt. Insofern ist es m.E. richtig, die Information dem Knoten zuzuordnen.
Diese Information geht im Moment verloren / wird nicht erfaßt. Warum sollte man sie nicht speichern?
Was Sascha meint (wenn ich es richtig verstanden habe) ist nicht, daß der Knoten selbst rund ist. Stattdessen könnte ein Tag für den Knoten die Information speichern, daß sich an diesem Knoten nicht zwei Strecken in einem stumpfen Winkel treffen, sondern daß dieser Punkt in Wirklichkeit auf einer durchgehenden Kurve liegt. Insofern ist es m.E. richtig, die Information dem Knoten zuzuordnen. Diese Information geht im Moment verloren / wird nicht erfaßt. Warum sollte man sie nicht speichern?
Das bringt die Sache auf den Punkt
Die Informationen, dass der Punkt Teil eines Vielecks, bzw. Kurve ist, macht durchaus als punktbezogener Tag Sinn.
Eigentlich ist dies auch mehr als nur eine renderingbezogene Angabe, schließlich definiert man über den Tag letztendlich mit die Form des Gebäude (eben gekurvt oder eckig an diesem Punkt).
Bei Gebäude macht dies meiner Meinung nach richtig Sinn. So kommt man der wahren Gebäudeform mit einem zus. Tag schon sehr viel näher. (Ansonsten würde man vielleicht noch in OSM anfangen mit NURBS/Tangenten/etc. aus dem Vektorgrafikbereich)
Strassen lassen sich viel besser nach Mustern beim Rendern bearbeiten, da sie als funktionale Verkehrswege eigentlich immer bestimmten Regeln/Formen entsprechen. Gelegentlich verhält sich vielleicht mal ein Wendehammer, etc. nicht vorhersehbar, in solch Ausnahmefällen wäre dann so ein Eckig/Rund-Tag auch sinnvoll (aber nur dann).
Für meine 3D-App bastele ich übrigens als Workaround ein Regelwerk, dass den Linienverlauf analysiert und aus den Winkelabfolgen dann berechnet, ob es sich (wahrscheinlich) um eine Kurve oder ein Eck handelt. Ich werde das dann mal testen. Wenn die Trefferwahrscheinlichkeit hoch ist, könnte ich das Ergebnis auf Wunsch auch in Form der neuen Tags automatisch in OSM einspeisen. Problemfälle könnten dann nachträglich angepasst werden.
Jetzt verstehe ich, was gemeint war.
Die Information erhöht den Datenbestand, nur mal so als Gegenargument.
Es betrifft ja immer mehrere Punkte.
Dabei ist natürlich zu bedenken, dass Renderer ggfs. so zeichnen, dass zwei Wege
übereinander liegen, die das in Wirklichkeit nicht tun. Das wäre unschön.
Bei Straßen in EU und Nordamerika mag das noch passen, in anderen Ländern oder
bei Tracks/Pfaden wird das wird das schon schwieriger.
Ich sehe das eher als Werkzeug bei den Editoren.
Analog zu dem existierenden Kreis-Tool, nur halt für Teilstücke / Teilkreise.
Ggfs. kann man auch weitere Punkte hinzufügen, damit die Rundung
gleichmässiger wird.
Bei der Gelegenheit sollte man auch die Möglichkeit einbauen Ellipsen,
Parabeln, Ovale resp. Teilstücke davon zu erzeugen.
So bleibt es in der Hand des Mappers und nicht der Renderer,
was daraus wird.
Nicht unbedingt, runde/geschwungene Gebäudeumrisse sind immer in mehr oder weniger viele Segmente aufgeteilt. Gibt man den einzelnen Nodes die Info mit, dass sie Teil einer Kurve (Spline) sind, kann man den Umriss mit wesentlich weniger Segmentpunkten definieren. Im Endeffekt entstehen dann sogar weniger Daten als bei der Erstellung eines fein facettierten Geradenpolygonzuges mit vielen Nodes.
Splines sind mathematisch berechnete Kurven, eine Überlappung ist also exakt vorhersehbar und damit auch vermeidbar.
Das schöne an der Lösung wäre ja auch, dass die Sache “abwärtskompatibel” ist. Renderer, etc die den “Rund”-Tag nicht kennen bilden den zugehörigen way einfach als eckigen Polygonzug (wie bisher Standard) ab. Wird der Tag durch neuere Renderer erkannt, kann der Umriss wirklichkeitsnäher als Spline abgebildet werden.
Ja, das sehe ich auch so. Der Vorschlag war nur in dem Sinne gemeint, dass ich damit schon mal einen Anfangsbestand taggen würde.
