I don’t now if I understand the problem. I’m using nodes with window definition (tagged building=window). In my implementation windows are cut out from wall. The reason that you can see vertical lines like this:
It is that i don’t implemented any real 2d polygon union and intersection algorithm. I emulate this by simply cutting polygon by line. Cutting creates additional vertex which you can see by vertical line (first cut) and t-junction. But this can be easily fixed replacing my algorithm and using polygon union/ intersection function. Maybe you know some opens source (no gpl inside) library for 2d polygon union/intersection or algorithm description?
Currently this implementation don’t cause any visible problems so fixing this is not priority.
Multipolygons are work in progress so I fixed this.
I wonder if we can assume for buildings that:
end or begin of not closed way is always connected to only one way (no Y-junction)
Kendzi did change some parts and moved some functions out into several JOSM plugins. Go to JOSM settings for plugins and install those two plugins extra, restart JOSM and 3D does work again.
I ask someone else for test and it is working. Do you use proxy, vpn or non standard dns server? Can you ping host www.openstreetmap.org.pl ? It should return ip 195.2.255.33.
If it is problem width dns server, you can try to setup as primary dns ip: 62.129.252.31 (from dns.home.pl)
Hi again I tried to get Kendzi3D running, but on JOSM startup (NAG screen still open), a new Kendzi3D window appears but the whole editor startup is blocked (still NAG screen displaying "checking plugin requirements kendzi3d)
Tried to log something on console, but not very detailed IMHO:
Thank you! But now at home I can’t test it by the other internet provider. Here the download work well and openstreetmap.org.pl is working too. For me it was interessting that I could donwload too plugins and but not the third main plugin.
For me it is mystery why it wasn’t working. Where was complaining from other people too. But it is problem with hosting. I hope that new location will work better. I will move all files in few days.
What if the dormer don’t start at the edge of the roof. With the roof rows it is not optimal. it seems that there are only 5 rows possible, so i can let start a dormer at only 5 different points. it would be better if i could set the value in meter.
there is a tag in wiki:
I currently read only 5 rows. How many rows should be allowed?
This way of tagging dormers was shown as idea and it hasn’t been implemented yet. It is base on dormers index and maybe it isn’t best way to do it. If you have any ideas please write them on wiki in discussion tab (best in English).
Yes officially it is used colour tag in OSM, but many people use color so I support them both.
I don’t know if more than 5 rows are needed. but with this kind of tagging i could only split the roof in 5 parts, where I can place the dormer.
For example if I have a 5 meter roof and the dormer is 1m away from the edge, I have to place the dormer in row 2. and I have to set a row 5 with no dormer (‘3dr:dormers:front:row5=-’). if i don’t set row 5, the row 2 is in the middle of the roof.
Because of this I meant, setting the distance from the edge in meters with a tag would be better.
There are few things to work out with dormers. Currently the easiest way is to add tag 3dr:dormers:front:row5:depth for entire dormers row. We need to work out easy way to add custom tags for each dormer. Some time ago someone proposed to use nodes for dormers.
I for some time try to focus on adding new roof shapes and editor capabilities. So it is good time to write down some ideas about dormers.
New things:
Holes on flat roofs:
new half-round roof (5.2)
The round depends on roof:height tag.
In next release I will change behavior of roof:direction tag. Currently it is pointing form left to right side of building. After change it will pointing to roof front. As it is discussed here.