I’ve encountered an OpenStreetMap link to an https://www.openstreetmap.org/export/embed.html?... sub page that showed me this message:
We are sorry, but it seems that your browser does not support WebGL, a technology for rendering 3D graphics on the web.
WebGL is required to display this map.
Read more
This seems bad because:
I assume this is a 2D map link. If yes, it doesn’t seem quite convincing there would be an inherent technical reason why it would be impossible to render that without 3D acceleration.
There are so many reasons to disable WebGL on purpose, e.g. security. LibreWolf requires opt-in for WebGL for that reason. 3D drivers are notorious for undiscovered security holes and problems with the security enforcement.
Some devices may not have 3D acceleration drivers available.
I understand the community may just have other things to do that seem more important. Nevertheless, I hope some day, somebody finds the time and motivation and interest to improve this in the future. Perhaps this post can spark some interest!
The future of map rendering is in the browser for a multitude of reasons like Internationalisations, rotation, user side filtering, speed just to name a few.
Thats an off topic discussion here - The world has moved there and OSM is just to follow. OSM is working on that for some years now. Rendering in the browser is using WebGL everywhere.
My guess is that OSM will for the foreseeable future always offer the fallback to png based tile maps. We are not even there yet to make the vector tiles the default.
I have no clue how you got to that link. The /export tells me that you tried to export vector data for the view you saw.
I have WebGL disabled and you’d be surprised how rarely it makes any difference. It might be common as an option, but as an unavoidable requirement it’s actually extremely rare. (Outside of web games of course, but I don’t really play those.)
Ultimately this boils down to development effort required to support the non-WebGL interfaces. It’s technically feasible, just a matter of someone doing it in a maintainable way for the ~1% of users with WebGL off.
Because of the maintenance cost of keeping osm.org code supporting both WebGL (for the vector layers, so you can zoom like you wanted) and non-WebGL (for the reasons you specified), I would suggest that a privacy-and-security-conscious non-WebGL version would actually be easier to serve from a separate server and app, not from the main osm.org site: a separate web page, for now using the existing raster tiles (with proper attribution), in the future perhaps serving your own tiles if the raster tileservers ever get turned off on osm.org.
I couldn’t tell you what should be best served from where, but it should be such that whenever something links OSM in one of the common ways, it should still work when WebGL is off. If that is done via a redirect then I don’t mind.
Google maps works fine without it edit: even for embeds, which seems to be a similar use case to what I’ve encountered here. edit 2: sorry that this came across as abrasive. The reason I brought this up is that things “will increasingly require WebGL” doesn’t necessarily seem to hold true in the maps space as a whole, for now.
I imagine unless you’re a OSM developer, and I apologize if you are, neither you nor my opinion are directly relevant. I simply wanted to leave the info here that it might be worth fixing.
My opinion is indeed not particularly relevant, but what I’m trying to share with you is less my opinion and more some of the actual reasons as to why maps are being migrated to require WebGL. It’s because of the maintenance cost vs the benefit. You can see that discussion playing out in the Github issues I linked above.
You are free to try “fixing” it yourself. Or run your own page. It’s not actually very hard, it’s just HTML, read the quickstart on the Leaflet website and you’ll be most of the way there.
Until you do, my opinion is that it’s a particularly bad look when someone apparently not interested in actually doing the work says “well Google can do it”.
It absolutely does hold true. No one is investing significant development in server-side rendering these days. Pretty much all the effort is going into client-side rendering, and in the browser, that largely means WebGL.
Google Maps has a userbase of billions and is very aggressively monetised. That means they have a tolerable ROI for retaining a legacy server-side renderer. openstreetmap.org is not a consumer-facing mapping site, is mostly developed by unpaid volunteers, does not have a userbase of billions, and is not at all monetised. The equation is different.
Whether this particular page on osm.org requires WebGL for genuine reasons (for which “developer time” is absolutely a genuine reason), or just as an unintentional side-effect of a recent migration on a little-used page, I couldn’t tell you.
But if you are interested in helping fix this, then here’s the osm.org issue tracker which is where enhancements to the code should be aired. I would, however, advise drafting better steps to reproduce than “linked on some web page of some doctor’s practice”.
The only thing I’d add here is that the OSM website is primarily intended for mappers. For better or worse, end users have historically been a lower priority. LibreWolf disables WebGL by default due to fingerprinting risk, but in the course of mapping, there are much greater fingerprinting risks, which we hope can be mitigated somewhat by the fact that mappers are familiar with OSM and trust OSM. Casual new contributors are an exception, but so far we aren’t seeing non-WebGL users as a significant source of new contributors. If this changes, we can reevaluate our choices.
The embed page is a different story. It gets presented to end users who have no relationship to OSM. Typically the webpage’s author has used the Share function on our homepage to obtain the code for it. We offer the sharing options as a convenient shortcut, but the functionality is deliberately limited compared to what even the most basic quick start guides offer for libraries such as Leaflet. By the way, our default sharing option is a static image, which requires no special software to display on a webpage. This might be a suitable option for a simple locator map on a shop’s website or a blog post. It would be more reasonable to request an enhancement such as compositing a marker onto the image, like the overlay that appears in the embed page.
I don’t think that’s really true - the top option on the shard panel is to get a URL to openstreemap.org or the HTML embed fragment.
I believe the only static image option is the mapnik image export at the bottom of the share panel which I wouldn’t generally recommend anybody to use as it’s a one shot export.
edit: even for embeds, which seems to be a similar use case to what I’ve encountered here. edit 2: sorry that this came across as abrasive. The reason I brought this up is that things “will increasingly require WebGL” doesn’t necessarily seem to hold true in the maps space as a whole, for now.