During the last few years I’ve been working on putting up an open-source alternative to F4Map and OSMBuildings. So here it is. Streets GL is a web-based 3D map that uses OpenStreetMap data to render features such as buildings, roads, paths, trees, etc. on top of a dynamic terrain. Geometry for tiles is generated in runtime.
Compared to F4Map and OSMBuildings, this project is more focused on the visual aspect of the map. Hence, it implements some purely aesthetic features such as dynamic time of day and complex post-processing effects. As a result, it is not optimized for low-end and mobile devices. Most of the effects can be disabled in settings, though.
The tiles are pulled from public Overpass API instances, so it may take some time for them to load. You can switch between Overpass API endpoints in settings. Also, I’ve cached some areas so that they load much faster, which is (hopefully) a temporary solution to this problem.
The source code is available on GitHub (which also includes a readme with a more detailed description of the project):
Right now, I’m gathering feedback to see if it’s worth continuing to spend time improving this project. And if so, then what aspects/features should I focus on? Any kind of feedback is appreciated. To report bugs, it’s preferable to use GitHub issues.
There is also a Discord server for discussions and posting screenshots.
It would be interesting if you could make it entirely powered from vector tiles (and .png elevation tiles) so that it could be plausibly self-hosted without needing an Overpass instance.
I love that we can immediately see what we mapped. With F4Map and OSMBuildings I never knew when they were upgraded, and if they were but my edit had no effect ecc.
I noticed something different from other renderers tho. I always thought we had to tag only the building:part values that differed from the outline ones because the building:parts inherited the outline tags if not differently stated (so height, building:levels and building:colours at least). So if the building outline was height=10 and one part was height=5, I used to tag one of the building:part=yes with height=5 and the other building:part without height=* at all because I thought it inherited the maximum value from the outline. Seems like it’s not the case with this renderer? So if a big building with the same facade colour is mapped with x building:parts we have to repeat building:colour=* in every single part?
I’m not seeing anything but the ground in the Spokane area. Is that because nothing’s tagged in a way that the renderer can handle, or because I’m trying to do this on a ten-year-old Mac Mini?
Oh yeah, this is certainly on the roadmap. But I’m not really familiar with tools that are out there and can be used to solve this task, so I have no idea how complex it would be to implement a tile generation server. And I can’t really just use any regular vector tile schema. I want to have full control over how tags are processed, I also want to be able to add some additional metadata to each polygon e.g. its oriented minimum bounding box for better texturing. So the tool must be highly customizable.
That’s bad that there’s no widespread tagging to specify if a building has windows.
I already follow the second approach though, several building types have windows disabled (garages, silos, greenhouses, etc.)
That looks amazing! 3D rendering is a great way to demonstrate the capabilities of OSM and it’s great to have an OSS demo. I’m a fan of rendering sidewalks next to roads - a lot of renderers miss this detail.
As a bonus, it loads on my budget phone (even if it’s impossible to pan without connecting a mouse).
And I can’t really just use any regular vector tile schema. I want to have full control over how tags are processed, I also want to be able to add some additional metadata to each polygon e.g. its oriented minimum bounding box for better texturing. So the tool must be highly customizable.
You might like to look at tilemaker (which I maintain!) - it embeds Lua precisely for customisable feature selection and tag transformations. Very happy to help with any advice if needed. But there’s lots of great tools out there.
Very nice indeed!
I would like to know which OSM tags are taken into account and how they modify the appearance of the objects.
E.g. in my street, no sidewalk is shown, the trees completely cover the water, and the houses are flat and only ground level, while in reality they are 3 level with gable roofs!
For anyone not living there it already looks amazing, though. But if I can improve by adding more detail, I would certainly do that. Because everybody always will look at their own vicinity, right?
I think osm2world renders windows only if building:levels is set. @Tordanik
Could you add building=church|service|garages|industrial|digester|storage_tank to the blacklist?
Congratulations on the launch, it looks great and being able to run entirely client-side is a big benefit!
With OSM2World, I’m supporting window=yes/no for that purpose. I think having more software support for it would encourage mappers to use it more frequently.
But yes, it’s not widely used at the moment, so I’m also falling back onto building type heuristics in the absence of explicit tagging.
window=yes/no looks good, though it’s a bit confusing as it seems like this page proposes using the same tag for ways (to specify if a building has windows) and for nodes (to mark them as separate windows). I think I’ve seen this page before, and I’ve got an impression that it only described mapping separate windows. I somehow missed the part about ways. Probably it would be helpful if you mentioned it in the the first paragraph.
I’m going to add support for window=yes/no, but only for ways for now.
I’m not sure about church (most churches seem to have windows) and industrial (this tag is a bit too generic, it’s hard to tell for what kind of buildings people actually use it; and I think that most industrial buildings actually do have windows).
Other ones seem fine, I’ll add them to the list. Currently the function to determine whether to render windows for a building looks like this.
I believe we should have a generic way to distinguish basic facade types, e.g.
perforated facade (“wall with windows”, in German Lochfassade)
There are other types, referring to the construction (structure, how the glass or panels are held in place, water is drained and wind forces are led to the ground), I don’t know the English terms and they are fairly specific:
wie should maybe also have something for “closed”, i.e. a perforated faced without perforations
For perforated facades (and maybe in general) it could be interesting to know the ratio open/total surface.
Btw, Panteon has a lot of windows in this first version
Moved from StreetComplete to OSM Buildings (that never seems to update and has ludicrous and missing building elements), to F4Map, which does show the missing elements and is quick to refresh but not all parts and no windows and now this, Streets GL, oh, ah, ooh, eh, silent. A sample of an greater area I’ve been mapping near ground up, but for to roads and residential area outlines in great detail at a low view angle. The undulation of the landscape and the many calanchi erosion zones against the hills is awesome. The building dome now looking more like a star observatory I’ve just tagged with roof:angle=20 value, roof:height I’ve never understood… from where?. The roof is really maroon coloured and the walls are white plastered. My interpretation is that more goes into the rendition… the farmland at right is really light in the ESRI imagery, on the left still to be cropped and ploughed.
