You started as a “Building Viewer”, didn’t you? As I did with OSMgo.org , the project got extended and now it’s almost a full 3D viewer for OSM. Do you accept this as a far away target?
Your tool is prisoned in JOSM. You get the tagging form JOSM, you use JOSM for your 3D outputs. Still there is an independent middle module: Checking the tagging and converting to 3D meshes. You could separate this to a Java library/package/module with a documented interface (tagging lists in, mesh data out). So it could be used form other projects. (Example: Output into a GLB file)
Well, I actually have a report that shows missing features.
Judging by it, the next addition should be wind turbines and surveillance cameras, but for some reason, nobody is asking for them. 
I probably won’t make the surveillance cameras, but the wind turbines (huge, highly visible structures) are already in the works.
Your tool is prisoned in JOSM.
Yes, it’s prisoned in JOSM—much like a fish is prisoned in water.
I tried creating a standalone Android app, but for one thing, it would require extensive reworking, and for another, it’s not entirely clear what purpose such an app would serve. What kind of functionality would actually be useful?
Example: Output into a GLB file
osm2world handles that quite well.
Question regarding height, roof:height, min_height
In the past I used levels for this which isn’t correct?
But when it looks like UrbanEye3D don’t min_height and roof:height?
typo thanks @Jarek
This is a typo, should be roof:height
Very good, but since the plugin is already so good, please allow me a small suggestion: the Swiss flag is actually square, not rectangle.
Fair enough. Will be addressed in the next release
Agreed. And not only in sattelite imagery; colors and white balance is hard (and not always possible)
In SCEE there was idea for roof/building color picker from phone camera, but some preliminary research (see SCEE #633 comment and around) has shown too much variation even for same roof/building colors.[1]
And trying few methods to normalize colors to smaller pallete to work out the “average” color name (instead of high fidelity but too low-accuracy RGB) didn’t work too well either.
and workaround of carrying a sheet of white paper with you and doing manual WB-calibration before taking RAW images was way too complex to be useful in practice. And checking location, sun position on the sky, and local weather prognosis for clouds too much guesswork and prone to too much errors anyway. Not that it would helped in this case of satellite imagery even if it was feasible ↩︎
The new verison of the plugin, v2.8.0 October Wind is out! I hope you will like it :)
In this release wind generators are introduced and Flagpoles are revisited
Wind turbines (power=generator + generator:source=wind, or generator:method=wind_turbine) are large and highly visible objects. In some countries, entire fields are covered with them. In OSM, there are over 400,000 of them, which is a significant number.
Wind turbines are now rendered in 3D using a procedural model: a three-bladed rotor with a nacelle on a tapered tower, built to match the OSM height and realistic proportions.
height defines the total height of the model: from the ground to ther rotor tip in its highest positon.rotor:diameter — rotor diameter; if absent, derived as ~66% of the height.height:hub — from the ground to the center of rotor axis; if absent, derived from the height, leaving ~0.5 rotor-diameter clearance below the rotor. (Note: the OSM tag is height:hub, not hub:height as one might expect.)min_height — lifts the whole turbine above the ground.colour tag is respected and applied to the whole model — hub, rotor and nacelle.height and/or rotor:diameter are not tagged, but manufacturer and model are (e.g. manufacturer=Enercon + model=E-101), the missing values are inferred from the statisticsSupport for textured flags was added in the previous version, but it quickly became apparent that large, world-famous flagpoles (such as those in Baku or Minsk) did not look convincing enough.
For one thing, their masts are quite thick but taper towards the top. Secondly, the flag itself can reach record-breaking dimensions rather than just average ones.
Consequently, support for a few new tags had to be added.
flag:width and flag:height tags are now supported for man_made=flagpole. When the tags are absent, the flag cloth is scaled non-linearly based on the mast height.shape tag. Supported values are shape=frustum and shape=prism (default).diameter of the pole can also be specified. Remember, it’s in millimeters!Most flags look fine with a 2:3 aspect ratio, but the flags of certain countries have non-standard proportions. In this version, I have hard-coded the aspect ratios for the flags of Switzerland, Nepal, and the Vatican. Support for other ratios, such as 1:2 or 3:5, is a task for the future. If you consider this important, please let me know.
Communication masts (man_made=mast + tower:type=communication) are rendered via a procedural model — a telescopic tube mast with an antenna head on top.
height (and min_height) tags: the body scales to the exact height while keeping proper antenna proportions.colour tag defines the colour for the whole model.roof:direction for roof:shape=saltbox (the asymmetric roof shape).misc data pipeline; internal layout cleanup of roof and street-furniture meshers.The Urban Eye is watching you!
Isn’t this a case of if you have two you could calculate the third:
height - height:hub) * 2 = rotor:diameterheight- (rotor:diameter / 2) = height:hubheight:hub + (rotor:diameter / 2) = heightSo you only need to start deriving stuf when you got only one, right?
Then deriving a value, using the ~66% of the height mentioned for the rotor diameter leads to the following:
rotor:diameter = ~66% of heightheight:hub = height - (~33% of height) or in other words height:hub = ~66% of heightWhich actually comes down to height:hub = rotor:diameter
This would only work if you have height and rotor:diameter, so you could calculate as said above using height:hub = height- (rotor:diameter / 2). But if you use ~0.5 (times) of rotor:diameter as clearance then height:hub = rotor:diameter isn’t it?
@Kees_59 , you are absolutely right.
I start deriving, when I have only one of three. When I have two, the third is just calculated, since obviously height=height:hub + rotor:diameter/2.
height:hub=rotor:diameter
That is also correct. And it gives pretty good classical look:
The code is complex, I just do not know how to describe it better.
If I knew you were taking a second pass at flags I would have suggested this earlier, but better late than never I suppose.
OSM has support for multiple flags on one pole (via semi-colon separation from top to bottom). Currently only the top flag is rendered. It would be wonderful if you were able to support this. Thanks for the awesome plugin!
Well, it’s not a problem to do the third pass
However I need some photo references for those multi-flag flagpoles. The best of all is adding some photos to the wiki page.
In the United States, its very common to have a state flag and the US flag on the same pole. Here’s a picture I found online:
Not sure what the bottom-most flag is, but there’s no hard and fast limit to how many flags can be on the same pole.
No 3 is Greece.
Thanks! I was unaware. A bit rude to put that below even the state flag, but I guess state pride gets the better of us Americans sometimes 
OK, nice. I will include this in the next version, the fix seems to be simple.
However I expect that an image (license appropriate) will be added to the abovementioned wiki page.
I still want to follow documented features
Could be worse. Upside down. There have been many occurences of such displays in the UK recently. Can be fun passing streetlights - right right right wrong wrong right… 
It is documented in the “Multiple Flags” section on that page. I’ll see about adding an image next time I pass by a state house or a post office. Thanks!
Edit: I found a good example on Wikimedia Commons (it was honestly easier than finding one on Google, amusingly…). I’ve added it to the bottom of the page.
Thank you very much!
Code analysis revealed that it will not be that easy to implement as I expected: currently only one texture is allowed per object, but several are needed, but it’s still on the shortlist for the next version.
