It’s still fun to improve “OSM go” and add new features. After adding some lines of code, and trees get visible; and there are really a lot of trees in OSM. The main idea still is visualising OSM data. A really realistic view may be possible and may be done (much) later (As teamwork with OSMBuildings and OSM2WORLD, I hope)

We made an experiment: OSM2WORD offers to export an area as 3D format “obj”. And “OSM go” is able to show this, including colours. Jan (OSMBuildings) exported some areas to test, they may be used as 3D-tiles in an thin client. Works fine: Twitter-Post

The controls have been reworked generally. Now there are two ways to move and look around, the ‘Inspection-‘ and the ‘Segway-Mode’. ‘Inspection’ is default, use the key “C” to change the mode. ‘Inspection’ is what you know from other 3D renderers like OSMBuildings: By keys, you move your point of view, by mouse or touch, you move the 3D world.

To see all improvements and details, drop by or follow Twitter @OSM__go. To test the latest version of “OSM go”, use the new web URL OSMgo.org. There you will see almost daily changes. Its work under construction! It may work or just crash because its also my online test sandbox! You may try older versions at OSMgo.org/versions. And all information to “OSM go” is on the wiki page

Nodes & Data

The first versions of “OSM go” only showed ways or areas, no POI. But now the Overpass query is extended to get all nodes to. It startet by an student of HSR Rapperswil. He tested how hard it is, to extend OSM2WORLD to add 3D models of ‘’’tables’’’ with chairs (amenity==”table”). It worked fine and I got the code to, rewrote it to Javascript and so the first OSM object was visible in “OSM go”. It motivated me to write a small library to create 3D types dynamically by the actual OSM tag values. I also also added a more popular OSM node leisure==“picnic_table”. Because I was on holiday at the seaside at that time, I also added “generator:source”=“wind”. This is now the first animated node type. Exiting to visit a wind park and see them all spinning.

There are so many different node types, to much work to build them all in 3D. But anyway, now (almost) all nodes are visible, mostly by a read tetrahedron. It is a big step to the goal of “OSM go”, to make all OSM data accessable. Klick on a ‘red gem’ to get all the tags listet. There are quite a lot of nodes visible now! For some, it is not really useful to show them:

• If it is only a level tag of a way, it will not be visible. Also if it is only a tag “created_by”
• It doesn’t make sense to show a railway- or highway-crossing, does it? It is visual by the ways crossing anyway. What about imaginary objects like stop positions of “public_transport”? There may be a busstop sign anyway. You may want to see this abstract “ghost objects” or not. User the new URL parameter “&abs” to decide, default is off.

Now or then, types of nodes will be designed in 3D. The first are realised: “natural”==“tree” and “barrier”==“bollard”. That was rather easy. A busstop will be more difficult because each country may have it’s own sign. Sure, they could all be put in a “database”. Much work. Firstly I will use the same symbols as the 2D renderer.

Reasendly I did not find a power:substation, which I had seen before. So an url parameter “&f=“ for filter/find was added. It checks tag names, values and OSM ids. The found objects may be marked by spikes or exposed by dimming all other objects. Quite impressing to use (try “f=!surveillance”!). And it is again a step to OSM data handling. See the Wiki for details.

Rendering in the 3rd dimension

Inspired by a drawing of the London underground I wanted to make some “in earth mapping”. Now the subway tubes are visible as such. It took me a few days of trying until the steps were really correct going up and down in 3D. It is written in the Wiki: Steps don’t need level tags. Levels are defined by the connected nodes or ways anyway. A big problem is the meaning of the tags level and layer. This could get us into an extended discussion. To see under ground without “diving down” by the keyboard commands you may use the experimental URL parameter “&sub=1”

What if a building height is not defined? There was an default by 6m. But now it is calculated by the footprint of the building, the bigger the more height. This is still incorrect but looks much better than an unique value. On the other hand: How do I see, if a building lacks height and levels? Now there is another URL value “&hei=“ to set your own unique height. try “&hei=0.5” and you will see clearly the difference (looks like in “Pokemon GO” :-)

Fighting the render time

All that improvements used to increase the needed render time! My knowledge to optimize this is limited, anyone like to help? Luckily, to show OSM data, it is not necessary to show Buildings till the horizon. Less level of details will be done for remote tiles eventually. Additional time is needed to download tiles in the background. That has been reworked some times already and will be again.

Anyway, the handling of SOM go may get nasty, if many objects and greater areas are shown.

• Press Shift-L to reload the scene with only the local area.
• Hit the key H to see the dt between frames and the frames per second (fps) actual and as less or more average.
• Switching of the shadows by “&sha=0” may help a bit.
• To keep the FPS above 5, now the far-plane will be reduced, remote buildings and roads will disappear. You may set this limit even to 0/off by the URL parameter “&fps=”

Next?

First steps to a real tile handling; deleting tiles is necessary. The fps must be stable to keep the keyboard handling running. May be a “3rd person view” will clarify how a user may move in the 3D world. The Cardboard-Mode is under construction: Head twist should control direction and speed. The data display must be more large for smartphones.

I am not sure about the user experience. What should be changed, improved, added? I would apprichiate any feedback. Please do a test, send me screenshots of your favourite places. Tell me what you dislike or enjoy.