# Kendzi3D - 3D Viewer as plugin for JOSM.

I think, that it is incorrect rendering. When I write building:levels=1 + roof:height=3, I want to say, that building have one level and roof with height with 3 meters, and a roof is above base of building. I think, that approximate height of building (if there is no roof:height building:height or height) should be calculated as building:levels3 + roof:height (or roof:levels3, if there is no roof:height).

However if there are building:height=10 and roof:height=3 it should mean that total height of the building is 10, not 13.

How it should behave when there is only building:levels tag?
What if it is building:levels and roof:angle tag?

I guess that those are questions with no true answer. I also do not completly agree with Dinamic. 3 meters most probably make a story

is it a levels=1 or levels=2?

this one is definitly levels=1

I think it should be tagged with
levels=1 and roof:levels=1

levels=1 and roof:height=0.5

In case when height is not setup:
when there is building:levels and roof:levels tag kendzi3d behave exactly how you described.

when there is building:levels and roof:height tag, I thing it be should as it is. So roof height is sub from building height calculated based on levels. But maybe some one have any other idea?

What will you say, if I show you another buildings?

Do you want to say, that tagging building:levels=1 + roof:height=2 is wrong?

Do you want to say, that such model (tags building=yes + building:levels=1 + roof:height=2 + roof:shape=gabled) is correct?

is it building:levels=0?

In my opinion building:* tags should express overall stats of a building: total height and total number of levels, including attic/loft

I think this is building:levels=0 and roof:levels=2 as described in Wiki.
building:levels is used 2 054 368 times on a way. If you want to change this, there are many buildings to correct…

It is building:levels=2 or building:levels=0 + roof:levels=2.

Note, that the upper point of normal level (where people can live) can be lower, than upper point of building. And the difference is usually equals namely roof:height.

I think in such manner:

1. if there are N levels (both building’s levels and roof’s levels), we should write building:levels=N or building:levels=K and roof:levels=M (N=K+M, because roof:levels is “number of floors within the roof, which are not already counted in building:levels=*”).
2. if height of roof is 2 meters, we can write roof:height=2 (if there is also level in the roof, we can also write roof:level= ).
3. So if building has 1 level and roof with height 2 meters, it is correct to write building:levels=1 + roof:height=2. And exact height of all building in this case is “average height of level”*“number of levels” + “height of roof”.

Algorithm “we think, that height=building:levels*3” is wrong, because it doesn’t take into account, that building can have roof with height, but without level!

Kendzi 3D v242 doesn’t work with wall=no and building=roof.

left building:

right building:

Why did you remove old post? Why not to add new content to new post?

I start think that it is not so bad idea. But in general you should avoid mixing level tag and height tag. So it should be “forbidden” to describe min height using meters and max height using levels. Same with roof:height.

If we assume that roof:heigh will be added to height generated by level tag it will complicate drawing windows little bit…

tags wall=no and building=roof are not supported currently. I added ticket.

Finally I manage to clean up stright skeleton algorithm implementation for holes in polygons and I would like to introduce automatic hipped roof, very similar to F4.

Additionally if roof type should not be detected automatically it is possible to use roof types:
square hipped – for classical roof on square like base
complex hipped – for skeleton algorithm
hipped – automatically switch between square and complex as described here
Of course roof type 9.0 is still working.

There may still be some problems with it, so please report them.

This looks great congratulation.

Does Kendzi3D plugin work properly now? It crashed at my computer some time ago, but I decided, that it is local bug in my computer, but just right now one our college wrote me, that he also had problems with Kendzi3D plugin.

My problems: I go to settings in JOSM, mark kendzi3d, kendzi3d-jogl and log4, press “OK”, restart JOSM. Go to “3D” - Kendzi3D View - nothing happens. I mark “autostart” and restart JOSM, in this situation I see a sign like “trying to load kendzi3d, it is impossible, do you want to disable kendzi3d?”. The sign is exact, because I write here translation to English (I see sign at my local language).

Our college has sign “Your security settings have blocked an untrusted application”, when trying to start kendzi3d plugin. He tried to decrease security level of Java, but kendzi3d doesn’t work.

In there was change in JOSM api in version 7575. I adjusted plug-in in the release 1.0.180. Please check if you have that version installed, if not update it. You can do it by Menu > Edit > Preferences > Tab Plugins > Button “Download list” > Select kendzi3d plug-in from list > Button “Update plugins”

If it won’t help please send PM with console output as described here.

User Andrei Maneasa from the University Brasow in Romania has programmed under my and Kendzi care following plugIn:
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Improved_Kendzi3D

I hope, this plugIn can make 3D mapping more comfortable.
Of course, this is not the end of the develping:
More features should be realized in the next months.
Thanks for the user Kendzi for support and the company Elektrobit for financial powering of this development.

By the way: I spoke at the SOTM 2014 about S3DB 2.0.
The description in Wiki comes soon.
Improved Kendzi 3D should support these elements.
I hope everybody of you will have more fun with the work work with S3DB 2.0 because of more flexibility in 3D modeling with.

I released new version of application. New futures are:

• new selection, now highlighting is made by outline not as ugly bbox
• new editors. Now they are always the same size on top of object, so no longer hidden editors
• editor could be highlighted when mouse is on it and it could provide some more information like height of building
• new editor for height of building roof

This release contain massive re-factor of code so it is quite possible that there are some bugs there. If you find them please make bug report.

Hy, i’ve used the plugin the plugin the first time since the update.

Now there is that problem: (on a macbook using Yosemite)

If the plugin is started i could not select more than one node or way by holding the shift key. only the last node is selected then. if the plugin is not started, josm works normal.

The problem exist since some weeks both in Windows and in Linux.

Sorry for that, I will fix it as soon as possible.