Some of you already know my current Open Source project, OSM2World, but I have not yet written about it on this forum. With an OSM2World image being featured as the current “image of the week”, I think it’s high time to change this.
OSM2World is a 3D renderer/converter written in Java. It can create 3D models from OpenStreetMap data.
Features include:
writing .obj and .pov model files (you can also easily add more output formats)
rendering .png images, including map tiles
drawing directly to OpenGL
a graphical interface with real-time rendering
a command line interface with many configuration options that supports automated rendering of images on servers
support for a growing number of OSM attributes and objects, from billboards and benches to railways and buildings
Yes, it can do this, but only if you convert that data to an OSM format and merge it with the input data.
The quality is very much hit-or-miss at the moment. That’s why elevation calculation is disabled by default. If you want to try it and are working with OSM2World’s graphical interface, you can use the menu entry “Options → ElevationCalculator” mentioned by viw. Among the non-zero elevation options, “ForceElevationCalculator” is going to produce the least broken results with normal input data. (“EleTagElevationCalculator”, for example, would require you to edit/preprocess the input so that every single node has an ele tag.)
As a future perspective: Elevation calculation is a feature that I’ve planned for from the beginning and I expect to have it working reliably at some point during the next year, but I’m still working on it.
IIRC another user of OSM2World has already used these for his experiments, so I think they should work in principle. A bit of preparation might be necessary as the files declare using API version 1.5 instead of the current 1.6 version. I could test this myself tomorrow if you want a more definitive answer.
Oh, I’ll look into that.
You can overwrite the default textures by using #declare instructions. For example, to replace the boring grey for asphalt surfaces with a bitmap texture, add
I’m not actively working with SRTM data myself right now, so I can only speak from my limited experiences and users’ reports.
OSM2World can work with ele tags on nodes and/or ways, so whatever process you use needs to result in that representation. Merging data simply means that the SRTM-derived data and the original OSM data need to be in the same file. For manual one-time experimentation, even combining layers in JOSM should be sufficient. The srtm2osm tool looks as if it would work very well for the task, too. (But no guarantees, as I haven’t used it myself yet.)
Hi
I’m new user to osm2world. I’m trying to render data downloaded previously from OSM by JOSM editor. But unfortunately I recevie only this crash box:
What’s wrong? Please help me.
Can you send me the file you are trying to load? That would it make it easier for me to find the reason why it doesn’t work. My email address is listed on http://osm2world.org/contact/
That error may be caused by various problems, including incomplete ways and - under certain circumstances - incomplete relations.
In case anyone wondered: We have since identified the reason for the “Could not perform conversion” issue. While errors like that are often caused by the extraction procedure, that was not the case here. Instead, broken building geometry within the OSM database triggered the problem. The area in question contained building areas with only 2 distinct nodes, as well as self intersecting outline polygons.
OSM2World actually provides meaningful error information in cases like those when it is run from command line, but these details unfortunately do not show up in the graphical user interface yet. This is something I intend to improve with a future release of OSM2World. I also plan to make it more robust: Preferably, it should drop these buildings or try to make the best of them and output a warning, but continue the conversion.
It has been a while since the last official release and there’s still some work left until 0.2.0 is finished, so I decided to write a post about current developments at OSM2World. The most important feature of the next version will be the newly introduced support for textures. It has already been implemented for OpenGL and OBJ; the POVRay export doesn’t support textures yet.
While I’m at it, I’m adding a few interesting details beyond basic texturing. This includes rendering of building walls with multitexturing and color blending. This allows (as previously described in another thread) to set a wall’s material, color and elements such as windows independently.
OSM2World is not yet evaluating any detailled attributes for windows. The software simply tries to find a plausible window arrangement based on building shape and number of levels, e.g. by making sure that the number of windows on each wall is an integer. A small number of building types, such as garages, get special treatment.
Textures can be PNG or JPG files. PNG textures also support an alpha channel. This allows partial transparency, as demonstrated below with a chain-link fence, which also allows a more realistic rendering of trees.
Adding textures has been made possible to a large part by Marek’s initiative to create a Texture Library and the contributors who have donated textures. Many textures used in the renderings above have been taken from that library and its existence has motivated me to implement the feature in OSM2World.
Hallo
Habe heute Installation unter Ubuntu 14.04 gemacht von Ubuntuusers, alles IO
Programm läuft
Dachfarbe wird als rot angezeigt bei gray und silover ? In der Programm Vorschau.
Mal sehen wie es auf der Webseite aussieht
Halle Saale Voßstraße 2 Häuser rot 11 Stockwerke Stirnseite ohne Fenster.
I am playing around with turn-lanes on OSM ways in the moment, thus I am looking for a good way to display highways with each lane when having direction arrows.
So my aim is to display such a bitmap (or many tiles) from raw OSM data for a specific region with highways like the screenshot, but in 2D and NOT in 3D … like perspective on main osm.org
So far I played around with osm2world on my PC and I was able to load and display some data, but how can I achieve such a 2D Rendering of streets?
To get a 2D rendering, you can configure the virtual camera of OSM2World to look on the scene directly from above. This will result in square tiles with the same perspective as those on osm.org. In order to cover a larger area, you will likely want to set up an automated process to generate map tiles. Depending on your needs (size of the area, frequency of updates) this can be relatively easy or quite involved.
As the first step, it probably helps to get familiar with the OSM2World command line interface, as that is easy to use in scripts for automation.
If you give me a bit more info (area you want to render, how experienced you are with the command line and scripts, whether you have a server available …), I can help you to set this up.
Hello Tobias,
as you have seen, I started a first frame for a tutorial about my aim on wiki discussion page from the german OSM2World article there.
So I managed to load a small extract of raw OSM data in the latest GUI version, and I can zoom and rotare with mousebuttons and wheel.
But when I choose Camery → Ortographic projection, the screen content turns black with no content!
Is that reproducable on any other PC by another user?
As I am still not so familiar with camera position settings and view angle parameters in OSM2world:
Is there an easy way to get a view directly on that area I want to render which is called ortographic / senkrecht ?
Turns out the ortographic projection in the GUI is currently broken. I’ve wrote myself a note about this here. You will still be able to produce images with orthographic projections via the command line, though.
I recommend to use the command line anyway, as it gives you more precision for configuring the view. If you need help with the OSM2World commands in particular or command line usage in general, I’m here to help. The relevant parameter for orthographic perspective is --oview.angle 89 (or something else that it close to 90°). Then you can use --oview.bbox , , or --oview.tiles ,, to define the intended area.
I’ve wrote myself a note about this 
