I see there’s a possible problem with the current use of building:levels=. High, pitched roofs, and the points below are not in the wiki, except for a mention of building:cullis:height= at a page that describes itself as a proposal.
This came up when I was tagging an office building with two different parts; the higher part is a bit narrower and several floors higher. Say that the lower part has 4 levels and a “gabled” roof on top of that, but the apex is about, or less than, a half level’s height higher than the cullis, and that the same roof continues “around” the higher part. If I then draw a second building:part=yes way for the higher, narrower part, and I add a building:min_level=4 tag to it, it appears as floating above the gabled roof. This happens, because the said gabled roof is drawn as sloping down from the “floor roof” height of the 4th level.
On the other hand, I know that for many single family houses the roof does slope down from the second floor ceiling at the apex, to possibly even to the ceiling height of the first floor at the side walls and the cullis. However, all it takes is one tag, if such is agreed upon, to tell whether the roof’s lowest edge, or the apex is at the “height” specified by building:levels=*.
Or, the alternative is to draw yet one more way just for the building:part=roof and to use maybe just (in this case) building:min_level=4; although at the moment that makes it think that the ceiling is still at somewhere just above “level 1”.
You can specify height of building using tags “height” and “min_height” this tags should solve problem with building ending on middle floor. To describe how many floors are inside roof you can use tag “roof:levels” [1] (but this hasn’t been implemented yet.). And for roof height you can use tags: roof:angle in degrees or roof:height (this is calculated from building top to cullis)
I was looking for a way of getting the elevation/altitude of nodes with JOSM and I’ve just found your project, it seems very interesting. I’m responsible for engine support for the JogAmp Foundation: http://jogamp.org/wiki/index.php/Maintainer_and_Contacts
Thanks Julien Gouesse. Sorry but I don’t look here for while. If you think this project to be worthy of put on this site, I will be happy to see it there.
The current version of the plugin does not support rendering multpolygon relations such as buildings (building=*) and their parts (building:part=yes) and outer contours (building=outline)?
I have played around with the latest version of your plugin and noticed that you are indeed able to combine multitexture rendering of windows with the building=window node mapping technique. That’s an interesting feature, but I wonder about one aspect of this approach. (To clarify: The approach based on wall segments tagged with the number and attributes of windows is not affected.)
Namely, I assume (and it looks like it based on the debug wireframe) that you need to create additional vertices within the building to achieve this, i.e. vertices on the building’s base that do not correspond to on a node in OpenStreetMap. Inserting additional vertices like that is something I have generally tried to avoid. The reason is that two adjacent areas will not necessarily be rendered visually clean unless they precisely share vertices. If you insert an vertex into only one of them, creating a “t-junction”, this may cause gaps or other graphical glitches because of the limited precision of the rendering - particularly if you have large scenes where the floating point numbers become less dense. This might show up in cases where the building outline shares OSM nodes with an area of e.g. grass or asphalt directly connected to the building.
Do you have taken steps to avoid this or do you expect that it simply will not cause problems?
On an unrelated note, it appears that your code supports multipolygons with non-closed outer ways for the walls only if these ways are either all clockwise or all counterclockwise. Consistent winding is not normally required for multipolygon members in OSM, though. Is this a known limitation?
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)