Die Idee ist verlockend, aber da gibt es gleich mehrer Probleme. Das erste ist das Urheberecht. Also es ist ebenfalls wie bei Garmin schwierig an die Daten zu kommen.
Das zweite ist, das dieses Programm von Google entwickelt wird. Also wenn wir Dinge gerne anders hätten, als sie Google meint machen zu müssen, dann geht das nicht mit diesem Programm.
Ob die Nutzer dieses Programmes nachher an ihren Objekten die gleichen Rechte haben und diese auch bei uns zurverfügung stellen dürfen ist fraglich. Auf jeden Fall muss man aber schonmal bei Google registriert sein und dann ist die Frage ob man auf zwei Hochzeiten tanzen möchte/kann.
Naja als “dummen” Editor wird es gehen. Problem aber wie du schon sagst die Lizenz:
-Erlaubt die EULA überhaupt CC BY SA/ODBL/Public Domain Resultate?
-Wie unterbindet man, dass Leute aus GMaps tracen und das dann einstellen?
Aber hey bis dahin müssen wir erstmal kommen 
Hallo Edwin,
auf den ersten Blick erscheint diese Idee verlockend: Modeller wäre vorhanden, und sehr viel ließe sich sicherlich in die Taggingschemata der OSM übersetzen. Die Frage ist aber, was wir wollen. Unser Editor bleibt unser, das Geschehen wird von der Community bestimmt.
Stellt einmal eine Firma fest, dass sie Geschäftsbedingungen ändert, haben wir ein ziemliches Problem…
s Ketchup ist recht gut für einfache Modelle, trotzdem ist die Herstellung von dem eigenem Modeller - wenn man genau weiß was man will - keine unmögliche Sache.
So wie ich Google und deren Anwälte einschätze, hätten wir mit s Ketchup früher oder später ein Problem am Hals.
wenn ich das richtig sehe, sind da exporte in diverse Dateiformate möglich… also warum nicht? Als Dankeschön kann man das Hausmodell auch für Google Earth hochladen.
Wie gesagt, in der Pipeline. Probleme kennst du ja jetzt.
Hi Edwin,
-
Exportfilter zu schreiben ist kein Problem - hat man ein gängiges Format, gehen alle anderen über Konverter in 3D ja auch.
-
s Ketchup ( entschuldige die Schreibweise, ich kenne SketchUp noch als Produkt einer kleinen, tapferen Firma die ein gutes Produkt entwickelt hat, bevor sie von Google gekauft worden ist, und anschliessend viele Entwickler auf die Straße gesetzt wurden…) liefert lediglich einen dreidimensionalen “Gipsabguß” dessen, was modelliert wird. Von Objektorientierung, wie wir´s bei OSM praktizieren ist dort keine Spur.
Es ist auch ein Problem für Google: Sie haben nur eine dreidimensionale Darstellung von dem Sichtbaren, keine Objekte dahinter. Man kann mit s Ketchup zwar nett Modelle machen, diese sind aber aus unserer Sicht alle für die Mülltonne. Wir künnen und sollten mehr wagen und schaffen.
Für Google kann Sketchup ausreichend sein, denn sie können nur automatisiert arbeiten und nur eine gewisse Detailtiefe erreichen. Für mich ist Google in diesem Bereich ein sterbender Patient, es ist nur die Frage der Zeit, wann es vorbei ist. Ich weiß natürlich dass diese These bei vielen als zu gewagt gesehen wird. Wir sollten mal in ca. 8 Jahren nochmal darüber sprechen.
Ich habe meinen schwierigen Job nur deswegen, weil ich bisher im Geodatengeschäft immer richtig lag.
Also rate ich von Google ab: Selbst mache, besser mache auch wenn´s länger dauert und ungleich schwieriger auf den ersten Blick erscheint.
Hmm, also das sehe ich definitiv anders! Na klar sind das nur “dumme” Modelle, ohne Speicherung der Topologie und Semantik. Aber trotzdem ist SketchUp weit verbreitet, um recht einfach 3D-Modelle zu erstellen
und es sollte für die Community möglich sein, damit Modelle von Landmarks zu erstellen und diese mit OSM zu verlinken.
Ich finde wir sollten uns nicht zu sehr auf die parametrisierte Lösung versteifen. Wenn ich jetzt hier raus auf die Straße gehe, sind mindestens 50% der Gebäude die ich auf Anhieb sehe unmöglich tag-basiert modellierbar (außer natürlich bis zu einem gewissen Generalisierungsgrad). Gerade für komplexe Bauwerke ist eine tag-basierte Modellierung unmöglich und/oder viel zu komplex, sodass die Mapper da m.E. gerne “dumme” aber dafür schöne, aussagekräftige 3D-Modelle erstellen und hochladen können sollten. Wir müssen einen breiten Fächer an Möglichkeiten anbieten und nichts von Vornherein ausschließen.
Aber genau sowas können wir dann perfekt im März diskutieren. 
Sehe ich recht ähnlich Matze. Es gibt bedarf an beiden Ansätzen, beide haben ihre Vor und Nachteile und es wird sicherlich für beides Communities in und um OSM herum geben. Aber am besten die Diskussion für den März aufsparen
Ja, bitte einsparen auf März. OSM4D sieht eben 2 Arten der Bauwerke vor:
- Generalisiert für alles, was sich generalisieren läßt
- Für “mindestens 50% der Gebäude die ich auf Anhieb unmöglich tag-basiert modellierbar” sollen nicht ““dumme” aber dafür schöne”, sondern oberflächen modelliert mithilfe von Tags wie “Wall, Roof, Ceiling…etc”.
Grob gesagt kann man die nr 2 als eien Erweiterung von dem Konzept der Industry Foundation Classes betrachten und mit dieser kompatibel. Die Modelle werden also nicht “dumm”. Das volumetrische Modellieren in 3D mithilfe z.B. der Wände die eine Stärke haben, eröffnet uns eher neue Möglichkeiten. Um das vielleicht an einem Beispiel zu veranschaulichen.
Dieses Modell:
http://webscape.com/AIAawards2002/gallery/entries/094img/094_BerlinerDomBackgrd_06.jpg bzw.
http://webscape.com/AIAawards2002/gallery/entries/094web/content.html und weitere haben meine Mitarbeiter eben mit Werkzeugen modelliert welche die architektonischen Bauteile als Volumenkörper siehen. Reine Oberflächenmodelle wie die von Sketchup sind spätestens dann unbrauchbar, wenn man mit indoor navigation beginnt.
Die Details und gesamte Problematik ausfürlich in Foren zu beschreiben ist eine Herausforderung und wäre auch schnell unübersichtlich. Daher wie !i! schrieb:
Bitte an alle Interessierte die Topics incl Detailfragen aufzuschreiben und vielleicht auf eine wiki Seite legen, damit wir eine sortierte Übersicht haben und ein Programm vernünftig planen können.
Viele Grüße,
Marek
Wenn wir genügend Stichpunkte zusammen haben, teilen wir das mal auf Personen auf und legen Unterseiten an. Hatte sich damals auf dem OSM Koordinierungstreffen echt bewehrt. Aber bei der vielzahl der Themen brauchen wir locker 2 Tage
Das denke ich mittlerweile auch. ein Tag für generelle Themen, ein Tag für Taggingschemata…
Ich denke nicht, dass man dumme Modelle nehmen sollte, wenn es gute Gründe für weniger dumme gibt. Was man machen sollte ist die dummen Modelle in jene umwandeln welche den Ansprüchen genügen. Ob das nun ein Converter macht oder der Editor sich gleich so bedienen läßt ist eigentlich nur eine Abwägungsfrage. Beide haben Vor- und Nachteile.
Ich mag das ungern abwürgen, aber am besten schauen wir auch einfach mal, was wir haben:
http://wiki.openstreetmap.org/wiki/3D_Development/Tagging#Usage_tools
Bitte schreibt eure Ideen unbedingt auf, aber nicht hier, da man da immer gleich versucht ist auch darauf zu antworten Ich persönlich werde nun immer mit Kamera durch die Gegend ziehen und mal Sachen fotografieren, wo ich nicht wüßte wie man das modelliert.
Letzten Endes müssen wir es ja alles Schritt für Schritt machen, denke da sollten wir uns auch zu ein wenig Pragmatik zwingen, denn jeder hat ja bestimmt leicht andere Vorstellungen von einem “perfekten” Tagging 
Ekhm, bei OSM kann wohl niemand Etwas abwürgen :)…
Ein tabellarischer Vergleich ist gut und richtig, auch wenn´s unnötig den Eindruck eines Rankings verschiedener Softwarepakete erzeugt, wo wir eher eine Synthese brauchen. OSM-4D ist auf der Seite in der Tat falsch platziert, denn es ist als ein Konzept zu verstehen, bei dem Taggingsyntax austauschbar ist. Der Modeller der in Lodz entwickelt wird, hat noch keinen Namen, wird aber fast alle in der Tabelle erwähnten Funktionen unterstützen, sowie die, die auf OSM4D Seite angedeutet sind.
Ah ok, dann ändere ich das in der Tabelle.
Und nein uns geht es nicht darum, wer die meisten Featuers unterstützt