Strange. It never crashed before. 
Could you please provide me with osm file? Or coordinates of bbox?
Sorry can’t reproduce it. Today everythin was fine 
1 Like
Never a fail here, but I do tag roof:orientation to tell if the hip is on the short (across) or is on long side (along). Then I use the KindaHacked plugin extension’s H shortcut to add the roof:direction.
2 Likes
@SekeRob, why do you need roof:direction if you have already set roof:orientation?
1 Like
Orientation along/across only tells if on the long or short side, does not tell which of the two short/long sides… direction will. Strictly only direction would be enough for roof types like side hipped and skillion, but I’d like to be complete.
1 Like
Hi, could it be possible, that saltbox has the wrong shape?
1 Like
I would say that there is no real consensus about roof:shape=saltbox. Other wiki-pages describes describes this shape differently, and there are different opinions even in single bug report.
Urban Eye just follows rendering of F4 here.
2 Likes
Besides the very-WIP OSM Wiki: OSM-4D proposal, where are the conflicts? (ref: OSM Wiki: Tag:roof:shape=saltbox#Common_tagging_mistakes)
The existing roof:shape=saltbox rendering by the plugin is definitely incorrect.
roof:ridge=yes could be used to indicate the location of the ridge, as I have (experimentally) done here and here:
In its absence, just default to the ridge being at the ⅓rd mark along the edge.
Let roof:direction=* work just like roof:shape=gabled, but with the long side of the roof sloping down in that roof:direction=*.
Perhaps I should just use two skillions …
Unnecessary complication - that requires two additional building:part=* areas, for something that should just be represented as a single tag on the main building=*.
1 Like
I don’t know if the ticket system is for plugin creators, too…
I got the “crash” again.
€dit:
like @ivanbranco proposed:
I would rather open an issue here:
2 Likes
Osm-file or coordinates are highly needed!
1 Like
The bug is fixed in 1.6.1
@SimonHarms, please pay attention to validation results. You examples contain a lot of broken geometry, it may impact generation of 3d models negatively.
2 Likes
The UrbanEye3d plugin has been around for almost six months now and has been downloaded around 25,000 times totally (all versions) and about 7,000 times by different people/computers. That seems like a lot, but I don’t want to stop there. :)
So, I’d like to ask the community what improvements you’d most like to see in our plugin.
Please vote in this poll. Note that you can only choose one option.
What is the most necessary enhancement in the UrbanEye3d in your opinion?
- Render
building:part=roofin the same way as F4 does (no ‘side’ walls). - Add more objects, e.g. roads, rivers, street lights, etc.
- Support the base:shape proposal.
- Implement rendering of building passages (
tunnel=building_passage). - Improve performance/responsiveness of editing in large scenes.
- Improve rendering, implement real ambient occlusion and/or support materials (e.g. metal and glass).
- Support
roof:shape=saltboxas well asdouble_saltbox,quadruple_saltbox. - Some other improvement (please describe it in comments below).
0
voters
The results will be used to prioritize future development ;)
2 Likes
I voted "Add more objects, e.g. roads, rivers, street lights, etc", especially I would like natural=tree rendering (height, circumference, leaf_type) and area:highway=* rendering.
4 Likes
Voted for base:* but really, the above poll should have been a multiple-select rather than a single pick IMO.
5 Likes
Roof without side, tunnel=building_passage and building:facade would be great 
1 Like
There is only one manpower in the project currently, that’s why only one vote
7 Likes
Would this be an optional rendering mode? (F4 mode)? As this question has come up before with no clear answer as to whether building:part=roof should always have open sides or not, and no consensus among different 3D renderers.
As for the poll, I’ve voted for experimental support of base:shape (as a neutral third party) ;)
2 Likes