OSM go - and stop - what next / was nun?

(Deutscher Text unten)

The development of OSMgo is on hold, may be forever. It was not intended to go that far anyway. I will do small changes now or then. And “support”: If anyone tells me new bugs or a missing feature, I most probably will get active. If you like to use OSMgo with a liddle help, I would be glad to guide you in multiuser mode. My friend Martin is coding a plane control/simulation. Soon you may fly through the virtual 3D world of OSM with/as a model plane. When the intended 3D model server/repository is online, it will be used by OSMgo to.

My whole code is a first shot style, really no clean code and not well structured. It has to be redone from the scratch. And in a way it will. But not by me. There is a project slightly relaying on my work. And I will contribute a bit. In that project, the dead ends of OSMgo may be solved, mostly by analysing the solutions of existing code. Mainly OSM2WORD because it is open source and OSMBuildings with an open source client at last. Are there other good sources? Unfortunely the really good solutions are in commercial products like F4. But they will not support a community project, will they? I would like, not only to have correct and complete code, but also a public description of the functions and algorithms. Yes, in the OSM wiki are pages about multipolygons and more. There are other disasters of complexity in OSMgo: rendering roof types and even roof directions, replacing buildings by building parts. The recursive OSM relations are hell. On the other hand, most of this problems are already solved by the 2D renders. And they are open source!

There are some ugly errors I will not fix. Like my roof typ gabled or the flickering land uses. Some buildings holes or holes in landuses are missing because of an error in ThreeJS. That may be gone in the next version. The frame rate is mostly a mess, mainly because I use ThreeJS. The new project uses Cesium now and so, it will also be limited. But Cesium may partly replace it with “native” code later. A lot of functiionality, like the analysis of OSM tags should not be done by the client but an tile server, a vector tile server of course. There are quite a view such servers already, most of them are commercial. I would be happy, if the OSM community would set up its own independent server and code.

Creating the Houses of Parliament in London etc. in details with building:parts is artwork of it’s own kind. I am always impressed what some OSM user have done. I started the page "https://wiki.openstreetmap.org/wiki/Simple_3D_Art” and almost forgot it. There are much more artful places in OSM. Some can be found in the twitter feed “OSM__go”.
But I think, creating labyrinthine Objekte as "Simple 3D buildings” is only ok ok for really simple buildings. If I see an artful created fountain in Paris, I don’t think, that should be part of the OSM data base. That’s a job for the model server. Building heights or levels are necessary, roof types and colours are fine. But building:parts only intent do create an exact outer view. And they will interfere with indoor mapping! For objects of a certain complexity, they should be “exported” into a file format for 3D editors and the 3D model should be placed in the model server.

