It is by design that values in building are discarded if any building:part is present. This tells 2D from 3D.
Is this a bug?
The glassy pointed corner of this building (LBBW-Hochhaus in Stuttgart, Germany), which was mapped separately as a building:part, is slightly offset in height. Use terrain elevation data is enabled.
Disable using terrain elevation data and the rendering seems correct.
The original:
1 Like
Each building part is placed on the terrain separately, so they are often not aligned if there’s a slope. There is a way to fix it though. I’m working on vector tiles right now and it’s possible to “group” parts by their outlines in the tile generation stage, but I’m not sure when I’m going to be able to actually implement it.
8 Likes
Just stumbled upon this, Streets GL is one building Way: Agnes-Heller-Haus (524429566) | OpenStreetMap with four parts, all the same colour.
But yeah, it looks realistic and I did not have to wait 
UPDATE: f4 shows the colour specified on the building on all of its parts. The specification is silent on this, but as a mapper, I’d take this for granted. The documentation could be more specific on this?
I think the mapper is responsible to define that, not the render. If the building is in a slope, the mapper must play with building:level, height and min_height to adapt each building:part to the real situation. The OSM wiki defines height as “Distance between the lowest possible position with ground contact and the top of the roof of the building, excluding antennas, spires and other equipment mounted on the roof.”, so my understanding is every other height and min_height must be referencied to that “lowest possible position with ground contact”. In such situation, it does not matter if terrain elevation is used or not, the building is drawn correctly ever. If not, how can I as mapper ensure the roofs of the building parts are aligned?
1 Like
If the building is in a slope, the mapper must play with building:level, height and min_height to adapt each building:part to the real situation.
o yes, and if the floor is inclined you simply split it into infinite parts and it will be perfectly represented.
It would be nicer if we could define slopes and inclined planes (so we can concentrate on representing curved sloped surfaces, like this https://i.pinimg.com/originals/fe/f2/0d/fef20daac8b64bf77da000efeeb02f4f.jpg ), what we generally need IMHO is a tag to define how to blend from one value to the next (assuming we don’t want to split the volume into infinite parts), also useful for 2D mapping (e.g. width on highway). Is it a hard step or a smooth curve from width=8 to width=16? And similarly: is the way curved and the points are arbitrary, or are they corners of an edgy shape? Sometimes it can be guessed from the kind of thing, but being explicit could help fixing all the unexpected exceptions.
1 Like
I agree that building:parts should not be placed on the terrain individually. Because terrain data isn’t part of OSM, that would result in buildings looking different in each renderer depending on what terrain data source that renderer was using. However, it sounds like this behavior in Streets GL is just a technological limitation that will be addressed in the future, not an intentional choice.
(Of course, consistency within a building is only part of the battle. In the future, I’m hoping we’ll be able to better define the elevation of a building relative to adjacent objects and terrain. This has recently come up within the context of indoor mapping, and is obviously also relevant for 3D rendering. But that goes beyond what’s possible with existing tagging standards.)
3 Likes
From now on Streets GL use a custom self-hosted vector tileset instead of Overpass API and Mapbox vector tiles to render the map.
The reason for this change is to improve tile loading speed and put less strain on public Overpass API servers. And also I can’t afford Mapbox API costs.
The biggest downside is that it’s not possible to see the most recent changes on the map. I’m going to update the tileset every week on Saturday or Sunday.
Powerlines are currently not rendered on the map because they don’t work well with vector tiles and need to be reworked. Everything else should be rendered the same.
See the updated Data sources section in README: GitHub - StrandedKitty/streets-gl: 🗺 OpenStreetMap 3D renderer powered by WebGL2
12 Likes
I wonder, is there a way to create vector tiles on the fly from overpass?
That changes made were visible practically immediately has been a big boon of this software, as it somewhat motivates to map all those things in detail. Now, if you have to wait up to a week + time until the cache is refreshed for the changes to show up, part of this excitement will be gone.
Now that all the logic that translates OSM tags to properties for rendering is in the backend code (as far as I understand it), the only way to bring that back would be a mode where vector tiles are generated directly from the response of an overpass query on the fly.
8 Likes
hmmm, weird is, yesterday I did some buildings adjustments, checked, showing exactly as intended, and now they show as prior to the correction applied such as missing levels. E.g this one that did/does not understand crosspitched and showed a flat roof_tiles roof. It’s utterly flat again with an flickering effect when viewing in the browser.
Absolutely distraught about Crtl P having gone out the window. Guess it’s back to F4 for some near immediate feedback, with a fallback of crosspitched to gabled, but height is right
:o(
1 Like
Agree, red arrow is the announcement of the release of Streets GL for building:part=* usage:
Watching the rendering after one minute was a big help, it was nice while it lasted 
7 Likes
If I’m not mistaken, the switch to vector tiles was not so much about the vector tile format as it was about avoiding wasteful calls to the Overpass API to download practically everything in the current viewport.
Essentially, folks have been using Streets GL as part of an editing workflow, as an alternative to something like Kenzi3D. That use case could be supported by something like minutely-updating vector tiles. That would be nice, but it might be overkill: making direct calls to the OSM API, like ordinary editors do, would place less of a burden on the server side. Active mappers could opt into this more intensive mechanism, while everyone else who’s just browsing the map can get the vector tiles.
3 Likes
Yeah, I understand. However, if this has actually been a problem, maybe there could be some button with which to switch to current data. I.e. people that just want to look at the map won’t use that button, people who just mapped 3D things and want to see how it looks now could switch to that mode.
12 Likes
From now on Streets GL use a custom self-hosted vector tileset instead
of Overpass API and Mapbox vector tiles to render the map.
The reason for this change is to improve tile loading speed and put less
strain on public Overpass API servers.
Streets GL has at any time been a good citizen user for Overpass API. By
licky coincidence, we have changed over to faster servers in February,
so at the moment in particular the servers are mostly idle.
Problems in general have come and still come from users as explained
here.
Streets GL never has followed such a pattern or an in any regard similar
pattern.
9 Likes
Would it be possible/practical to generate a more limited rendering of buildings (only?) using a local .osm file from the user’s own computer?
I’m probably not alone in having only really started to pay attention to 3D rendering tags beyond building:levels as a result of streets.gl. I’m still very new to it and it would be nice to fix my mistakes before hitting upload in JOSM.
4 Likes
I’m using OSM2world for this.
4 Likes
Tried to load Kenzi3D in past but it would be rejected by JOSM and still is, BUT, gave the dev version a go now which passed. Excellent, now have the 3D option on the menu. Takes some getting used to in navigating and camera positioning and aiming, but the result is instant on a building which just had yes, added levels and roof shape, material and got this out
The roof tiles look hunky dory up close. Experimenting, get the picture and when satisfied, send to OSM, yes tagging for user. Building colours it did not like, hex or html, walls disappear, so something to ignore, a true see through house, but plaster and brick as material did give a rendition. Levels is curious as a 1 level building has a roof on the ground, a 1 level building w/ 1 level roof is fine, more to ignore… Needs lots more play.
/OT
Thanks! I’ve just installed OSM2World and it looks ideal for the purpose.
It’s been mentioned that Streets GL now uses manually-updated vector tiles instead of real-time Overpass queries. However, the option to configure Overpass API endpoints still exists. Is it possible to re-enable their use as a user? Otherwise, are they even used for anything?
As mentioned above, being able to see your changes soon after you make them was a key feature of Streets GL for editors, so it would be great if this functionality is made available one way or another.
4 Likes