It doesn’t do a great job of Fylingdales
but that’s only because the OSM data isn’t great (surprisingly).
1 Like
it seems that the buildings are “eaten” by elevation of the ground sometimes? e.g.
Ah, too bad. I do think that modern devices are quite powerful. However, on my phone, just a white screen was displayed, so… 
1 Like
On my 4-year-old Moto G7 Power (+ Bluetooth mouse), streets.gl appears to run fine once the data initially loads, especially if I disable all the options. Although, the options popup gets cut off on small screens, but this should be an easier fix than full mobile controls.
One oddity is that every building and tree renders ~10 meters above the ground! I dread to think this could be a device-specific rendering bug.
My 2YO laptop takes considerable time loading everything, but in the end the rendering appears.
it seems that the buildings are “eaten” by elevation of the ground sometimes?
Yes, I had a similar problem in the other direction, all buildings hovering significantly above ground.
2 Likes
The wiki says:
Key:building:levels - OpenStreetMap Wiki
However, levels that are part-way underground do count
So that means that the lowest point of buildings should be positioned on the lowest point of the building footprint.
The elevation model is probably off because the building in your example has a large area, so the model thinks there is a little hill there. Maybe those models can be fixed with OpenStreetMap data.
1 Like
I need some feedback regarding a partial solution to the problem with buildings “eaten” by the terrain.
Would it be nicer if buildings without any tags from this list: min_height, est_height, building:levels, building:min_level would get a foundation, like on the screenshot below?
The reason why I chose these tags is that if somebody explicitly specifies building height or its level count than they probably know what they are doing and what these values mean.
And adding this kind of foundation to all buildings would be against the well-established definition of building:levels and height tags.
2 Likes
So first of all: wow, what a nice piece of work! I also like how you made flat roofs coming to life by adding some structure to it, well done!
I noticed 2 things:
-
half_hippedroofs aren’t rendered at all. Actually, if you don’t know a roof-shape, you don’t render the roof at all. Not sure if this is the best choice to make, just wanted to point out that this might be a problem if a 50-story house doesn’t at least have a flat roof - Sometimes, the
roof:orientation=acrossdoesn’t seem to work, haven’t figured out exactly when, though. This gives some odd shapes:
Overall, I’d love to see this project continue and get even better. Really excited!
2 Likes
It’s only implemented for gabled roofs for now.
3 Likes
Just to make it clear, the terrain is totally flat all around there.
That is a good guess as any, the model probably takes average height of some square (which includes both ground level and building tops!) and then tapers them off to neighbouring square. That is unfortunate, as we’d here like just the elevation of the ground, without buildings mixed in.
e.g. this area with skyscrapers seem incorrectly elevated too (in reality, there is no elevation difference whatsoever there, until some km away to the nearest stream; all terrain is flat).
I don’t see a good and easy solution for that problem:
- There might be an option to preprocess the elevation data, and try to subtract OSM building heights to get real ground elevation. Might be the most precise, but hardest to implement.
- Or maybe the raw elevation data of sufficient detail may be acquired, and one could use
min()instead ofavg()on it to get “ground elevation” instead of “average elevation”? - or maybe one can just use more coarse elevation model, which would probably nicely sidestep this problem with burried (or floating?) buildings as it will average all that area as flat and be quite easy to implement (but that workaround has an disadvantage that very small mounds would then not show on the map at all - but they don’t seem to show up anyway, as this anchor is supposed to be on a mound).
Yes, that does look somewhat less broken. Although it still makes one go “huh?” as those made-up mounds and hills do not exist in reality at all.
But that is expected as the problem is in elevation data, and real solution would be having better approximation of ground elevation data, instead of trying to map buildings on nonexistent hills 
The reason why I chose these tags is that if somebody explicitly specifies building height or its level count than they probably know what they are doing and what these values mean.
building:levels=* at least is being added by this StreetComplete quest, so might be quite popular tag (as here).
P.S. very nice looking job anyway!
Next in wishlist is implement some more popular playground equipment and waste baskets; as playgrounds look soo sad with only the benches, picnic tables and fences around 
3 Likes
Maybe i missed reading it here but there’s a new setting in SGL which switches off the terrain elevation function, all land flat as pancake. Then all building pieces fit, no building eating etc. Read github issues and closed items to learn whats on.
3 Likes
Yup, that has been implemented recently. Of course, when toggled, then even really existing elevation changes are not shown, which is kind of a bummer. It does help with debugging!
Read github issues and closed items to learn whats on.
True! This specific issue I’ve noted (elevation changes shown on map where the terrain is completely flat in reality) is being tracked in #46 - Integration of better data source for elevation bitmap.
Today I’ve changed the elevation tileset Streets GL uses to render terrain. Now it’s Esri Terrain 3D, and the data quality is much better across the globe. Hopefully, this is going to resolve most of the issues with terrain elevation.
For example, here’s Sydney. Looks much cleaner now without all these bumps (caused by high-rise buildings):
8 Likes
Sadly the ESRI imagery did not do away with the building eatery and wholesale swallowing of industrial buildings, maybe when surrounding industrial areas are specified, the terrain sloping could be suppressed as seeing the landscape in 3D with it’s undulations really gives the imagery a big kick in ‘experience’.
Anyway, since more and more buildings are covered by solar panels from rain gutter to rain gutter, determined the hex colour from some measurements and inserted that as roof:colour for a building. Can’t miss which 2 have this. Since it really looks ‘true’ to reality have build this into a JOSM custom preset for solar panels mapped as an area. Yes, we tag for ourselves and not for the renderer ;o)))
PS The windows=no now truly works on all building types where specified. A loading dock roof, building middle right, worked too, 5m height and min:height=4.5 m
2 Likes
In my town, it looks like the buildings are floating several metres above the ground. Any idea why? (Safari 16.3.)
This is an alias for window=no. window is better documented and is more widely used, but it seems like some people prefer using windows, so it now works too.
2 Likes
Did it break recently? I only reproduce it in Safari.
Frankly I don’t understand this returning singular opposed to plural in OSM as the nagging continues by a certain QA prog of side v sides (totems at fuel stations are near guaranteed to have 2 for both driving directions e.g.) and resident v residents (access to private streets, parkings, buildings ecc) and tree v trees and so on and so on. Does a building have a window or does it have windows.?
Anyway, steam valved off, thanks for putting that ‘alias’ in 
(And last nights dream was if we could specify which side of a building had a window(s), W/E/N/S.
)
1 Like
This can be done with building:part.