Hilfe bei dem Baumkatalog

wambacher · 2011-04-17T09:05:15.000Z

marek kleciak:

zusammen mit dem User Kendzi arbeiten wir an einem 3D PlugIn für JOSM. Dort haben wir die Möglichkeit vorgesehen Bäume 3D zu zeichnen.

hi,
wie soll das den aussehen?
gruss
Walter

aighes · 2011-04-17T09:22:20.000Z

Ich könnte mir eher sowas vorstellen, dass man für jede Baumart Vorschläge bekommt, wie sie in 3D aussehen könnten und der Mapper dann eine Variante auswählt. Das Plugin müsste diese Auswahl dann in Tags pressen. Bspw. schlanke Pappel oder wie auch immer man einen Baum charakterisiert. Wichtig ist, dass in der OSM-Datenbank die Information neutral verpackt sein muss, sodass jeder die Angabe nutzen kann und auch nachvollziehen kann, wenn er die Tags liest.

marek_kleciak · 2011-04-17T15:58:03.000Z

wie soll das den aussehen?

Wir dachten an eine Bibliothek der 3D Formen, wobei wir einer Gattung eine Form sowie dazu gehörende Textur zuweisen.
Die Grundform wäre durch Parameter beschrieben:

Breite Stamm
Höhe Stamm
Breite Baumkrone
Höhe Baumkrone

Eventuell auch Neigung (nicht alle Bäume wachsen gerade)

Ich habe 2002 einen solchen Versuch bereits gemacht: mit einem Testdatensatz von der Stadt Hamburg.
Es sah sehr gut aus.

_i · 2011-04-17T16:16:43.000Z

Geht das denn auch ein wenig in die prozedurale Richtung? So hier vielleicht: http://ngplant.sourceforge.net
Kann man deine Ergebnisse irgendwo anschauen Marek?

marek_kleciak · 2011-04-17T17:22:43.000Z

Ich bin mir nicht sicher, ob der prozedurale Ansatz für diese Zwecke notwendig ist.
Die Echtzeitdarstellung ist dann sehr rechenintensiv. Wir dachten eher an low poly Modelle für Echtzeitdarstellung.
Irgendwann ist der prozedurale Ansatz mit Sicherbheit interessant.
Dann sollten wir aber über Level of Detail Konzept sprechen.

Wenn entsprechende Wiki Seite steht, lade ich dort Bilder hoch.

Fabi2 · 2011-04-18T20:16:23.000Z

marek kleciak:

Wir dachten an eine Bibliothek der 3D Formen, wobei wir einer Gattung eine Form sowie dazu gehörende Textur zuweisen.

Ich würde es wundern, wenn sich die üblichen Wuchsformen nicht in irgend einem spezialisiertem Baumbestimmungsbuch auftreiben lassen. Im Normalfall benutzt man aber in der Regel Blätter, Blüte und Sproßachsensymetrien, nicht die Erscheinung als Ganzes, sollte man aber man versuchen was dazu zu finden. Dann kann man da vordefinierte oder eigen Texturen drauf packen.

marek kleciak:

Die Grundform wäre durch Parameter beschrieben:

Breite Stamm
Höhe Stamm
Breite Baumkrone
Höhe Baumkrone

Eventuell auch Neigung (nicht alle Bäume wachsen gerade)

Und was wenn die Krone kegelförmig ist, wie bei freistehenden Nadelbäumen?

fkv · 2011-04-18T21:11:27.000Z

marek kleciak:

Wir dachten an eine Bibliothek der 3D Formen, wobei wir einer Gattung eine Form sowie dazu gehörende Textur zuweisen.

So funktioniert das nicht. Gattung und Form sind verschiedene taxonomische Ebenen. Eine Gattung (genus) kann mehrere Arten (species) umfassen. Eine Art kann mehrere Unterarten (subspecies) umfassen. Und zu jeder Unterart kann es verschiedene Formen (forma) geben.

Z.B. ist die Pyramidenpappel nur eine Form der Schwarzpappel (Populus nigra), sieht aber ganz anders aus als normale Schwarzpappeln.

Die Grundform wäre durch Parameter beschrieben:

Breite Stamm

Hängt primär vom Alter ab.

