Absolutely agree. 
2 Likes
As an aside (or perhaps directly related, but expanding to the wider topic of renderers) ANY “good, fast-cycle / quick-turnaround-time renderer” is going to encourage and result in good-to-better development of the underlying data which are rendered in that renderer. This is true for any 3D renderer (they are a “hot topic” right now), but in my direct experience, this is true for OpenCycleMap and cyclosm (bicycle route display renderers) and OpenRailwayMap (rail infrastructure and related tagging, but not passenger rail route renderers, which live in other overlays / renderers, like OpenTransportMap and Transport layer).
In short, when OSM has “the full stack” (of data, which get rendered), “people can see” their data (mapped), so “more people further develop” said data. More comprehensively, and to a great extent, related to the speed / cycle-time of the renderer. This is a basic tenet of digital mapping, even if it isn’t explicitly stated very often (so I state it here).
And yes, I know OSM says “don’t tag for a specific renderer,” and that’s good for us to say, but that doesn’t change this underlying truth of digital mapping, especially when it is crowdsourced as OSM is.
9 Likes
It doesn’t actually say that, it is a common misconception due to unfortunate easily misinterpretable wording that stuck in people heads.
In “Don’t (mis)tag for the renderer” it explains that it is:
bad practice of using incorrect tags (or otherwise skewing the data) for the map features, so that they show up in the mapper’s renderer of choice.
key words being emphasized. There is absolutely no problem adding extra detailed information which is only shown in some renderers and ignored by others – to the contrary that is very welcome (and one might argue actually the whole purpose of the OSM!)
What is however not acceptable is intentionally lying to get rendering results that you like. An example also listed on that page:
For example, if landuse=industrial shows up as a pink area on one of maps, and you have a flowerbed full of pink roses, then tagging your flowerbed as landuse=industrial would be incorrect and must be avoided. Instead, you should accurately tag the flowerbed with the type of plants and improve the renderers so they understand how to show it.
15 Likes
We agree. Thank you for the sharpening of definitions, links and clarifications. Not only I appreciate that you took the time to post this, but I believe others appreciate your post as well.
2 Likes
Where is it discussed? I feel that the current tagging system should be expanded but I feel that only few people are interrested in the topic.
One measure of the popularity of 3D rendering is this topic’s rather high traffic: hundreds of Replies and thousands and thousands of Views.
Not to mention the clearly visually beautiful renderings that we have seen posted earlier here: it is truly eye candy. And for people passionate about OSM (myself, I suspect many others here), it is exciting to see how our often-humble map data can be readily crafted into such beautiful renderings.
20 years from now, Streets GL might look crude. Today, I find it very visually exciting!
1 Like
Please note that I was not being critical. I concur on every point about the how good streetsGL is and am very thankful and admirative for it.
As stated earlier, a few shapes seem to be missing from simple 3D:
The same goes for the half domes or side hipped building for instance. I understand that we don’t want to turn OSM into a CAD software, but there should be a middle way.
Thanks for sharing this post, using PMTiles + Lambda for forwarding + CDN makes sense, I’ll look into it.
I don’t have a laptop with 64GB (!) RAM just lying around, so I don’t think setting up a physical server is an option for me, at least right now.
1 Like
There have been attempts to extend 3D tagging, may be to much. I think, there may be a view tags we could discus and add - in an extra post.
Another idea is to take the idea of “https://3dmr.eu” and add it to WikiMedia, again - in an extra post …
I think I’ve figured out what was causing bad performance on Apple silicon, in particular on my Macbook M2. I had suspicions that it’s related to vertex data but I didn’t see any specific render pass standing out, as if it was a general performance problem.
I’ve found this thread which discusses a performance regression on Metal backend (1496807 - chromium - An open-source project to help move the web forward. - Monorail), so I’ve enabled WEBGL_provoking_vertex extension and it helped. They also suggest using more strict Metal-compatible vertex buffer strides and offsets, but enabling the extension already helped a lot so I’m not going to look into further optimizations for Metal for now.
5 Likes
Amazing!!! 3D rendering is a great way to demonstrate the capabilities of open street map.
1 Like
Actually, on this topic, I found this. Maybe well-known, but it was new to me at least:
https://osmdata.openstreetmap.de/data/water-polygons.html
Recently I see some – few in reality – 3D models (.stl) on Wikimedia Commons Category:STL files of buildings - Wikimedia Commons, and especially the Eiffel Tower (File:EiffelTower fixed.stl - Wikimedia Commons). Today in Streets GL we see this… We surely can do better !
Has anyone thought about integrating 3D .stl models from Wikimedia Commons into StreetGL? (I’m absolutely not technical, I don’t understand much about it.)
1 Like
Not a fan of brutalist architecture, eh?
I’ve tried to integrate these models into a Mapbox GL map before (not Streets GL specifically). It isn’t very challenging, as long as you already have the map’s transform matrix. However, the STL models are designed for 3D printing, not 3D rendering. If you put it on a 3D map, performance will suffer due to the large number of vertices. You’ll also need to make some modifications to the model to match the map. For example, you’d need to reorient this Eiffel Tower model to point upwards instead of sideways, and you might want to also add a bronze texture so it doesn’t appear to be made of concrete.
1 Like
There is also the 3D model repository and the (rarely used) tag 3dmr=.
This diary has more information about its development as part of a Google Summer of Code project.
I don’t know if any renderers use the models from this repository. The Wiki page mentions https://osmgo.org/ but the 3D rendering part is not working for me.
1 Like
Okay thanks for those information !
As I say I’m really not a specialist, so in you opinion which file format is best for OSM ? (and could be rendered in Streets GL !)
Any format is technically fine, it’s the polycount that’s the issue. .obj & .stl are usually used for 3d printing, so they usually aren’t optimised for real-time rendering.
the format we should be using for anything 3d nowadays is GLTF.
see ⚓ T246901 Support full colour 3D models on Wikimedia projects for discussion on better 3d support on Commons
2 Likes
I agree. Given the widespread support, robust specification and openness, glTF is the obvious choice for models intended for 3D rendering.
STL is extremely basic, and even OBJ (which at the time seemed like a good choice for the 3D Model Repository) is now very outdated and lacks support for PBR textures, among other things.
is there a way to have different levels of detail? IMHO this would be necessary for urban scenes so that it remains responsive even with many buildings loaded