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-