Work is in progress, features are improved and added. See the OSM Wiki page for more details and read some background infos below.

There is an Twitter-Feed: https://www.openstreetmap.org/user/OSM__go (two underscores!). You may follow the latest activities, upcoming ideas and related things.

Tile processing

Overpass seemed to be slow but my measurement was wrong because Javascript even delays console.log while callback code is running. A close inspection showed: Overpass is great, my code with a lot of string copy was slow and is now replaced by jQuery.js and getJSON. Much better, much faster but there was still that “wait-cursor”. Again it was me. I had simple linear searches for already existing nodes or ways. I replaced them by arrays with the OSM-ID as index. Odd to debug but fast. Now, the default load radius is set up to 800m and still fast. Or fine, if you are in a dense city. Old hardware devices may have trouble and get slow. Now the download will stop.

Thats was not the end. I move the tile/tag decoding and the 3D object placing (not yet parseJSON) away from the callback into the render cycle, sliced in fast steps. Now, the default load radius is set up to 800m and still fine in a dense city. Old devices may break downloading. And you may even move already during the download. - One more thing: The first load will be more slow than thereafter of curse - because of the just in time compiling. ___

Overpass gives an array of elements, first all node-types, then all ways etc. “parseJSON” can only convert this to an single array with mixed types. Is this good? Building tags may be placed at ways or relations(multipoligon). Decoding code would be the same. So it may be good to have all types in one array. But OSM does not have ONE set of IDs!

What about an “overparseJSON” ?: It should convert to separate arrays, one for notes, ways, and relations. It shouldn’t be hard to morph the jquery-code. And there could be a callback for each node, way, etc. So I could immediately extend the node- and way-instances to my needs like adding the three-ja-mesh.

Colors

Even if the shape of buildings are fine, paint makes them more realistic. Handling the tags building:colour and roof:colour was easy. Chroma.js does convert the color tag strings and Three.js ExtrudeGeometry also handles different colours for the sides and the ends. So after 10 lines of code and 1-2h test it was done. But soon Murphy’s law strikes back: There are quite a view named colours, not known form three (see wiki). Tags like light_brown or yellow-brown may be handled automatically. But what about spelling errors and unknown colours? That may be a task for the validators like Keepright.

Shadow

Jan (OSMBuildings) asked me, how fast Three handles shadows: about 20% more rendering time. When you start now, the place around that point has shadows. To show the effect even more, a big disk flies over you. There are still some shadow options to investigate. In the Code, a virtual camera is placed at the shadow casting light. Mostly the graphic card is doing the hard work. This “camera” analyses the shapes, if they cast shadow and if this shadow is seen by the “real” camera. A greyscale bitmap is generated and placed between before the virtual world. Looks good. Todo: move the virtual with the real camera.

Placing Modells

For quite a view buildings, extruding doesn’t make much sense, especially for famous buildings like churches or monuments like the Eifel Tower. There are 3D-models of many of them. To place them in a virtual 3D OSM world doesn’t help for data visualisation but for an realistic view. And it’s cool anyway, if you move around by mouse or with VR glasses.

What to render: Where to store and get the model files?

• I like the Idea of osm.wiki/OpenBuildingModels, but its offline :-( I got in contact, may be we will have the files and set up them on a new server and even extend the service to other formats.
• Meanwhile I did the two models, OSMBuildings uses. (They are not perfect yet)
• OSM2WORD and other 3D-viewer seems to have a lot. Who do the to that?
• What about Google Scetchup? I will try to get and dynamically convert all the models. Three.js does have loaders for many file types, that seems to be no limit. But I am sure there is a copyright prohibiting a use.

How to place: My first answer to the following questions was an OSM relation for each model to place with special tags.

• First the model file. The concept of OpenBuildingModels is great. A reference to an external server with the file. (server-code, model-name/ID and may be file type.
• The model may be directed correctly already or we need a tag to do it, useful if a model is used more than once.
• There may be a tag for scale to, and even a hight-offset.
• Now we need the place. if there is no existing node to reference to, it has to be placed.
• Usually there is one ore more building-ways in OSM, representing the building in a 2D map. They have to be removed/skipped by the 3D renderer. So wee need a reference list to them. The solution used by OpenBuildingModels is simpler: One Tag with Server and Model. No direction, size and height. And this tag is added to each building to be replaced by the model. I like that.

Other changes

• The debug output now shows the FPS (add &hud=1 to the url) Disappointing: 40 down to 10 FPS with 3D models displayed. Strange: it doesn’t feel slow.
• Added new URL parameter: “&keep=1 or 0 for show/don’t Keepright error markers. Default is don’t
• Level & Layer: Underground objects shouldn’t be seen above, bridges should be raised. Now the tags level and layer are used.