Höhe Stamm
Breite Baumkrone
Höhe Baumkrone

Das alles hängt ab vom Genotyp, vom Alter, vom Standort (Boden, Klima, Licht, Wind), vom Schnitt und davon, ob der Baum frei steht. Freistehende Bäume haben breitere Kronen.

Eventuell auch Neigung (nicht alle Bäume wachsen gerade)

Wenn ein Baum schief wächst, dann als Folge von Bodenfließen (Säbelwuchs) oder Verletzungen.

Ich habe 2002 einen solchen Versuch bereits gemacht: mit einem Testdatensatz von der Stadt Hamburg.
Es sah sehr gut aus.

Das glaube ich dir gerne. Aber was gut aussieht, hat leider selten was mit der Realität zu tun.

Ich finde, die Unterscheidung nach type=* ist für die grafische Darstellung ausreichend. Eine Unterscheidung nach Arten ist nur kompliziert und bringt nichts.

wambacher · 2011-04-18T21:41:11.000Z

Ich hab immer noch erheblich Schwierigkeiten mir vorzustellen, was ich damit in Josm anfangen soll.
Josm ist für mich ein Editor, mit dem ich so ziemlich alles anstellen kann, was ich beim Erfassen der OSM-Daten brauche. Mehr nicht.

Soll ich etwa den Baum “beschreiben”, bekomme dann ein generiertes 3D-Bildchen mit passenden Tags???
Eher erfasse ich HKTS.

na ja, warten wir mal aufs wiki, denn “ein Bild sagt mehr als 1000 Worte”

oder ich sehen den Wald vor lauter Bäumen nicht

Gruss
Walter

marek_kleciak · 2011-04-19T05:39:47.000Z

Hallo fkv,
ich bin kein Biologe, daher unpräzise Formulierung. Selbstverständlich findet die Zuordnung der Geometrie auf der untersten Ebene statt, was die Sache so aufwendig macht.
Was die Realität und deren Darstellung in Form von 2D oder 3D angeht, so haben wir immer mit einer Abstraktionsstufe zu tun. Man redet daher von dem Wiedererkennungswert.

Und da es verschiedene Karten für verschiedene Zwecke gibt, bedient man sich des Konzeptes “level of detail” (LOD)den ich in den 90-er eingeführt habe. Grob gesagt, LOD 1 in 3D sind nur Gebäudeformen als Blöcke und Geländemodell in Grobauflösung (250m Raster) LOD 5 sind alle architektonische Feinheiten, perfektes Geländemodell (mit der Höhe der Bordsteinkante z.B.)

Der beschriebene Ansatz für Bäume soll für LOD 2 bis 4 funktionieren. Selbstverständlich kann man davon nicht erwarten, dass es naturgetreu die 3D Realität abbildet. Es steigert jedoch den Wiedererkennungswert der Umgebung.

Hallo wambacher:
klar, in dem JOSM kannst Du die Bäume nur erfassen. In einem 3D Viewer an dem wir arbeiten, wird man die Bäume sehen können.

wambacher · 2011-04-19T08:16:35.000Z

marek kleciak:

klar, in dem JOSM kannst Du die Bäume nur erfassen. In einem 3D Viewer an dem wir arbeiten, wird man die Bäume sehen können.

Aha, jetzt macht die Sache schon etwas mehr Sinn.

Aber dann schreib sowas doch einfach in den Start-Post rein.

Gruss
Walter

marek_kleciak · 2011-04-19T08:29:51.000Z

Hast Recht Walter,

momentan kämpfe ich leider an einem Ersatzrechner mit dem GAU: Hauptplatine tot, Festplatte hoffentlich zu retten, bitte also um ein Wenig Geduld. Melde mich mit einer Info hier, wenn´s soweit ist.

TobWen · 2011-04-19T18:45:32.000Z

Vor 10 Minuten bestellt, da ich jetzt Botanik büffeln muss:
http://www.amazon.de/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=9783494014685

marek_kleciak · 2011-04-20T05:59:26.000Z

Hi TobWen, herzlichen Dank. Da lese ich aber in einer Beschreibung:

Hatte mir dieses Buch für meinen Botanischen Bestimmungskurs an der Uni bestellt. Alsdort mein Tutor erfahren hat, dass ich das getan habe, meinte er ich sollte es solange es noch geht zurückschicken.
Und wie ich im Verlauf der Bestimmungsübungen erfuhr, hatte er recht behalten…

marek_kleciak · 2011-04-28T09:25:12.000Z

Ich habe die erste Arbeitsversion der Baumbeschreibung ins Wiki gestellt:

http://wiki.openstreetmap.org/wiki/Tree_table

Dank !i! weiß ich von der Seite:
http://www.gardenology.org/wiki/Main_Page von dort kann man Inhalte rausholen um die Tabelle zu ergänzen.

PHerison · 2011-04-28T12:43:26.000Z

Ohne mich jetzt näher in das Thema eingelesen zu haben: Dein im Wiki beschriebener Tag “name” kollidiert nicht mit dem normalen Name-Tag (z.B. “Förster Justus Eiche”?

Fabi2 · 2011-04-28T15:49:31.000Z

http://wiki.openstreetmap.org/wiki/Tag:natural=tree ist dir aber hoffentlich schon bekannt? Nur weil du diverse bereits existierende Tags offenbar noch mal neu erfinden möchtest.

hurdygurdyman · 2011-04-29T04:03:34.000Z

PHerison:

Ohne mich jetzt näher in das Thema eingelesen zu haben: Dein im Wiki beschriebener Tag “name” kollidiert nicht mit dem normalen Name-Tag (z.B. “Förster Justus Eiche”?

+1
“name” wäre irreführend und kollidiert. Nimm doch “species=*”

marek_kleciak · 2011-04-29T05:46:36.000Z

Danke für alle Hinweise,
natürlich kenne ich http://wiki.openstreetmap.org/wiki/Tag:natural=tree
Eigentlich gehören Inhalte die Ich vorschlage hinein.
Ich schlage eben den Ausbau der dort vorhandener Struktur aus Sicht der 3D Visualisierung vor.
Tags die dort auftreten, erlauben eine realitätsnahe 3D Darstellung nicht. Selbst geschätzter Durchmesser Krone fehlt.
Aus meiner Erfahrung weiß ich auch, dass es schlauer ist getrennt die Höhen für Stamm und Krone zu nehmen statt der Gesamthöhe wie dort vorgeschlagen wird.
Ergebnisse sehen nach der 3D Berechnung eben besser aus.

Über die Namensgebung für die Tags sollten wir diskutieren: ich bin mir selbst unsicher, wie man das am schlausten lösen kann.

Der Kern des Vorschlages ist die Zuweisung eines Geometrietypes für jeden Baum.
Weitere Beispiele auf der Seite werden folgen.

Tordanik · 2011-04-29T08:06:29.000Z

marek kleciak:

Aus meiner Erfahrung weiß ich auch, dass es schlauer ist getrennt die Höhen für Stamm und Krone zu nehmen statt der Gesamthöhe wie dort vorgeschlagen wird.

Wenn ich bisher Bäume eingetragen habe, dann war die Gesamthöhe (als height=*) das erste, was ich erfasst habe. Dazu könnte ich mir noch vorstellen, die Höhe der “Kronen-Unterkante” (auf eurer Seite height_trunk) einzutragen.

Wieso ich statt der Gesamthöhe die Differenz aus Gesamthöhe und height_trunk taggen sollte, erschließt sich mir derzeit nicht. Es handelt sich letztlich um die gleiche Information, aber die Verwendung von height scheint mir sinnvoller: Erstens, da es sich um ein universell verwendbares Tag handelt, das auch eine nicht auf Bäume spezialisierte Anwendung kennen wird, und zweitens, da die Gesamthöhe diejenige Information ist, die ich mit höherer Wahrscheinlichkeit direkt messen würde.

Aber vielleicht kannst du deine Gründe für den Tagging-Vorschlag noch etwas ausführen?

marek_kleciak · 2011-04-29T08:26:27.000Z

Hallo Tordanik:
Dein Vorschlag klingt sinnvoll.
Ich habe es eingebaut.

Der Einzige Grund war die Denkweise eines Programmierers.
Aus der Sicht eines Erfassers ist es natürlich einfacher, die Gesamthöhe des Baumes und die Höhe des Stammes zu erfassen.