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?
9 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.
7 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:
2 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