No. You cannot even click on a bakery to open its page. It's a bad Web client for the general public, and the vector style is hidden all below.
Osm.org is the reference website, the one where all data is always up to date and above all, where you edit the map.
But it's not a good OSM client.
Cool; but this is one of those instances where I wish the wonderful and benevolent FOSS developers of the world would consolidate efforts behind existing projects to make fewer better things instead of many never-finished forks. Especially since there is not yet a single open source map ui that is polished enough to compete with enterprise maps.
Agree. In terms of features Organic Maps has never been more than a pale imitation of OsmAnd, only "more ergonomic". The developers admit this themselves. So why couldn't they have just invested their time and energy into making OsmAnd more ergonomic! Ego-fueled duplication of efforts is a real problem in FOSS.
Last I checked, Osmand uses an unconventional map rendered. I would want to contribute to it, it's lagging on so many devices, I can barely use it. Comaps is perfectly smooth.
I'm not saying ego problems don't exist of course. But taking Osmand and making a simple general public app out of this is a huge effort (human and tech), probably more than building a side app.
We at cartes.app have discussed with some people Comaps. We've made links from cartes.app to Comaps, e.g. for navigation, a feature that we don't have.
We've not seen anything from their side. We don't really understand why they wouldn't want a proper Web version.
It's even worse in the non-open source world : Kagi's maps are bad. Qwant dropped their cool map project, too expensive. Ecosia has none, redirects to Google, its main competitor.
They could "just" clone cartes.app and run `bun i && bun start` and `ansible-playbook` to launch their instance of cartes.app, but we can't reach them. Or fund the project.
What's important though is that we collaborate on the tools we all use. OSM, MapLibre, Photon, Pelias, Protomaps, Motis, Brouter, etc. are all tools that we somehow share, each end-user app having their own combination of them.
We also thought like you do when outside of this world. But now, its a human problem. How to reach people and how to gain the time that it would take to collaborate ? We don't have the keys.
Would you consider using cache storage for enabling offline capabilities? Maybe I am in the minority but I usually go to organic maps for offline usage.
Yes it's planned. Should work in theory, but no one tried before.
Maps are so often done as native apps that to my knowledge no one tried to just use the PWA capabilities to cache tiles on the Web. Of course what's hard is cache invalidation. Does the user want to update the tiles ? Never ? Daily, weekly ? Only some regions ? Or manually ?
FWIW, I have an experimental open-source implementation of offline-capable PWA protomaps. Haven't advertised it much, because I haven't sorted out performance (particularly on mobile), and it's a bit buggy still. Also, don't have cache invalidation. But it does work. Usually. xD
I didn't dig too deeply into it, because explicitly storing locally just gives a bit more control. Also, since I was kind of imitating the style of Organic Maps, I wanted to give the ability to download entire tiles. I view caching responses more like a performance enhancement, whereas I wanted explicit offline support.
That makes sens. Both features combined would be cool. In any case, a cache invalidation feature should be always visible to the user, so that he knows that clicking this button will switch to online mode.
We're this on https://cartes.app, trying to push the Web further (even on mobile devices) so that you don't even need an app for most use cases.