There could be a second poll „my second wish“, scoring 0.5 points
1 Like
That Sounds like a merge with OSM2World at the end, to get a Great 3D viewer.
A building editor does not need elegante around the edited object.
1 Like
Another thing which would be a nice addition is to visualise:
- basic landuse
- bridge outline / area
as they are often found together with walls, fences and buidldings bridge:support=*(pier, abutment etc..)
1 Like
A nice addition for me would be in this order::
- Support all this roof:shapes: Key:roof:shape - OpenStreetMap Wiki
- Support inverted roof shapes (e.g for arcs)
- Support
roof:shape=saltboxas well asdouble_saltbox,quadruple_saltbox. - Render
building:part=roofin the same way as F4 does (no ‘side’ walls). - Don’t render buildings which have no 3D Tags (to find them better)
2 Likes
Another thing.
The plugin is assuming the roof direction for a skillion often correct.
It would be nice to have access to this value for mapping.
1 Like
Thank you all for your answers! I’ve stopped the voting.
Now we have some priorities for the new year 
Luckily performance is not perceived as a big problem
5 Likes
The new version 1.7.0 is out.
It contains a small enhancement which proved to be the easiest one to implement.
- Building parts with
building:part=rooftag are rendered in the same way as in F4, without walls.
So building:part=roof is rendered as in this picture,
Notes:
- ‘side walls’ are suppressed for roof shapes, which actually have them:
gabled,round,gambrel,saltboxandskillion. For roof shape like ‘hipped’ this feature is not of much use. - The tag
wall=nohas the same effect: walls are not generated. However, ifwall=yes, walls are generated even ifbuilding:part=rooftag is present.
How it was before:
3 Likes
Potential new feature in the Urban Eye: base satellite layer (obviously, synchronized with the layer list in the 2D view)
Does that make sense/worth efforts?
10 Likes
That would be just amazing. I’d love to see my handiwork rendered like that!
2 Likes
It would certainly help with orienting the preview window in the correct direction, as an alternative to rendering nearby roads/landuse features.
3 Likes
Ok, let’s see where it can bring us. Some work is required to polish this prototype before release.
With underlying OSM Caro it looks even more funny:
as an alternative to rendering nearby roads/landuse features.
It seems that for rendering roads and other 2D features (like rivers and lawns ) we rather need satellite-like 2D-renderer (but cartoonish one).
4 Likes
Love the pun, that you actually polish the Polish example <3
3 Likes
The new version, namely 1.8.0 is out.
There are two enhancements:
- Rendering of satellite imagery as a ground plane in the 3D viewer.
- Limited set of JOSM layers is supported: public TMS layers and BING,
- It is not feasible to support other layers (like Mapbox) as of now, due to complicated JOSM API.
(see screenshots above).
- Object, selected in 2D view, is highlighted in 3D view also.
This should make the life of the editors easier.
Both features are experimental, so if something does not work, please let me know.
P.S. I had to implement the TMS client myself. It proved much easier than cutting through the jungle of the JOSM API. Whether JOSM has a thread-safe, GUI-independent tile cache is still a big unknown.
Maybe that’s not critical for us, since exotic satellite layers aren’t the focus of our plugin. Our focus could instead be a custom 2D renderer that imitates satellite imagery using OSM data. The result could be similar to OSM-Carto, but with natural colors and without labels.
10 Likes
Well, I’m starting to think this whole satellite/2d layer hassle is some Swedish thing: there is nor way I can finnish it!
Development screenshot: with less labels and underground objects it seems better:
3 Likes
We once used a top-down view (orthogonal?) of OSM2World to dynamically renderer a well fitting 2D ground bitmap.
1 Like
You forgot it is too Damnish…
1 Like
The 2D basemap with own style is still a work in progress (and requires new JOSM release), but I have something interesting for you.
Dear friends! Meet the new and possibly quite controversial version of the plugin – v1.9.0.
It introduces hyperboloid structures. Now the shape=hyperboloid tag is supported, making it easy to model buildings and structures in the shape of (you guessed it) a hyperboloid.
The Hyperboloid in Architecture
There are many such buildings and man made structures all over the world: from the very first Shukhov water tower (1896), which, by the way, still stands today, and the famous Shukhov radio tower in Moscow (1922) to modern architectural masterpieces — the Canton Tower in Guangzhou (2010) and the Jübergtower lookout tower (2010) in Germany.
Why do architects love the hyperboloid so much? Because despite its apparent curvature, it can be assembled from straight elements, like straight steel (or even wooden) beams. This gives it strength and lightness with minimal material usage. The aforementioned Jübergtower is assembled from 240 wooden beams.
Furthermore, the hyperboloid shape is common in industrial architecture. Hyperboloid cooling towers are very widespread (in OpenStreetMap we know them as man_made=tower + tower:type=cooling). The smooth curves not only give the structure strength with minimal materials but also make it function like an aerodynamic nozzle. The narrowing in the middle (the hyperboloid’s “waist”) accelerates the moist air flow, effectively sucking it upwards, while the subsequent expansion helps it disperse efficiently into the atmosphere.
What’s supported in UrbanEye3D
-
The
shape=hyperboloidtag — adding this gives a building or its part a hyperboloid shape.- The hyperboloid shape is never applied automatically (not even to cooling towers); you need to add the tag manually.
- The tag can be used on buildings (
building=*), onbuilding:part=*, and on towers (man_made=tower|water_tower|cooling_tower). If you tell me what else this shape could be applied to, I’ll add it. - The tag works on ways and multipolygons without holes. It doesn’t work on buildings with holes yet, unfortunately.
-
The hyperboloid shape is defined by the tags
hyperboloid:top_rateandhyperboloid:middle_rate.hyperboloid:top_rate— the relative width at the top. Can be from 0 to infinity (values greater than 1 widen the top, values less than 1 narrow it).hyperboloid:middle_rate— the relative width at the middle, the narrowest part (“waist”), from 0 to 1, where 0 means it narrows to a point, and 1 means no narrowing.hyperboloid:middle_ratecannot be greater thanhyperboloid:top_rate.
Tweak the values to achieve the desired curvature.
Comparison with F4 Map
F4 Map is capable of rendering hyperboloids (without parametrization) and assigns this shape to some objects automatically, but the exact algorithm is not known. I don’t want such automated assignment in the plugin, especially without a means to override it. After all, even cooling towers come in different shapes. Maybe we’ll need something like shape=prism or shape=frustum in the future. But that’s a matter for later.
So now, folks, it’s all in your hands. Go fire up JOSM, enable the plugin, and start modeling!
There’s a ton of work to be done: en.wikipedia.org/wiki/List_of_hyperboloid_structures! 
6 Likes
Call for help!
The same place again, but no with trees:
This is a screenshot from a development version of the plugin, scheduled to be released by the end of March, together with the next release of JOSM (josm-tested).
In version 2.0 UrbanEye3D will support trees, but currently I have just one texture, and even that one is borrowed from osm2word.
So, if you want to contribute, it’s the opportunity.
What exactly is needed:
- Tree textures for billboarding (two crossing planes method)
- Specific images for various combinations of tree additional tags, like leaf_type=* , genus=* , species=* ) will be very helpful.
- Some height variations seem also be useful, because tall old trees and small young trees look differently.
- Images should be square in PNG format with alpha channel (transparent background).
- Moderate resolution, e.g. 256x256 or 512x512, higher resolutions are not needed.
- License should be free and compatible with GPL 3.0 used in the plugin. Credentials can be included into about screen (or readme file) , if desired. (There is no about screen in the plugin currently, but something can be organized, I believe
)
Example:
Textured low-poly models (like those used by F4) can also be utilized.
Any help is appreciated.
4 Likes
Some more or less stupide ideas:
- Different versions for seasons (green, no leafs, snow, with fruits)
- Rotated by random for just better looking woods
- For tree-rows small dis-allocations by random looking more trustfully
- For all without “height”: small different sizes by random for the same
- Textured low-poly models only near by the camera (if there are MANY trees)
3 Likes
I’m a tree-mapping fan, so I’m glad to see a new 3D renderer in town. A few more stupid ideas:
- Most 3D renderers only support height. It would be cool to render the trunk circumference as well.
- We have much data about species already. We could create a table[1] with average height to circumference ratios and use it to estimate a plausible height when only circumference is tagged, and vice versa. At least for the most tagged species.
- F4 has a problem when a tree row has tree nodes mapped as well, rendering overlapped trees. Maybe a logic similar to “Simple 3D Buildings” could be used: “When a building has any
building:part=*areas, the building outline is not considered for 3D rendering”. So “When a tree_row has any tree node mapped, the tree_row is not considered for 3D rendering.”
I have a little one in my wiki userspace with four of the most tagged species ↩︎
3 Likes