I see OSMgo as a sandbox for experiments. Recently, I added an OBJ file of my favourite space ship Orion (http://www.orionspace.de/ww/de/pub/english.htm). After “running” around it, I wanted it to fly. That may happen in OSMgo. And it may be my next big project, a “Syfy Space Sip Simulator”. Off-course OSM would be used to show the Earth. So that would be a union of my long time hobbies: Raumpatrouille/Science Fiction, OSM and gravity simulation. After a start in Javascript I may change to WebAssembly & Apple Swift and may even use the VR-Kit. (Mabbox is showing some experiments with OSM and VR-Kit already.)

What do you think about this: The OSM community should start an OSM 3D renderer in WebAssembly. Oh, wait a minute! Java can be compiled into WebAssembly. So OSM2WORLD could run as an Web-App. Supported by a good tile server it could make OSM great again (sorry, a spontaneous joke). But not only 3D! A 2D renderer is almost a subset of a 3D one. But in this case, it would be a 2D vector renderer with many advantages. The view of all objects configurable by MapCSS, even the zoom-height it gets lowly visible, or not at all. So you define the content and the layout. We don’t need special maps for horse riding or what ever, but just a new MapCSS. There are many vector renderer already. Except the experiments, sadly they all are commercial. A community 2D(+3D?) vector renderer in WebAssembly could be the future landing page of OSM.

-karlos-


Die Entwicklung von OSMgo ist angehalten, vielleicht für immer. Das es so weit geht war garnicht angedacht. Ich werde hi und da kleine Änderungen machen. Und “Support”: Wenn jemand neue Fehler meldet oder Funktionen gewünscht werden, werde ich sehr wascheidlich aktiv werden. Wer beim Benutzen von OSMgo etwas Hilfe möchte, den werde ich mit Freuden im Multiuser-Modus begleiten. Mein Freund Martin schreibt gerade Code für eine Flugzeug-Steuerung/-Simulation. Bald kann man mit einem Modellflugzeug durch die virtuelle 3D Welt von OSM fliegen. Wenn der geplante 3D-Server/Service online ist, wird er auch von OSMgo genutzt.

Mein ganzer Code ist nur ein erster Versuch, wirklich kein Clean Code und nicht gut strukturieret. Er müßte komplett neu gemacht werden. Und in gewisser Weise wird er das. Es gibt ein Projekt, teils auf meiner Arbeit aufsetzt. In dem Projekt werden die Sackgassen von OSMgo hoffendlich gelöst, meistens, durch Analysen von vorhandenem Code. Hauptsächlich OSM2WORLD weile es open source ist und OSMBuldings mit einem zumindest offenen Client. Gibt es andere gute Quellen? Die wirklich guten Lösungen sind leider in kommerziellen Produkten wie F4. Aber die werden ein Kommunity-Projekt nicht unterstützen, oder? Ich möchte nicht nur korrekten, kompletten Code sondern auch eine öffentliche Beschreibung der Funktionen und Lösungen. Ja, im OSM-Wiki sind Seiten zu Multipolygonen und mehr. Da sind noch andere Katastropen von Komplexität im OSMgo-Code: Rendern von Dachtypen und sogar Dachrichtungen; Gebäude ersetzen durch Gebäudeteile. Die rekursiven Relationen sind die Hölle. Andererseits, die meisten dieser Probleme sind schon von 2D-Renderern gelöst. Und die sind open soruce!

Einige fiese Fehler werde ich nicht mehr flicken. Wie meinen Dachtyp “gabled” oder das flackern bei Landflächen. Einige Haushöfe oder Lücken in Landflächen fehlen wegen eines Fehlers in ThreeJS. Das könnte in der nächsten Version weg sein. Die Framerate ist meistens schlimm, hauptsächlich, weil ich ThreeJS nutze. Das neue Projekt nutzt Cesium und wird so auch begrenzt sein. Doch Cesium mag später durch nativen Code ersetzt werden. Viele Funktionen, wie die Analyse der OSM-Tags sollten nicht vom Client sondern von einem Server erledigt werden, ein Vektor-Tiel-Server natürlich. Es gibt da schon einige Server, aber meist kommerziell. Ich würde mich freuen, wenn die OSM-Gemeinschaft eigenen Server-Service /- Code erstellt.

Erstellen der Houses of Parliament in London usw. mit building:parts ist eine eigene Art von Kunst. Ich bin immer beeindruckt, was mansche OSM-User geschafft haben. Ich habe die Seite "https://wiki.openstreetmap.org/wiki/Simple_3D_Art” angefangen und dann fast vergessen. Es gibt viele kunstvolle Orte in OSM. Einige kann man im Twitter-Feed “OSM__go”.
Aber ich denke, verwinkelte Objekte sollten nur mit "Simple 3D buildings” gebaut werden, wenn es wirklich simple Gebäude sind. Wenn ich einen kunstvoll gebauten Brunnen in Paris sehe, denke ich, das sollte nicht Teil der OSM-Daten sein. Das eine Aufgabe für einen Modell-Server. Gebäudehöhen oder Stockwerke sind notwendig, Dachtypen und Farben sind prima. Aber building:parts wollen nur die Aussenansicht von Gebäuden genau darstellen. Und sie beissen sich mit Indoor-Mapping! Objekte mit einer gewissen Komplexität sollten in ein Dateiformat für 3D-Eitoren “exportiert” werden und das 3D-Modell sollte in den Modell-Server gepackt werden.

ich sene OSMgo als einen Spielplatz für Experimente. Kürzlich habe ich eine OBJ-Datei meines Lieblings-Raumschiffs eingebaut (http://www.orionspace.de/ww/de/pub/english.htm). Nach einem “Spaziergang” ‘drumherum wollte ich , dass es auch fliegt. Das mache ich vielleicht auch noch in OSMgo. Das könnte aber ich mein nächstes großes Projekt geben, einen "SF Raumschiff-Simulator” Natürlich wird OSM genutzt um die Erde darzustellen. So würde das eine Vereinigung meiner Langzeit-Hobbies: Raumpatrouille/Science Fiction, OSM and Gravitationssimulation. Nach dem Start in Javascript wechsle ich vielleicht zu WebAssembly & Apple-Swift und benutze eventuell sogar VR-Kit. (Mapbox zeigt schon einige Experimente mit OSM und VR-Kit)

Was denkst du darüber: Die OSM-Gemeinschaft sollte einen SMO 3D renderer in WebAssembly anfangen. Oh, warte mal! Java kann zu WebAssembly übersetzt werden. So kann OSM2WORLD als eine Web-App laufen. Unterstützt von einem Vektor-Tiel-Server könnte das OSM “make great again” (Sorry, ein spontaner Witz). Aber nicht nur für 3D! Ein 2D-Renderer ist fast eine Untermenge von 3D. Auf diese weise würde es ein 2D-Renderer mit vielen Vorteilen: Das Aussehen von allen Objekten konfigurierbar mit MapCSS, sogar die Zoom-Höhe bei der es langsam sichtbar wird, oder auch nie. So bestimmt man den Inhalt und das Aussehen. Wir brauchen keine extra Karten fürs Reiten oder so, nur eine neue MapCSS. Es gibt schon eine menge Vektor-Renderer. Außer den Experimentellen, sind leider alle Kommerziell. Ein 2d(+3D) Vektor-Runderer in WebAssembly der OSM-Gemeinschaft könnte die zukünfige Landingpage von OSM sein.

-karlos-