Uh, not really. Original phrasing of that principle was very unfortunate, and thus many people misunderstood it. The more correct term is “Don’t mistag for the renderer” or “Don’t lie to the renderer”.
Tagging correct data for a renderer (or router or any other data consumer), even if that data is used only by one single data consumer at some point in time, is not only fine, but encouraged. In fact, entering correct data which will be used by random data consumers is the whole point of OSM existence.
What is not okay, and the reason why that principle exist, is clearly given as an example on wiki above:
For example, if landuse=industrial shows up as a pink area on one of maps, and you have a flowerbed full of pink roses, then tagging your flowerbed as landuse=industrial would be incorrect and must be avoided. Instead, you should accurately tag the flowerbed with landuse=flowerbed and improve the renderers so they understand how to show it.
Screenshot from development version, just an experiment, very far from release readiness.
However, UrbanEye3D 2.0 with trees and some other improvements will be released shortly after the new version of JOSM. JOSM guys are a bit behind schedule: 26.03
The new version of the plugin 2.0.0 Trees, Roads and Rivers is out!
this is a big update for the plugin and I have worked on it about 3 months. I hope you will like it. Here’s what’s new.
What’s New
1. 2D Ground Plane
Buildings no longer float. The ground surface is displayed with “flat” objects - roads, lawns, rivers, and lakes. This flat layer is rendered based on downloaded OSM data using a custom MapCSS style. Alternatively, a satellite background can be enabled, as before.
Height is taken from the height tag. If height tag is missing, the circumference tag is used to estimate height.
Two tree textures are included: broadleaved and needle-leaved (based on the leaf_type tag).
More textures could be added for various species/genus – if you’re good with graphics, feel free to contribute!
3. Whole Multipolygons
Missing members of multipolygons and building relations can be downloaded automatically. Without this, the map often looked broken – like buildings cut in half or water spilling everywhere. The Building relation, which seemed completely useless, turned out to be good for something.
You can turn it off in the plugin preferences if multipolygons in your area are too large.
4. Background Processing
The UI no longer freezes when you load a large area. Everything is calculated in the background. It still takes time to render a big area, but at least JOSM stays responsive.
Contribute
This is a one‑person project, so any help is welcome:
Textures for more tree species. See some details here.
Since you added the trees, I see your plugin on the way from an object viewer to a full area viewer. If so, the 3D view you render could not only be used as edit-helper but to use the 3D view in applications. Exporting an area “tile” as a gilt/GLB file would enable that.
Translations into the following languages have been added:
German
Italian
Slovak
Russian
Thank you all who contributed!
If you would like to translate the plugin in any other language, here is the pot file. We do not have any web UI for translations, but you can use PoEdit instead.
Difficult to say as the renderer is already very good. One thing that might be useful for some would be the ability to edit the tags from the renderer itself. Clicking on a roof to choose a roof shape for example. Or the levels / height. This could make 3D tagging easier for those unfamiliar or prone to make typos (as I am).
Hi, not sure this is appropriate here, but anyway… I have completed my first 3D-church and noticed two things.
If I give the tower a min_height of 10 instead of letting it start at the bottom, it will slightly change colour. It also seems that the apse and side annexes have a slightly darker colour.
I haven’t figured out a practical way to not intersect 3D volumes. At the very least, I’d have to create roof only parts and intersect those.
It’s due to “fake” ambient occlusion effect. The plugin tries to make colours vary to make the picture more realistic and eye-pleasing. You do not like it, you may turn it of in plugin preferences or just by pressing Shift+Z (if you have many plugins installed, the sortcut could be changed by the josm to smthing else).
practical way to not intersect 3D volumes.
Bad news:
In many cases, especially in cases of complex roofs, there is none. The lesser evil is belived to create separate parts for roofs and intersect them only. I personally do not know, is it better of worse.
Good news:
In this particular case, you do not need those complications. Just 4 parts are quite enough. One for tower with dome roof, to parts for side extensions with skillion roofs, and just one part with hipped roof for everything else.
I’m impressed, didn’t know hipped can do all that. In this case, hippedand side_hipped seem to behave the same way. There’s a minor difference where the roof meets the tower, but I get the idea. Thanks for the quick reply.
I believe it’s not about editing tags directly in the 3D window, but rather about select-by-click. One clicks on a building\part, and it gets selected, so that you do not need to find it in 2D. This is possible, I will see what I can do about that.
They almost convinced me that I should support saltbox as it described by the roof:shape=saltbox wiki page.
If anybody has to say something against it, it is your last chance
Open questions are
how to treat roof:height, is it height from ridge to upper eave or to lower eave. I think it could be the longer one.
how to treat roof:direction. I think it could be direction of the longer slope :)
It still seems odd that the OSM4D shows this as
The problem with OSM4D is that it’s some kind of memorial page, it cannot be adjusted.
The real discussion we need to have is about whether mansard rooves should have a flat top or a hipped top
Incidentally I was trying to work out how to tag a 3-sided flat topped mansard roof the other day and couldn’t find any documented tag or example - screenshots are attached of the shape I was trying to create (mocked up with skillion rooves).
Agreed with the above assumptions 1&2 for how to treat saltbox rooves. It would be useful to add information to the individual roof:shape wiki pages about the way roof:direction should be interpreted (roof:shape=saltbox doesn’t even mention roof:direction despite obviously needing it). I’m also thinking in respect to how roof:direction is interpreted when tagged on roof:shape=hipped and roof:shape=half_hipped.
OSM4D page suggests that it should be triple_saltbox I wonder, however, if such roof exist in reality, they should have some name in natural language, should not they?
