CoMaps: New OSM based navigation app(comaps.app) |
CoMaps: New OSM based navigation app(comaps.app) |
> The main code repository of CoMaps, a community-led fork of Organic Maps. Reinforced with commitment to transparency, privacy and being not-for-profit.
A community-led fork of Organic Maps - https://news.ycombinator.com/item?id=43961908 - May 2025 (206 comments)
That said, if you're just looking for a simple maps app, I suppose OsmAnd could be quite overwhelming and this would probably be a lot better.
I never really got what the Organic Maps drama was about, but as long as the two can peacefully coexist I hope they'll work together to make their apps as good as they can be.
That's the main draw of CoMaps to me. I also have OsmAnd installed and it's useful for more complex uses, but for a quick lookup CoMaps works a lot better for me. OsmAnd is more the swiss army knife of navigation tools, with all the complexity that means.
OpenStreetMap doesn't even seem interested in things like "this street is closed next week Tuesday", but maybe there's another open project that collects this information for maps apps. I don't know any, though.
A question: given that common pattern of forks of this codebase over time which seem to have a common theme of confused/transferred/disputed ownership, are there plans for an actual neutral foundation (or joining an existing one) or some governance which will guarantee that this avoids those problems?
From the outside it's getting embarrassing constantly telling my friends and family "actually you need to install this new fork instead" for the fourth time. I've seen norming in the wild with maps.me or MapsWithMe installed on their phones in the past, and I can't believe that they're following along the journey and we really can't go though this again.
E.g., on iOS CoMaps has fixed several bugs present in OM like: * CarPlay Interface not resetting upon arrival at destination * Search Results still highlighted after route creation * Button overlaying during routing on small iPhone
I have improved the consistency of paths and footway rendering
- added automatic backups for bookmarks and tracks
- added 100m-step altitude isolines to all regions that had worse or no isolines
- a big rework of the map colors - lighter, warmer, friendlier
- add a setting to customize the leftmost button or hide it
- removed semi-transparent background in Subway layer
And there is a bunch of smaller changes, for details check the release notes: https://codeberg.org/comaps/comaps/releases
I.e. is it that Organic Maps just have different priorities than you do? Or is it that Organic Maps have been holding back these good features for no good reason?
And yes, amount of work done on OM has reduced significantly, as many contribturos have moved to CoMaps.
Still, features-wise priorities of both projects are quite similar. E.g. being easy to use and simple , offline-focused, etc.
I would say CoMaps is a bit more serious about privacy and is also more open to customization by users (to a reasonable extent).
As CoMaps is a community-driven project then it's possible that with time the growing community would change the direction of the project somewhat.
But the biggest differences that actually were the reason for forking - are in the way the project is run - CoMaps is truly community-driven, open and transparent, which includes project's finances and decision-making.
But make sure that the app is installed from Google Play. Google prohibits use of navigation apps in AA from other sources.
It happens because they don't apply any movement filters/momentum to the navigation, which means that the navigation marker jerks from one GPS update to the other and is constantly behind the actual location of the vehicle. Which makes it extremely easy to miss a turn.
The authors of Organic keep rejecting implementation of a filter/momentum (just like any other nav app) with "it's less accurate"... which is kind of ridiculous if you think about it.
They should take your velocity vector into account, or something along those lines, to minimize rotations, even when not following a route. It just leads to a ton of unnecessary screen redraws and jerky movement.
Furthermore, as I've been driving in a region with a lot of tunnels, I wish they implemented a better system for when you pass through one while following a route. It animated the arrow for a bit but then stops and only jumps forward when you get out. I wish it would keep going with a speed based on your entry speed (and maybe the tunnel's speed limit, if available), taking the routed exit if there are any forks inside. This would make the happy path much better and would not really worsen accuracy, since it isn't accurate in any way as is right now. You could tweak the arrow's color/shape to indicate it is showing a predicted route.
You can fix those aspects yourself in OpenStreetMap (OSM), with the result that once your updates flow into the routers/apps that use OSM (OsmAnd, maps.me, etc.) that those tools should stop attempting to route you over those roads.
For bus lanes, I just checked and they're all correctly marked in my city. Seems they are missing in yours, sadly.
Fortunately OSM can be edited by users. Updating the lanes in your city is something you can do. I'm not saying it's easy, just that it's possible.
Original letter regarding the dispute with Organic Map is here: https://openletter.earth/open-letter-to-organic-maps-shareho...
https://openletter.earth/open-letter-to-organic-maps-shareho...
But if your question is more about app features, then see my reply here: https://news.ycombinator.com/item?id=44455300
The official company reporting source is https://ariregister.rik.ee/eng/company/16225385/Organic-Maps... . Yearly PDF reports are in Estonian language, but your favorite AI should help. The numbers are in actual EUR (not housands), so they seem to have 33KEUR profits, IMHO no huge piles of money to worry too much for.
OpenStreetMap data consumers can have much longer update cycles than "next week", so it makes sense to have such information outside of the map data if you are implementing a router.
That seems pretty normal, there's lots of this around Europe. Apparently overlooked by navi/maps designers overall.
Maybe the bug you're seeing is this? https://codeberg.org/comaps/comaps/issues/510