CoMaps - Blog

Making CoMaps future-proof: How we are removing technical debt

hello@comaps.app — Fri, 08 May 2026 09:00:00 +0000

Between Maps.Me and Organic Maps, some parts of the CoMaps code are 15 years old and have not been updated recently. For that reason, they continue to use quite old implementations and technologies. This blog post explains some of the different changes that we have done to improve and update the code, to guarantee that we will be able to maintain the project during the next years.

Since beginning of the project, we have regularly worked on these technical aspects of the app, because we are convinced it's an important part to guarantee the continuity of the project: To continue to have an efficient app on most devices, to simplify the maintenance of the project, to reduce bugs on different platforms, to reduce the time required to develop new features, and hopefully also attract more contributors by using more recent technologies.

Some examples of important changes we did for removing the "technical debt" in our codebase:

Swift UI Our iOS app initially used the Objective-C language, but a few years ago Apple introduced Swift as a more efficient and more easy to develop language for the Apple platforms. We have started to switch some parts of our app to this new development language, like the settings view</a>, the OSM profile view</a> or the about view</a>. </li>

Material 3 Our Android app uses a lot of custom styles to define the styles of things like buttons, texts, or progression bars. We have removed most of the custom components to use the components that are available in the Material library and have also simplified the app by reducing the number of styles and themes. And to have a better consistency and a more modern UI, we have switched to Material 3 UI</a>, using our community-chosen color scheme. </li>

Map generator automation To reduce the amount of volunteer time needed, and avoid human errors, we have been working hard to automate all the map generator processes</a>, including downloading data from different sources, generating the map files, and uploading them to our different map delivery servers. We have also done some improvements in our map generation code to reduce the time required to generate the map files</a> and the time required to download map files on your devices</a>. </li>

Elevation chart library For a long time, our Android app used the same library to draw charts, but this library is no longer maintained. To avoid issues with this, and be able to have elevation charts in the app, we have switched</a> to a maintained fork</a> of this library, which still improves the code and uses more modern technologies like the Kotlin language. </li> </ul>
We are also working to switch to other more recent technologies, like viewPager2 for the search view</a> on Android, using the okhttp</code> library to improve our networking</a>, using svg icons or system icons instead of webp icons</a> to improve visual quality and be able to integrate new map features without increasing the app size and improved our build tools to reduce the size of the Desktop app</a>.
Deciding whether to do invisible technical changes or developing a new features is a hard choice, but often the first option is required to be able to develop new features. If you are interested in developing in Swift or Kotlin, or in improving technical parts, join us and lets improve the app together!

3 million daily requests, zero CDN: optimizing CoMaps maps delivery hello@comaps.app — Thu, 23 Apr 2026 09:00:00 +0000 This post by Edoardo Codeglia is licensed under a Creative Commons BY-NC-ND 4.0 License</a> and was first published on unfoxo.it</a> CoMaps is an open-source navigation app that uses OpenStreetMap data as its map base. One of its key strengths is its ability to work entirely offline, either by downloading maps in advance or as you explore. Three screenshots show the different ways users can choose which maps to download.</figcaption> </figure> The app provides compressed and distilled packages of OpenStreetMap data, containing only the information needed for everyday navigation. This way, with just a few gigabytes, maps are always available offline and ready to be searched directly on the device. It is unclear how many active users there are (since there is no tracking or statistics), but providing high-quality maps on such a large scale and, above all, maintaining user privacy is an interesting infrastructural challenge. CoMaps' goal is to shift away from commercial CDNs and run its own network of independent nodes managed directly by the project's volunteers. In this way, traffic would pass exclusively through individuals who are genuinely committed to and aligned with the project's goals, without any intermediaries. Starting from April 2026, unfoxo provides CoMaps with the "comaps-it1" node. Is it actually a CDN?</h2> The goal of a CDN is to bring data as close as possible to the user: data is copied and distributed across multiple nodes that cover many different geographic areas. This way, no matter where the user is located, statistically there will be at least one node close enough to download the data as quickly as possible. Closer nodes also mean lower traffic costs and greater resilience. The purpose of CoMaps' "CDN" is different: each client connects to random nodes and downloads only map regions in compressed format. This makes it almost impossible to determine a specific user's exact location by correlating their requests. Furthermore, since states are divided into very coarse sections rather than "tiles" (the classic "squares" found in other navigation apps), in the worst-case scenario, only a very approximate location of the user can be determined. The architecture of comaps-it1</h2> In a CDN, the HTTP server acts as the intermediary between the user and the data; therefore, it must be efficient and optimized. File system: Bcachefs on SATA SSDs, with NVMe caching</li> Operating system: Alpine Linux</li> Web server: Nginx</li> </ul> For synchronization, the CoMaps team uses SFTP, which has been installed on a separate container with write permissions only for the folder that will then be served by the node. Bcachefs was chosen for its ability to create a two-tier storage system: at the front, NVMe drives excel in speed and handle all writes and reads of the "hottest" data. SATA SSDs, on the other hand, are used as storage for less frequently accessed data, providing the necessary space at a much lower cost and with greater longevity. Alpine Linux was chosen for its lightness and simplicity: it is the operating system on which many Docker images are based, but it also excels as a base operating system and aligns very well with the "old school" approach to server management. The web server is not a critical component: since bandwidth is the limiting factor for this project, any web server would likely have saturated it. In this case, I decided to use nginx due to familiarity and its ability to function both as a static server and as a proxy. Performance Optimization</h2> The server was initially run with default settings and logging enabled in order to establish a baseline. The server, supported by the SSD pool, was still able to saturate the WAN connection through which it was connected. However, opportunities immediately appeared to further optimize the system: a lower load means lower energy consumption, longer component lifespan, and the ability to redirect that load toward other, more important tasks. Pareto's Principle</h2> Anyone who has dealt with large numbers is surely familiar with Pareto's Principle. Statistically, 20% of the causes generate 80% of the effects. This means that if we can identify and optimize the "20%" responsible for our work, we can theoretically achieve "the" 80% increase in performance. So I collected a day's worth of logs. In total, approximately 3 million requests passed through the server. Using a Bash script, we can easily extract only the requests related to maps and sort them by country: ## sed -n 's/.*\/260405\/$[^_.]*$.*/\1/p' access.log | sort | uniq -c | sort -nr | awk '{cnt[NR]=$1; name[NR]=$2; total+=$1; lines=NR} END {for(i=1;i<=lines;i++) printf "%8d %6.2f%% %s\n", cnt[i], (cnt[i]/total)*100, name[i]}' 934949 32.25% France 532499 18.37% Germany 252621 8.71% US 148178 5.11% Italy 98293 3.39% Netherlands 86948 3.00% Spain 61763 2.13% Belgium 57862 2.00% Austria 53080 1.83% Switzerland 51552 1.78% World (* Includes the "general" map and country borders) 50985 1.76% Canada 49935 1.72% UK [... altri stati qui ...] </code></pre> The logs are clear: 80% of the traffic comes from just 12 out of 220 states. In our case, 5% accounts for 80% of the traffic. We can therefore focus on optimizing this small portion to achieve significantly better results. Unused RAM is wasted RAM</h2> Right from the beginning, a system inefficiency became apparent: most requests were reading directly from the disk. While this operation was efficient thanks to the use of SSDs, it would certainly have caused slowdowns if there had been other concurrent workloads. The cause was simple: Linux heavily uses free RAM as a disk cache, and the container dedicated to the web server had only 512MB allocated. Since a large portion of the memory was occupied by the system itself, the server was forced to "discard" the data it had just read without being able to keep it in memory. By giving Linux the right amount of RAM, however, we can ensure it makes the most of it by filling it with the "hottest" data coming from the disk. This "fullness" is actually only apparent, and in fact, the memory used for caching can be freed up immediately if another piece of software needs it. Not everyone is aware of this, and there is even a dedicated website</a> that explains the concept. So, what does the 5% identified earlier correspond to? We can find out by adding up the size of all the stated identified earlier: ## du -ch France_* Germany_* US_* Italy_* Netherlands_* Spain_* Belgium_* Austria_* Switzerland_* World* Canada_* UK_* [...] 38.7G total </code></pre> I therefore allocated about 40 GB of RAM to the web server, so that the system could keep most of those files in memory. Within a few hours, the system reported that it had used 39.3 GB (buff/cache column). ## free -h total used free shared buff/cache available Mem: 125.7G 39.4G 3.0G 1.9G 39.3G 40.3G </code></pre> This caused an immediate drop in disk usage, which fell from an average of 15 MB/s with peaks of 60 MB/s to a steady rate of about 5 MB/s with peaks of 10 MB/s (roughly one-third of the original), with the curve continuing to decline as the algorithm optimized the most frequently accessed files. A drop of 10MB/s in disk usage.</figcaption> </figure> The beneficial effect of the additional RAM is even more evident in the I/O pressure graph, which shows the percentage of time "wasted" waiting for the disks to become available. The drop in I/O pressure stall.</figcaption> </figure> Who needs atime?</h2> Now that we've addressed the issue of frequent reads, there's another factor to consider: frequent writes. Even though reading a file doesn't usually involve any write, its metadata includes the last time it was accessed. This information is updated by the operating system and can be viewed using the stat command: ## stat World.mwm File: World.mwm Size: 53104836 Blocks: 103728 IO Block: 4096 regular file Device: 800h/2048d Inode: 5518608 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ UNKNOWN) Gid: ( 1000/ UNKNOWN) Access: 2026-04-18 10:28:45.836942564 +0000 Modify: 2026-04-06 07:03:48.000000000 +0000 Change: 2026-04-07 07:01:31.892520553 +0000 </code></pre> This means that every time a file is downloaded - even if the file is already in RAM - a small write operation updates that value. This is useful for auditing purposes or to maintain a list of recent files, but in our case, since every file is accessed continuously anyway, it becomes completely meaningless. It's not much traffic, but you can still disable it by adding the noatime or lazyatime mount options. These two options must be added to the /etc/fstab</code> file and have the following effects on access time: noatime</code>: the field is never updated</li> lazyatime</code>: the field is updated only when a modification occurs (which would have triggered a write anyway) or 24 hours after the last update of access time</li> </ul> In my case, I enabled lazyatime</code> across the entire filesystem: an approximate access time can be useful for determining whether certain files are in use or not, and the access logs still allow you to retrieve the exact timestamps if necessary. Those continous writes I had never noticed it before, but all of the web server's write traffic was caused by the access.log</code> file, which was updated with every visit. Each request generated a line, and each line resulted in a write operation to the file. Nginx provides three additional options to add to the logging settings: access_log /var/log/nginx/access.log privacyfmt gzip buffer=32k flush=10m; </code></pre> Here is the effect of each of these: gzip</code>: The entire log is compressed on the fly using gzip (level 1). In my case, 758MB of logs are reduced to 34.4MB (22 times smaller)</li> buffer=32k</code>: Logs will only be written to disk once 32KB of pending logs have accumulated...</li> flush=10m</code>: ... or until 10 minutes have passed since the last write</li> </ul> The only downside to this approach is the possibility of losing up to 10 minutes of logs in the event of a server crash. I have no interest in keeping such granular logs, so I applied these directives globally. Note: In the end, I disabled CoMaps policy logs anyway. Initial logging was done using a format that did not include IP addresses or User-Agents (privacyfmt</code>). Conclusions</h2> Making the node available for CoMaps is not only a way to contribute to an open-source project, but also an opportunity to learn about the challenges posed by specific types of traffic, such as those generated by this app. Despite the significant traffic, the presence of other nodes helps effectively distribute the traffic well below the saturation threshold. Clients are designed to download from as many nodes as possible simultaneously and retry in case of an error. Even if there was a need to limit traffic in the future, the load balancing of the clients would adapt dynamically by spreading the load on other faster nodes. I'm happy to provide this node, and I invite you to contribute even if it's just by downloading the app to try it out and leaving a review. CoMaps is a relatively new project and needs a lot of help on all fronts! This couple is traveling the world with CoMaps hello@comaps.app — Thu, 26 Feb 2026 09:00:00 +0000 Javi is an outdoors enthusiast and a tech expert who's navigation app of choice is CoMaps. He's currently on a sabbatical from his regular job as an engineer, doing what many have only dreamed of doing: traveling the world! Meet Javi: FOSS Advocate, Linux Volunteer, and Bikepacker</h1> Javi and Rebecca</figcaption> </figure> Javi loves bikepacking and all things FOSS (free, open source software). So it makes sense to me that he would choose CoMaps as his navigation app! Javi often speaks at events about Linux and the open source philosophy. He likes to code Linux kernel drivers too. In fact, he's been working on Linux drivers even out on the road using his laptop and Raspberry Pi! Javi also loves the thrill of being outdoors. He loves camping, bikepacking, hiking, and mountain climbing, to name a few. For Javi it's a lifestyle that matches his FOSS ideals of freedom. I have two main passions. The first one is outdoor sports like climbing, mountaineering, trail running, backcountry skiing, hiking, biking... just anything that gives me a feel of freedom and a connection to nature. I believe maintaining a physical and mental balance is crucial to enjoying a full and healthy life. The second one is the Free and Open Source technology, especially anything related to embedded systems and low-level programming.</blockquote> — Javi </div> Traveling the World: From Europe to Oceania!</h1> Right now he's in Oceania, but he didn't start there. Last year Javi and his girlfriend Rebecca planned to bikepack their way into Asia, starting from their home in the Austrian Alps. They had no specific destination in mind, and they've been through plenty of countries (and continents!) already. Cycling through Mongolia</figcaption> </figure> His long journey began on a train from Dornbirn, Austria to Trieste, Italy. From Trieste, he continued east, mostly traveling by bicycle, sometimes taking ferries, buses, trains, and (in rare cases) planes. He has crossed Italy, Slovenia, Croatia, Bosnia and Herzegovina, Montenegro, Albania, Greece, Turkey, Iraq, Iran, Tajikistan, Kyrgyzstan, Kazakhstan, Mongolia, China, and more. Trip Planning and Offline Navigation</h1> Javi says he's used CoMaps since the fork from Organic Maps back in 2025, which was before his sabbatical. He's been using it every day of his cycling trip since. I use CoMaps every single day of the trip, both for planning and also for offline navigation. Actually, it is currently the only app I use for route planning and navigation, and it has safely taken me to many countries in Asia and now in Oceania.</blockquote> — Javi </div> Downloading Maps While Traveling the World</h1> The great thing about CoMaps being offline is you can download maps when you have Internet access, and then use it even when you don't. Javi and Rebecca camp most nights.</figcaption> </figure> I asked Javi if he has any trouble downloading maps while he's traveling the world. He must be in a lot of remote areas most of the time, and he probably hasn't had cell service for most of his trip, so I wondered how that works. He said no, he almost never has any issues. I usually download them when I get WiFi access before entering the country, which is especially important before visiting countries with poor internet access or [other] limitations....</blockquote> — Javi </div> Battery Saving Tips</h1> I asked what he does to save his battery while traveling. Battery management is an important topic for me because I often spend several days cycling in remote regions where I don't have access to electricity.</blockquote> — Javi </div> He also shared these battery saving tips for navigating without electricity for long distances: Keep the phone in airplane/flight mode as much as possible.</li> Turn on battery saver and leave it on.</li> Leave your screen off while traveling; only turn it on when you need to check your directions. ("I usually take a look the day before so I know more or less what the route looks like, and then I don't need to check that often.")</li> Instead of using navigation mode while bikepacking, Javi likes to follow a track manually, which he says saves his battery. ("But if I am in a big city where I need to reach a certain destination, then I use the voice instructions as well [as navigation] so I don't have to look at the screen.")</li> Bring multiple battery packs, and charge them whenever you can. 10,000 mAh or more is best for long trips.</li> Javi uses a 21 Watt solar panel, which helps keep his battery packs, laptop, and Raspberry Pi Zero 2w charged, but not usually 100%.</li> Keep your phone and battery packs warm in cold climates. While hiking or cycling, that means keeping them on you under layers of clothes. Sometimes while camping you may even need to keep them in the sleeping bag with you!</li> </ul> Follow Javi's Journey</h1> Check out his journey at https://hackerbikepacker.com/</a>. He accepts contributions as well if you would like to support him on his journey and so he can continue his work on Linux. In fact he takes a part of any contributions he recieves and passes them on to other FOSS projects, including OpenStreetMap, and CoMaps via Open Collective</a>! Javi riding ahead of Rebecca</figcaption> </figure> OpenStreetMap Volunteers Made This Trip Better</h1> As CoMaps users, Javi and Rebecca have been traveling using map data other people from around the world have built. While other navigation apps have map coverage in many places, OpenStreetMap is often the most accurate in remote places. Because CoMaps uses offline map data from OpenStreetMap, they have been able to travel farther, safer. If you've ever added or corrected OpenStreetMap data in Europe, Asia, or Oceania, you might have helped him along the way! Thank you, Javi, for answering my questions while you're still traveling the world, and for your contributions in the FOSS ecosystem as well! Lots of us have benefitted from your work, I'm sure. Stay safe out there! CoMaps: powered by open source and OpenStreetMap hello@comaps.app — Wed, 21 Jan 2026 10:06:00 -0300 You might have heard that CoMaps is open source, but did you know that when you use CoMaps you're actually using content from a multitude of different open source projects, all powered mostly by volunteers? CoMaps uses OpenStreetMap (OSM) data to build offline map files, combining that data with other open source data projects, including: Wikipedia for offline articles</li> TIGER for additional address data in the US</li> Sonny's Lidar DTM, and also SRTM (Shuttle Radar Topographic Mission) for isolines throughout the world</li> </ul> Having said that, the single biggest source of map data in CoMaps is OpenStreetMap data! Why we use OpenStreetMap and other open source data</h2> Open licensed map data</h3> OpenStreetMap is under the ODbL</a>, which lets anyone freely use, distribute, and adapt the map data. This makes it ideal in two ways for CoMaps to use: We can provide the map data to you without any licensing fees (although servers and volunteer work to run the servers are still required).</li> You can help the larger OpenStreetMap community to improve the map data. This helps all CoMaps users, along with all users of OpenStreetMap.org</a> and all OSM based apps. That's millions of people!</li> </ul> Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License</a>. That means we can provide Wikipedia articles without licensing fees. It also means you can help improve CoMaps data by improving and adding new Wikipedia place articles. Screenshot depicts editing an OpenStreetMap place with CoMaps. Data in screenshot © OpenStreetMap</a> contributors, ODbL</a>.</figcaption> </figure> You can help improve CoMaps by improving OpenStreetMap and other data sources we use</h3> OpenStreetMap is a strong supporter of open source data, and so are we! OSM works primarily through crowd-sourced data, meaning from data it's users create. This means: Data is managed, reviewed, and updated by hundreds of thousands of volunteers, which helps keep the data accurate and impartial.</li> OpenStreetMap data is in many places the most accurate data, as the people who update it usually live near where they contribute OSM data. Think of it like Google's "local guides", but much more hands on.</li> If you see something wrong, you can fix it yourself</a>. You just need an account, an app to make the changes, and some time to learn. (CoMaps is one OSM editor. You can also use iD</a> on the OpenStreetMap website to edit the map.)</li> </ul> There are other projects you can volunteer for to help make CoMaps better too, including: Wikipedia</a> - Improve or create new articles about physical places. Many of these articles get an excerpt on the place inside CoMaps! You can help by signing up at Wikipedia.org</a>.</li> Panoramax</a> - Upload 360° images, or even wide-angle shots, to Panoramax and tag them with the location. Some of your images might get a link on the place in CoMaps, so other users can see the place too! You can help by logging into your OSM account on mapcomplete.org</a> or one of the other Panoramax servers found here</a>.</li> </ul> Screenshot depicts reading a Wikipedia article preview inside CoMaps. Text in screenshot © Wikipedia; CC BY 4.0 License</a></figcaption> </figure> Sharing is caring</h3> Open source data allows us all to work together for our common good. When you help improve something open source, whether it's CoMaps, OpenStreetMap, or something else, you're not just helping yourself, but all other users as well. That's why we, all of us CoMaps volunteers, are hooked on open source! Whether you contribute more for ethical reasons or just as a hobby, open source is quite fun! CoMaps in 2026: Planning for the future hello@comaps.app — Fri, 09 Jan 2026 10:06:00 -0300 After reflecting on our 2025 and what we have achieved so far</a>, we want to also share some updates and plans we have for 2026. During these first months of the project, we found our feet on working together, managing releases and dove into making improvements to the app. In 2026, we will continue with those, but want to put a stronger focus on our long-term sustainability, by tackling some meta-level topics: Formalizing our governance</h2> The governance of CoMaps follows the same core principles that were put in place with the start of the project</a>. By design, those core principles are very abstract and "high-level": Contributors who have privileged access to project-related accounts sign a "trust agreement" to use these for the benefit of the project, but otherwise we have done little further formalization of the governance. This year, we want to improve on these so-far informal processes, to better structure our decision-making processes, define how our voting processes work, etc. Related to this, currently CoMaps is hosted under the Platform 6 Fiscal Host on Open Collective</a>, which handles the transparent management and use of donations for us. As Platform 6 sees themselves as an incubator, we want to find a more long-term solution in 2026, either through another fiscal host or by founding our own non-profit association. If these topics are of interest to you, check out the issues in our Governance repository</a> to join the discussions. Defining our vision and mission</h2> Similar to how our governance structures are currently for a good part implicit between the active contributors, we so far have not written down our shared vision for CoMaps. While we have an implicit assumption of wanting CoMaps to be an easy-to-use, and newcomer-friendly navigation and map application, this level of detail is not necessary enough to really prioritise what to work on and which features might be out-of-scope. This is already becoming relevant now: The CoMaps repository has currently nearly 1,000 open issues. And at times these issues, in particular feature requests, can be at direct conflict with each other. Currently, it is not trivial to decide in these cases. By developing a more detailed vision of what CoMaps wants to be - and importantly also does not want to be, it will be easier to handle feature requests. Of course, developing this vision will be a shared process in an on-going dialogue and it will be created with all of you. Future-proofing the code</h2> As a "fork of a fork", much of the code of CoMaps can look back at a long history, all the way back to 2014 when Maps.me started out. As technology moves on and new toolkits appear, others become deprecated and maintaining it can become challenging. Due to this it becomes to important to ensure that CoMaps "goes with the times" in terms of underlying technologies, to ensure that we can deliver our apps to you for the years to come. Some of this work you might already have noticed, for example the implementation of Android's Material 3 interfaces. In 2026 we will need to work more on these, often invisible, changes to ensure CoMaps remains maintainable. Potential work that fits this, would include refactoring the way http requests in Android are made, to offer a more robust implementation for the traffic feature or overhauling the workflow for map icons, to simplify the integration of new POI types. Improving processes & automation</h2> In 2025, we already did some work on this, but there remains more to be done: Building the maps and apps; and then creating and publishing releases across all the different platforms can at times be a bottleneck. To minimize such bottlenecks, we want to improve our processes and automate them where possible. For example, much of our map generation tooling has already been put into mostly-automated workflows, but there are still parts where we can improve. Ongoing work on features</h2> There is also work on larger features that is ongoing: People are working on decoupling updating the map files from the app, improving the public transport integration, better displaying Panoramax street-level imagery, and even on features to implement optional live traffic data. None of these have concrete release-dates, but will continue to be developed this year. Onboarding developers</h2> In 2025, we grew our community quite a bit. We welcomed people who help with translations, maintaining our website, handling our many community channels, and much more. We also had some people join us in contributing code. But, for our long-term sustainability, we really would like to onboard more developers. For maintaining CoMaps, but also implementing some of those new and larger features, as developer time is at times a limiting factor in moving things forward. Additionally, we are also especially looking for iOS developers who would like to help us increase the feature parity between Android and iOS. So, if you have relevant skills (we use C++, Java, Swift, Objective C, Qt and Python and are happy to help beginners), please join us in making CoMaps the best it can be! How CoMaps focuses on Privacy hello@comaps.app — Mon, 05 Jan 2026 09:00:00 +0000 From the beginning of the project, we have chosen to preserve the privacy of our users. To do so, we have implemented technical changes in our app. Here, we want to share some of those changes that helped improve your privacy: Removing Kayak links</h2> On the first day of the project, as the second pull request</a>, we have decided to remove this feature from the app and our map generator. Instead, we prefer using transparent ways like OpenCollective to collect donations</a> and promote open data over proprietary/closed services. We are glad to see that Organic Maps has also removed Kayak links in their app. Removing the dependency on Google Firebase</h2> The original code used Google Firebase to distribute test builds to users and to test the app via a robot on virtual devices. To reduce our app's dependency on Google and the use of non-free source code, we have removed this dependency</a>. Instead, we now publish our test builds directly on our codeberg repository</a>. Replacing Google Fused Location Services by microG implementation</h2> Initially, we have used the Google Fused Location Services to improve the quality of location signal. The problem is that we don't know how exactly Google uses this data, e.g. if they can follow users movements like is the case on Google Maps. To preserve privacy, we have decided to use the microG implementation, which is an open source solution and disable Google Fused Location Service by default in the app settings</a>, to not potentially track locations without consent. The MicroG implementation can still communicate with Google servers but the code is open source and some options can be disabled in micro G Play Service settings. Rewriting the meta server</h2> As our upstream project, we use a "meta-server", which optimizes which servers or "content delivery networks" (CDN) are used to distribute our maps to your app. The upstream implementation at least historically also uses it to enable features in the app from the server, like replacing the app icon by a Christmas tree during the holidays or import donation URLs from a remote server to ask for donations in-app. To improve our transparency and the security of our app and metaserver, we have instead implemented our own meta server</a>, which is only used to choose the best CDN based on the location of users as determined by their IP address. At the same time, we removed the corresponding functions</a> from the app as well</a>. Lastly, we have also reduced logs recorded by the server. To furthermore remove the reliance on CoMaps, and provide ways to distribute maps in a more private way, the CoMaps android app can now also work without a meta server, by rather specifying a custom server address to get same maps data. in this way, users can even self-host their map servers if they wish. To further improve CoMaps, both around privacy related features but also generally, we are always looking for more people who can help contribute with relevant coding. If that sounds like you, get in touch with us on Zulip</a>. CoMaps and its community at the end of 2025 hello@comaps.app — Tue, 16 Dec 2025 10:06:00 -0300 CoMaps is now about 6 months old and between this and the end of the year, we want to reflect a bit about where we are standing and share some numbers. We also want to give a bit of an outlook what potential plans for the future are. And share how you can support us on this journey! CoMaps started as an idea for a potential fork of Organic Maps earlier this year, with just a rough idea for focusing on a more open, community-based governance model. On June 1st, we released the first preview release</a>, back then only as an Android APK, directly on Codeberg. Since then, 11 more releases have followed and CoMaps is now available in the Google Play Store, F-Droid, and the Apple App Store as well. From the very start, engaging the community in decision making has been a core principle, beginning with picking a name</a> and color scheme</a>. And the voting for our logo took a multi-stage voting approach</a>, in which all designers got extensive intermediate feedback before the final vote. And since then our community has grown further, with ongoing active exchanges in Codeberg issues</a> and discussions on Matrix/Telegram</a>. On the development side of things, the group of CoMaps contributors has grown and was very active: Nearly 1,200 pull requests were merged since the start of the project</a>, improving the code, fixing bugs and building out new features for CoMaps. While we also benefited from most of the contributions made to Organic Maps, over 30 developers contributed to CoMaps directly and that number is growing. Contributing to developing the apps is not the only way of contributing though: Helping with translating CoMaps into different languages</a> is another important effort to help our app serve a larger number of people around the globe. Thanks to the work of nearly 200 contributors who donate their language-skills to contribute translations, CoMaps is available in increasing numbers of languages. Currently, CoMaps is already available in 50 languages – and there are already efforts to bring this number up to 80! Beyond code and translations, there are also volunteers making sure that the word about CoMaps gets out and that we are responsive to questions: For example, by writing blog posts such as this one or by posting regular updates on our social media channels and answering questions on the many different CoMaps communication channels. And, not to forget, by writing both internal and external-facing documentation about processes and how to use CoMaps. On the less visible tech side, CoMaps is only possible thanks to a dedicated technical infrastructure that behind the scenes is responsible for generating the map files as well as distributing them to all of our users. Currently, this includes dedicated servers as well as CDNs</a> around the world which host and distribute the maps, to deliver faster download times. And since a couple of weeks, we got a new dedicated server for the map generation that wrangles all the data from OpenStreetMap, Wikipedia and other data sources like TIGER, SRTM and postcode data. In the past, our map generation could take around 11 days to finish. With the new hardware, we could bring this down to around 2 days, removing a big bottleneck in delivering new maps more often. All of these are great achievements, even more so given this important fact: CoMaps is fully made by volunteers! This starts at organizing community input, continues to the software development, creating the translations, maintaining our infrastructure, and our outreach/communication efforts. This also means we need your help to keep CoMaps running. As shown, there are many ways in which one can contribute to CoMaps to help the project. For some of you, that might mean spending some time to donate your skills to CoMaps. For example, by helping us test upcoming features in test builds, reporting bugs and giving us feedback. Or by spreading the word about CoMaps and answering the questions of users and community members in different places. Maybe you speak another language beyond English? Then we'd love your help with improving our translations. And if you are a software developer, there are always plenty of open issues for fixing bugs and implementing new features that could need a helping hand. Getting involved in any of these can be a daunting task, but the CoMaps community strives to be a friendly and welcoming place and loves to onboard new contributors! And if you are lacking time but have some money, you might also want to consider supporting the project financially, to help us pay some CoMaps related bills. At this point, virtually 100% of donations that we receive go into providing the technical infrastructure we need to run CoMaps in different ways: that includes things like renting the servers that generate and distribute maps. For example, renting the new, much faster map generation server was only possible thanks to the generosity of the people who donate to us. You can contribute your donation via Open Collective</a> or via LiberaPay</a>. Our Open Collective profile also includes the full ledger of how we spend donations</a>, including the LiberaPay donations</a>. No matter how you might contribute, in the past or in the future: Together, we can make sure that CoMaps will continue to improve even more in the upcoming year, as it takes a global village to make a map! Mapping offline with CoMaps and Every Door hello@comaps.app — Thu, 04 Dec 2025 10:06:00 -0300 This blog post was originally published on my blog</a> on November 21, 2025, under a CC BY-SA license. For the first half of November, I've been in Peru to do some hikes close to Cusco with friends: First, we did a 5 day trek to the Inca site of Choquequirao</a> and back. After a day and a half of rest back in Cusco, we then did the 4-day Inca trail to Machu Picchu as well. Of course, I wanted to use those opportunities to do some surveying and mapping for OpenStreetMap</a> (OSM) along the way as well. But there are (at least) two potential issues when doing so during multi-day hikes into at least somewhat remote areas: Having internet connectivity & managing phone battery levels. To give some context about the locations in question: Similar to Machu Picchu, Choquequirao is tucked away on the side of a mountain, surrounded by forests. But unlike its sister site, there is no way to reach that doesn't involve hiking 25 km as first descending and then climbing 1,600 meters (That is one way, you then do the same in reverse to get back). Given this geography, there's very little to no internet connectivity along the way, which makes live-mapping very hard. And while the Inca trail is more touristy, even along it there's ~2 days where there's no connectivity. Furthermore, most of the campgrounds one encounters have limited if any electricity to recharge batteries as well. To nevertheless be able to survey and contribute, I used a mix of strategies: Firstly, as I was recording the actual hiking paths with my Garmin Fenix watch</a>, I got GPX tracks of our routes somewhat as a side effect. On a full charge, and with a bit of integrated solar charging, it can record GPS tracks for ~24 hours. And similarly, by just taking holiday snapshots (as well as some more mindful surveying pictures) along the route using my phone, I created some geolocated reference images too. That left the question of how to more directly contribute to OSM, for which I settled for a combination of CoMaps</a> and Every Door</a>. CoMaps is mainly a map & navigation app that is based on OSM and is available for iOS & Android. It works with maps that are fully offline after the initial download. This in itself was already super useful: While we had guides for our treks, it was super useful to be able to quickly pull out a map to check what a given mountain peak we were seeing was - and even read the associated offline Wikipedia article. Or being able to check the current or remaining elevation. Beyond looking at OSM data, CoMaps also has a (simple) OSM editor, that allows adding & editing points of interest (POI), as well as leaving notes on OSM. And as CoMaps is an offline-first app, it works well offline too: It will queue your edits & notes and keep them safe until you're back online, at which point the data is sent over to OSM. While this approach works well for many common POI, CoMaps is by design limited to more common objects, to keep things simple. To be a bit more flexible, I also wanted to use Every Door, which is a more powerful OSM editor designed specifically for surveying. Until recently, it didn't work super well for pure offline-use, as the background map/satellite layers would not easily cache predictably. Luckily, Every Door 7.x was released in September and has changed this</a>! This version has two changes that make fully working offline very easily possible: Firstly, one can now optionally work with vector tiles instead of just the previous raster tiles, thanks to the new plugin architecture. The vector tiles are significantly smaller, so it's more feasible to have them available offline on a phone for larger regions – which comes at the cost of slower map-rendering speeds. Secondly, the 7.x version of Every Door also allows managing its offline-available data. One can now select areas for which both the OSM data itself and the raster/vector tiles (or even satellite images) should be stored offline. Once downloaded, the background layer and OSM data are persistently stored, allowing browsing the corresponding regions in Every Door without any connectivity. Unlike CoMaps, Every Door does not automatically push changes back to OSM, instead it requires actively pressing the Upload-button. This is nice for prolonged offline-use, as one can then submit one larger changeset, which one can even annotate with hashtags. Now that we have ways to collect and edit data offline on the trail, what about battery life: Given the assumption that there's no connectivity during the trek, the biggest battery saving comes from enabling airplane mode to disable the mobile radios. Otherwise the radios would continuously try to find and connect to cell towers, sucking up the battery. Using the phone otherwise for taking pictures and mapping with CoMaps & Every Door, that alone helped bring down the battery use to around ~30-35% of battery capacity in a hiking day. To further minimize battery use, I just switched off my phone in the evening, only turning it back on the next morning. Both CoMaps and Every Door handle a cold restart perfectly fine without losing the already downloaded/queued data. With that, my phone could easily last 2 days, maybe even a bit more. I carried a power bank to top up my phone every two days, as well as recharging my Garmin watch to continue my GPS recordings too. I didn't have any battery anxiety with this approach, leaving my (20,000 mAh) power bank more than half-full after the 5 days of hiking. Overall, this was my first time trying to do some surveying while hiking in (somewhat) off-the-grid locations that are mostly without internet connectivity and electricity. And I wasn't sure how well it would work, but it turns out CoMaps and Every Door handled contributing in that way really well: Once we came back to a place with stable WiFi, I uploaded all edits via both apps without any issues. And when I arrived back home, I used the GPS Tracks to adjust some paths that I had noticed as being slightly wrong along the way and uploaded some images to Panoramax</a> and Wikimedia Commons</a>. I will definitely continue using this approach for contributing to OSM on my next hikes, and if you plan to go out into nature you can give it a try too, just download the relevant map regions in advance and you're good to go. Happy hiking! A living map of Zion National Park hello@comaps.app — Tue, 21 Oct 2025 10:06:00 -0300 Zion National Park is a huge wasteland, which is what makes it so interesting. The park has peaks thousands of feet high, varying terrain, and a large list of animal species that live there. It's no wonder people flock to Zion National Park every year. It's massive size - 210 square miles, or approximately 350 square kms - makes it a magnet for adventurers every year, but it's also a place where it wouldn't be good to get lost! If you're looking for a map of Zion National Park, consider taking CoMaps along for the fun! Driving Directions to Zion National Park</h2> You probably weren't expecting me to mention getting to Zion National Park in this post, but CoMaps makes a great navigation app. It works offline, so you don't need to keep your data on while driving. Leaving your data on allows other apps to download notifications and such, which will use up your battery before you even get there! Unplug and drive.</li> CoMaps works reliably anywhere in Utah, even if your carrier has dead zones.</li> </ul> All you need to do is download the maps you need before you leave on your adventure, like the map of Zion National Park, and any other maps you'll need to get there. A Map of Zion National Park Hiking Trails</h2> Not only does CoMaps have virtually all the Zion National Park trails you'll want to know about, but it has a walking navigation mode too, so you can get turn-by-turn directions to where you want to go. Just point somewhere on the map and as long as there's a trail CoMaps will find a way to get you there. I do recommend having a printed paper map of Zion National Park, a guidebooklet, and a physical compass with you at all times while you hike at the park. After all, those don't need batteries. On the other hand, here is why you still want CoMaps with you while you're out having fun: With CoMaps you always know where you are on the map.</li> At a glance you can see where some of the roughest peaks are.</li> CoMaps makes it easy to check the distance to other locations on your hike.</li> If you do get stuck, you'll know exactly what your coordinates are so you can phone or radio it in.</li> </ul> Find What You Need Quickly</h2> With CoMaps, you can easily find a place to eat and cool off. Feel like having a burger? Eat at Oscar's Cafe</a>. Want a taco and nachos? Try Sotelo's Mexican Food</a> (or Oscar's Cafe, they have Mexican food too). If Pizza sounds best, go to Zion's Pizza and Noodle Company</a>. Basically, you have the option to search for food offline. Another nice feature of CoMaps is the ability to search for different amenities. If you need to use the bathroom, or your water bottle needs a little extra water, you can search for "bathroom" or "drinking water" on the map to find one nearby. Then just press the "route to" button and you'll know how to get there, and how far away it is from you. Of course, you shouldn't depend only on CoMaps for water in the wilderness, but it is easy to keep track of where amenities are supposed to be at all times. Safety Comes First</h2> While I hope you have a great time exploring Zion National Park, please go prepared. As the National Park Service website says</a>, "Plan ahead and prepare, your safety is your responsibility." If you plan to go out in the wilderness at all, here are a few items to consider bringing: Emergency Navigation: A compass and a paper map of the area (plus CoMaps).</li> Water: At least 1 gallon (approximately 3.7 liters) per person.</li> Clothing: Loose, cool clothing that will protect you from the sun, a hat, and sunscreen.</li> CoMaps: Your phone loaded with a map of the Zion National Park trails, amenities, and more, 1 battery backup, and 1 short charging cable. Be sure to keep that battery backup out of the sun!</li> Survival Gear: A knife, a lighter, a shortwave radio, a small pot in case you need to boil water.</li> </ul> Also, be sure to bring a single piece of chewing gum, a paperclip, and a used roll of duct tape. Why? Because that's what MacGyver would bring. Have fun out there! Improving OpenStreetMap through CoMaps notes hello@comaps.app — Fri, 17 Oct 2025 15:10:00 -0300 CoMaps is only possible thanks to the global, collective efforts of the thousands of contributors to OpenStreetMap. And of course CoMaps also allows its users to contribute to this gigantic effort, by having an editor that allows adding new places as well as editing existing points of interests, amenities and so on. But as editing OpenStreetMap, especially on the go, can be quite a daunting task, the CoMaps editing options have been streamlined to offer limited editing options when compared with dedicated OSM editing tools. Instead, for more complex issues, like adjusting finer details of a shop, changing the category of a place, or deleting it, CoMaps allows people to open "notes" that are accessible to all OSM users. These notes thus contain valuable information, and importantly are mostly designed to be actionable without having someone else do surveying on the ground. And of course, many CoMaps users are also happy to answer question, in case more information is needed. That sounds all great, doesn't it? Indeed, but of course those notes only really help to improve the OSM data - and thus future releases of CoMaps - if they are actually being integrated into the database. And unfortunately, not all notes will be read or acted on. But luckily, you could help us change that! As mentioned above: Most of the notes left by CoMaps users require virtually no local knowledge. For example, if a CoMaps user "surveyed" a place via CoMaps and reported via a note that a POI doesn't exist anymore, then it just requires checking if someone has updated the place in OpenStreetMap after the date the note was written. And if that's not the case, you can adjust the map accordingly and close the note! If this sounds like something you'd like to give a try: NotesReview</a> allows you to find all the open notes around the world that have been opened by fellow CoMaps users! Give it a look a see if there's maybe even some open notes close by to you, or in regions or places you know. Not all notes can easily be solved, but there will be plenty that make for excellent good first issues. And, if you have so far not contributed to OpenStreetMap, those notes can also be a good first step to learn more about how to contribute, and who knows, maybe you will soon find yourself being an active mapper! Improving routing data by correcting 1% of errors hello@comaps.app — Fri, 03 Oct 2025 15:10:00 -0300 The original French version of this was published as an OSM diary entry</a>. How navigation apps take penalties into account</h2> Most navigation apps based on OpenStreetMap data use road signs and road markings (stop signs, traffic lights, speed bumps, pedestrian crossings, traffic islands, etc.) to improve the reliability of route calculations and estimate travel times more accurately. Calculators often take these into account using a penalty system that impacts the route by assigning a default penalty for a given type of object. CoMaps groups the different objects</a> into seven different types</a>, and OSMAnd applies a penalty for each type of object/possible value</a>, which allows for greater precision. To make this approach work, it is necessary to add and update the OpenStreetMap database using ID/JOSM or StreetComplete editors to keep the data up-to-date and accurate. How to contribute</h2> I wanted to contribute to this topic, particularly regarding the keys crossing=*</code> and traffic_calming=*</code>, following the inclusion of penalties in CoMaps, using the Taginfo tool</a>. Taginfo is a superb tool for discovering the richness of OSM (i.e. creation of new keys/values by the community) as well as cleaning and updating rarely used keys/values, as it allows you to view the usage of both the most used values and the least used values. The contributions consisted of correcting the least used values (used less than 10 times) that appeared to be errors. The errors found in the OSM database are: Spelling errors in keys/values (truncated values or values with an extra character) → traffic_calming=bum</code></li> Plural values → traffic_calming=tables</code></li> Incorrect copy-paste → crossing=uncontrolledDon’t tag for the renderer For more details on this topic, see Tagging for the renderer</code>, …</li> Key value in a value → traffic_calming=bicycle=yes</code></li> Values separated by a semicolon with extra spaces or separated by another character → traffic_calming=chicane;␣choker</code></li> Translations of the value in the editor instead of the value → crossing=Only Road Markings</code></li> Value in a language other than English → crossing=лежачий_полицейский</code></li> Value containing an *</code> instead of yes</code> → traffic_calming=*</code></li> </ul> On this point, editing tools bear some responsibility because the checks performed are insufficient. In some cases, a warning could be displayed to alert the user, and autocomplete should avoid suggesting an incorrect value just because we have already entered it. The number of errors of this type remains very low, but they can remain in the database for several years without being corrected. Improvements are certainly possible in data validators such as Osmose, but this remains more complex because validators are designed to handle large numbers of the same type of error (e.g., a deprecated key used several thousand times) and performing checks based on wiki values would be too restrictive and would limit the development of new keys/values. This type of contribution applies to all types of objects in OSM, whether related to routing, rendering, etc., for example with the key traffic_signals=*</code></a>. These contributions are fairly easy and quick to make; I was able to correct a hundred errors in a very short time. Get typing and let's improve OSM together! How I designed the logo for CoMaps - and the lesson it taught me hello@comaps.app — Sat, 06 Sep 2025 15:00:00 +0000 A longer version of this blog post, including more in-between design stages, was originally published on my blog on September 05, 2025</a>. A few months ago, I was looking for a new maps application to replace Mapy.cz on my Android phone, which I had been using for the past few years. In an unexpected chain of events, this ultimately led me to design the official logo for CoMaps, a community-driven fork of Organic Maps. It still blows my mind to see my creation as the logo of an app that thousands of people use every day! This experience not only allowed me to make my first meaningful contribution to an open-source project (which makes me incredibly proud) but it also opened my eyes to the myriad ways individuals can get involved in the open-source world, even without any coding skills. In this post, I will outline the full story, share behind-the-scenes insights, and early drafts from the design process. But let's start from the beginning. How I discovered CoMaps</h2> My requirements for the new maps app were quite simple. It should be: Based on OpenStreetMaps (usually great maps for hiking/exploring)</li> Open-source and privacy-respecting (made by humans for humans)</li> Offline Maps and Navigation (no dependence on connectivity)</li> Easy to use with a smooth UI/UX (I love OsmAnd</a> for it's power features, but I don't like to daily drive it)</li> </ul> Those requirements quickly led me to Organic Maps</a>, a well-regarded staple in the open-source Navigation Space. While the app itself works perfectly fine, I did discover an open letter</a> from long-standing contributors, raising concerns about the project's governance and transparency. Because those concerns were not adequately addressed</a> by the maintainers of Organic Maps, a new fork was created. CoMaps was born. The main goals of this fork are to develop a community-driven, not-for-profit open-source application with maximum transparency and a commitment to community-led decision-making. That sounded promising. Intrigued, I installed the first test release, created a Codeberg</a> account, and joined the discussion. I was welcomed warmly by the highly motivated contributors, and I immediately appreciated the commitment to involve the community in all meaningful decisions. Only days after my first encounter, I was able to participate in the voting process to determine the main color scheme for the app. That was fun and felt meaningful. Over the next weeks, I created my first issues for improvements, bugs, and feature requests in the main CoMaps-Repo and enjoyed the constructive discussion that evolved around them - how cool is that? I can get involved in the development of an app by providing feedback? That's pretty neat. Then I found an issue titled Create project logo - community ideation and iteration</a> and decided to take a look. Following the naming process and decision of the color scheme, a logo was supposed to be the next step in the "branding process" to find the new visual identity of the project. That sounded exciting, so I kept scrolling through the issue, where people were already discussing the first ideas and concepts for the new CoMaps logo. And, well - I got sucked right in. My mind is weird sometimes - I tend to get random sparks of inspiration, which often burn short but bright and result in an unexpected deep dive. Well, this was one of those sparks: I was immediately inspired by the early idea submissions, and my mind started to circle ideas of my own. Which leads us to... The design process</h2> I will structure the design process into sections and share personal insights for each stage, starting from my first concept sketches all the way to the final refined submissions. Please note that, while I do have a light design background - I studied Game Design for a couple of semesters and have regularly dabbled with (digital) art - I am not a "real" (professional) designer by any means. The ideation phase</h3> The first thing I did (after looking through the already posted ideas) was to rip out a sheet of paper from a notebook and scribble down my very first, truly rough concepts. I was just brainstorming ideas that played with the letters "C" and "M" from "CoMaps" and with symbols that I associated with the theme of "Maps" and "Navigation". My first sketches & drafts for the CoMaps-Logo - not pretty, but a solid start to get thinking During that process, I noticed that the name "CoMaps" shares all the same letters with the word "Compass", which was one of my first symbolic associations for a navigation app. And well... I grew quite fond of the idea and started to ideate a lot of drafts based on this concept. The feedback I received on those early drafts led to more drafts exploring different ideas, which all tried to incorporate the (in my opinion) main values + selling points of CoMaps in some way or another: It is a maps/navigation app</li> It is community-driven and open-source</li> </ul> In my mind, a "good" logo should somehow communicate those values, while staying simple, easy to read and recognize, and without relying (too much) on colours so that it can easily be used in many circumstances (e.g., monochrome without a background). So these became my personal "guiding principles" from now on, which resulted in a ton of new concepts. Can you tell that I spend a lot of my evenings on this? Based on additional community feedback, I continued to experiment and add drafts to the discussion. At this "early" stage of finding a design, my philosophy has always been to "get ideas out" so that they can be talked about - it does not matter if they are "good" or pretty - as long as they are created, people will have opinions on them which they wouldn't if the concept did not exist. I find that this approach leads to more insights as it quickly irons out what resonates and what does not. All of this happened in this issue on Codeberg</a>, if you want to take a closer look yourself. In the end, the maintainers of the project organised a first community voting round (June 7, 2025) to narrow down the options to the most popular ones, for which I submitted the following designs: And it turned out, four of my propositions were chosen to advance to the next stage among some lovely ideas from other contributors! Which leads us to the next stage... The refinement phase During this stage, I tried to refine each of my concepts based on community feedback and personal ideas. You can read my longer version of this post to see all the iteration stages</a>. You can also see the different iterations on Codeberg: CO-Arrow</a></li> Windy Roads</a></li> CM-Split</a></li> </ul> The rule for the final voting round stated that only one version of each logo-concept should be submitted, which confronted me with some really tough decisions - especially for the CM-Split-Concept, where I had an especially tough time making a choice! But I somehow managed to choose an option after a long (mental) debate, which finally brings us to... The final voting round</h3> After refining the logos for several weeks (and spending some lovely camping/hiking weekends using CoMaps with friends), it was finally time for the final community decision to determine the new logo of CoMaps. A new issue was created to host the voting, and an initial post explained all the rules for this process. To enable an even playing field, one of the contributors (@yannikbloscheck) had kindly created a unified presentation of all the submissions in different scenarios, including mockups for both iOS and Android. On the 9th of July, the final voting process started with the official announcements on all social channels of the CoMaps-Team. And so the voting began, and with it a new (personal) obsession to impulsively check my phone to take a look at the current state of thumbs-ups - despite all my best efforts to use my phone less ^^ The winning logo</h2> And so the voting began, and with it a new (personal) obsession to impulsively check my phone to take a look at the current state of thumbs-ups - despite all my best efforts to use my phone less ^^ The winning logo After five long days, the results were finally in. The community had made a decision. Meet the new CoMaps-Logo.... Made by me! o.O Yes, roughly three months after my first post in the CoMaps-Project on Codeberg, I had contributed the new logo for the app! I feel incredibly honoured and grateful that my proposition was chosen, from all the great submissions, to represent CoMaps. I want to express a big "thank you" to all the people from the CoMaps Community who supported me along the way with encouraging words and/or valuable feedback. an I also want to thank all the people working on the project and organizing the community for their efforts! It still feels unreal to me to see my logo as an app on my phone screen, on the website, or as the profile picture on Mastodon. I can assure you that this is a truly great feeling! 🌱 I personally view this Logo as a base concept for me or others to build on - I am totally open to refinements/iterations in the future! Everyone can contribute</h2> This has been a crazy experience for me, which has secured a definite spot among my highlight moments of this year! Unexpectedly, it also taught me an important lesson: Contributing to open-source projects isn't limited to writing code. Designers, translators, writers, and testers/users all play crucial roles in the ecosystem. For instance, CoMaps thrives on community involvement in various capacities, from adding locations to OpenStreetMap, over translating text, to providing feedback on features. This sounds so trivial, but for me, this was kind of a revelation, as I had previously shied away from participating in any projects out of my perceived lack of skill. That's not the case - everyone can contribute something, regardless of skill or time constraints. That's why I want to encourage you to get involved yourself! If you have any app/project you like using, look into it and find out what you could contribute. Open-source only works when people get involved! It's people like you and me who decided to offer their skills, time, and energy to the community that make free, privacy-respecting, and open-source software possible. And it's not a one-sided endeavour either. I can assure you that you will get a ton of benefits in return for your efforts: Gratitude and the truly great feeling of working on something "bigger than you"</li> New friendships and connections, as it is quite likely, the people you meet while contributing are nice and share similar interests</li> Free Knowledge - no matter what you do, you will likely learn a lot - from soft-skills like constructive feedback and communication, all the way to technical insights from people who are far more knowledgeable than you. Also, don't underestimate the "learning by doing factor"</li> A "better" software experience for yourself - Contributing allows you to influence the development and shape the tool in a desirable direction</li> Potentially career capital, as many companies (especially in tech) value a portfolio of open-source contributions</li> </ul> How to get started</h3> I don't know about you, but that sounds like a win-win situation to me! So what are you waiting for? Visit the website of an interesting project and look for its get involved section</a>. Most projects will also have some sort of communication space (e.g., Forum, a Telegram or Matrix channel) and their code and assets organized on GitHub or its (arguably better) alternatives like Codeberg, GitLab, etc. Find out what they use and create the necessary accounts to start participating. Oftentimes, they will also have some documentation to help you get started</a>: a code of conduct, good starter issues, or things that need to be done. If you feel lost or don't know where to go, don't be shy - just ask someone and they'll most likely love to help you out! Checklist to get started</h3> To help you get started, here's a short 5-Step Checklist for you to follow: Pick your project (based on your interests)</li> Join the conversation in the forum/chat</li> Find the repo and create an account</li> Read the documentation for new contributors</li> Leave a first constructive comment or ask your first question</li> </ul> And remember, contributions can come in all shapes and sizes - from adding your opinion on an issue, to fixing bugs in the code, translating text, writing documentation, designing things, all the way to moderating the forum/chat. The possibilities are endless, and chances are high that you'll find something that suits you! If you don't want to get your hands dirty, that's of course totally fine too. You can still talk about your preferred projects in your social circle (to spread the word), or consider donating if you have the means and the project accepts that. Anyways - that's it from me. I hope this read was somewhat interesting and entertaining, and more importantly, I hope I successfully convinced you to look into contributing yourself! The open-source community needs all the help it can get - so let's step up, do our part, and have a ton of fun along the way! Oh, I almost forgot... CoMaps has indeed become the Mapy-Replacement I searched for. It is now my main maps/navigation app on my phone. It's free, beautiful, works offline, and best of all, it feels super smooth to use (I love zooming in and out). Sure, it's not perfect (yet), but the community is working on it and I am sure we will get there! Sources - Codeberg Issues</h2> I have made an effort to always link my sources right in the text. For your convenience, I curated this list of relevant Codeberg issues in chronological order. Feel free to dig through the links if you wish to dive even deeper into the whole process! Vote: CoMaps Color Scheme</a></li> Create project logo - community ideation and iteration</a></li> Vote: App Logo (round 1)</a></li> Logo finalist iteration, input, enhancements</a></li> Logo-Refinement: 1 - "CO-Arrow"</a></li> Logo-Refinement: 3 - "Windy-Road-Pin"</a></li> Logo-Refinement: 6 - "CM-Compass-Split"</a></li> Logo-Refinement 4: COmpass</a></li> Vote: App Logo (round 2)</a></li> CoMap's documentation for new contributors</a></li> </ul> Feedback</h2> I hope you enjoyed that long wall of text (and pictures). If yes, I'd love to hear your feedback</a>, as I'm still new to writing blog posts and trying to figure things out :) I would also love to know which design you personally liked most and why! Why I Use CoMaps to Find Hiking Areas Near Me hello@comaps.app — Thu, 04 Sep 2025 18:10:00 -0700 There are many hiking areas near me, which is nice because I like taking hikes out in nature preserves from time to time. Hiking is healthy, helps me feel more in touch with the rest of nature, and get's me away from the screen for a while. Here are some reasons I use CoMaps when hiking, and why you should try CoMaps on your next hiking adventure too! CoMaps has the Most Accurate Hiking Trails</h2> CoMaps gets its map data from the OpenStreetMap</a> project. OpenStreetMap is well known for having many hiking trails, many more than on Google's or Apple's maps. This gives CoMaps a decisive advantage over other apps that don't rely on OSM map data. The data is so good that even paid apps like Komoot use OSM, but unlike those apps, CoMaps is gratis, or free as in beer. CoMaps' Voice Instructions Make it a Better Hiking GPS Solution</h2> Imagine you're out hiking and you get lost in your surroundings. You might have been enjoying the trees or the grass, or feeling the burn in your legs. Maybe you were lost in conversation with a friend, or maybe the mosquitoes were keeping you busy. Whatever the reason, you forgot to check the map, and now you need to backtrack five minutes down the trail. Sound familiar? CoMaps has a voice navigation feature that really helps on hikes. Instead of constantly stopping to check the map, or just ignoring it altogether, CoMaps will announce the turns you've plotted in your hiking route as you come upon them. I like using the voice navigation feature so I don't need to look at the map. Once my hiking route is plotted in, I just need to follow the audible instructions and enjoy the hiking trail. It also saves my battery. CoMaps makes GPS based hiking less painful and more fun. A Good Hiking App Saves Your Battery</h2> Depending on how long you hike and how far in the wilderness you are, it can be extremely important to save your phone battery. CoMaps helps save your phone battery in two ways: First, it works fully offline. Turn off your data, WiFi, and bluetooth to preserve precious battery life on long hikes. This is especially helpful if you have data hungry apps, as the more data your phone transmits, the more power it uses. Second, with voice navigation turned on you can leave your screen off for longer periods of time. As you know, screen time is often the biggest contributor to battery drain. That's why GPS apps are known for draining your battery: they usually keep your screen on for most of the trip. I just choose the hiking trails near me I want to use in CoMaps, and then I don't need to keep the screen on after that. Know More about Your Hiking Trail Ahead of Time</h2> One feature I really like about CoMaps is that it tells you what to expect on your hike. When you plug in your route, it tells you how many miles you'll be hiking, gives a trail elevation profile, and an estimated time to finish the walk*. This has really come in handy since my wife was diagnosed with arthritis in her knee. Now we choose a path that won't exceed a certain number of miles, round trip, and prefer hiking trails that feature hills and varying terrain. * The accuracy of the hiking time estimate depends on the quality of the OSM data, and the calculation is still being improved. Find What You Need on the Hiking Trail</h2> Whether I'm just looking to find benches near me, or I want to hike with water near me, I can find that with CoMaps. When following a hiking path, I just hit the magnifying glass icon, search for water, or whatever else, press the "show on map" button, and results show up near me on the map. I also use CoMaps to find new places to hike, such as nature preserves, parks, and paths. The easiest way to search for a place to hike is type "path" and hit the "show on map" button. If I want a park, I search "park", and zoom the map out a ways to see more parks around me. Detours are Allowed</h2> Sometimes I like to go a little bit further down the trail than I initially planed. Because CoMaps works 100% offline (not including map downloads, which of course requires Internet access), I don't need to worry about loosing cell service while out on a hike. Most apps like Google Maps require cell service to recalculate the route, but with CoMaps, all routing/rerouting happens locally on my phone. In fact I usually just leave my data off for most of my hikes, and CoMaps keeps me on track even if I detour. Find Your Way Back</h2> Another feature of the app is the ability to record your track. I haven't played around with this feature of CoMaps much yet, but if you're ever worried about finding your way back, like to your car, you can turn on this feature at the start of your hike. Then following your path is easy peasy. This would be ideal in cases where you aren't using a dedicated path, such as on a large beach or in a desert. Offline Maps for Better Privacy</h2> Google and Apple doesn't need to know when I decide to exercise, or not exercise! CoMaps is offline and doesn't track what I search for, what parks I view, which parks I favorite, or what trails I take. That means there's nothing for them to leak to hackers, and I am fully in control of my own data. What About You?</h2> Are you using CoMaps for hiking, or have a question that isn't answered by the FAQ</a>? Join me and other users on Telegram</a>, Matrix</a>, or SimpleX</a>! The diversity of OpenStreetMap tools and how they help create a commons hello@comaps.app — Wed, 03 Sep 2025 15:00:00 +0000 This blog post was originally published on my blog on August 11, 2025</a>, under a CC BY-SA license. Last weekend was the 21st birthday of OpenStreetMap</a> (OSM), and with some friends we celebrated the occasion with a little mapping party. Our plan was to combine flying drones to collect aerial imagery</a> and collecting street-level imagery</a> with more traditional field mapping. Due to high winds, we mostly ended up with street-level imagery and doing field mapping though, using a variety of tools. On the way home, I was reflecting on how amazing this richness and diversity of tools for contributing to OSM is. Not just in terms of methods (like collecting imagery, sharing GPS tracks, arm-chair mapping or surveying). But even just within each of these realms: Yesterday we surveyed using Every Door</a>, StreetComplete</a>, MapComplete</a>, and ChatMap</a>, while recording GPS tracks with CoMaps</a>. Before then sitting down with our computers, to make larger edits with iD</a> and JOSM</a>. This wide spectrum of used tools is not (just1</a>) because each of us had different preferences for tools. But also because different tools fill different niches. Even individually, I end up using virtually all of those mentioned tools every single day that I contribute to OSM.2</a> Why? Because each of them excels at particular and different use cases. Every Door is great for surveying when it comes to adding more complex points to the map, things like amenities or shops.3</a> For these objects one realistically wants to add a wide range of information in one go (opening hours, websites, phone numbers, …). StreetComplete is perfect to quickly add missing data to existing objects, at least in part because it tries to gamify OSM contributions. By highlighting different types of "missing" information around one's current location, it's easy to find things that are both simple to verify as simple to add by the click of a button/answering a multiple-choice question (e.g. adding in the type of road surface).4</a> MapComplete is great for adding objects to which one might want to add photos, for example art works or wayside shrines</a>, as long as the objects are already supported.5</a> And CoMaps works great if find yourself without any reception (which would be needed to download the live map) but you found a place where you want to make an edit, as you can look at the offline map and still queue up an edit/note. Similarly, less surveying-based editors like iD and JOSM have their own niches they work well for. The answer to "what is the best editor" thus comes back to the common "it depends on your use case". While at times I've seen people complain about the complexity that comes with a large number of tools, I'd argue that this big diversity in tools is in reality a big asset to enabling contributions to OSM. Not only does it allow people to find a tool that works best for them and their contributing-style, it also facilitates having the right tool for the job. If you think of everything apps or super apps that try combining a lot of software features</a>, their alleged appeal is to have all the functionality you could ever need in one place, but the reality is more often that those tools become bloated, hard to navigate, and calcify as any changes to the structure are infinitely harder given the size and complexity. I often compare this to the Swiss Army Knife: In a pinch, its little screwdrivers, saws, etc. will do their job to fix stuff around the house. But for any larger building project you definitely would like a toolbox with some real screwdrivers and saws.6</a> This is because these individual tools can focus efforts on supporting and implementing comparatively narrow use cases, without having to make extra trade-offs. Of course, the idea of having tools that "do one thing well" isn't new. It's part of the Unix philosophy</a>, alongside the idea that all of these tools should work together with each other. Similarly, how different types of contributions require different tooling reminds the biologist in me of JBS Haldane's On Being the Right Size</a>, which neatly outlines why the shape of organisms plays a big role in the niche they fill. And more recently, there's been a call for malleable software</a>. That is software that can adapt to user needs. And while the authors are skeptical of too specialized software, they highlight interoperability between tools as a big factor, similar to the Unix philosophy.7</a> So why does this approach of having a large diversity of tools work well for OSM, when otherwise we might see trends that go counter to this? I think there's different aspects to it: First of all, there's a clear "interoperable target" - that is a place where people send contributions to: the OSM database. Ultimately it doesn't matter which tooling someone used, the changesets end up in the same place, contributing to the larger project and shared goal. Then there's two other key aspects of peer-produced systems</a>, having a wide range of tasks that are granular and modular.8</a> In other words: There's lots of different types of contributions that one can make to OSM, ranging from very small (e.g. Verifying that a business still exists) to very large (e.g. Adding a whole new neighborhood with streets, buildings etc. to the database). But no matter the size, all of these contributions are valid and help improve the overall database and map. And lastly, there is the elephant in the room: There is no incentive to build a "super/everything app". In the commercial space, the main incentive for building these tools is to keep "your" customers locked up in a closed, proprietary ecosystem. With that, the cost of switching becomes so high that you can maintain a 'captive audience'. But in a digital commons, that is built on cooperation rather than competition, such an approach makes little sense. Especially for tools that are open source for contributing into the commons for the community benefit. It seems that under those combined circumstances, maintaining a diversity of tools works quite well. It provides a pathway for making lots of different contributions by lots of different contributors. And just like it takes a village to raise a child, it takes a global village – with many diverse contributions – to create a map as a by-product of understanding the world</a>. And that's a reason to not only celebrate the birthday of OpenStreetMap, but also the huge diversity of contributors, the ways in which they contribute and the tools they use for that. Footnotes</h3> ^{1 Of course that also plays a role, people do realistically have different preferences or are willing to make different trade-offs with respect to usability. </div>}^2If you look at my contribution history</a>, you can actually see some of that diversity, but as different editors handle how changesets are pushed differently, the raw numbers can be a bit misleading. </div> ^{3 And of course it works equally well to "fully" annotate buildings (addresses, number of floors, color, roof styles, …), as the name suggests. </div>}^{4 It also works great for adding in simple objects, like all the play objects on a playground! </div>}^{5 If an object isn't supported yet, one can write a custom layer like I did for the wayside shrines, but that's slightly more advanced. Either way, images uploaded through MapComplete are automatically linked as an OSM tag and available via their own Panoramax instance. </div>}^{6 In the OSM universe, the OsmAnd map/navigation/editing app is maybe an example of such a Swiss Army Knife: Stuffed with features, it is very powerful and can do a lot of things, but comes close to requiring an advanced degree to really use all of those possibilities. As a result, for many/most use cases (think of doing a simple hike) there will be other, simpler, more specialized tools that will get the job done in a simpler/better way. </div>}^7Thanks to Helge Rausch</a>, who had pointed me towards the article initially and also highlighted the similarity to the Unix philosophy! </div> ^8If you look at page 5 of the preprint</a> you'll find a longer list of characteristics that are found in peer-production. The examples given are from Wikipedia, but are easily translatable to OSM </div>

Why we use OpenStreetMap and other open source data</h2>

Feedback</h2>
I hope you enjoyed that long wall of text (and pictures). If yes, I'd love to hear your feedback</a>, as I'm still new to writing blog posts and trying to figure things out :) I would also love to know which design you personally liked most and why!</p>

What About You?</h2>
Are you using CoMaps for hiking, or have a question that isn't answered by the FAQ</a>? Join me and other users on Telegram</a>, Matrix</a>, or SimpleX</a>!</em></p>

CoMaps - Blog

Making CoMaps future-proof: How we are removing technical debt

3 million daily requests, zero CDN: optimizing CoMaps maps delivery

This couple is traveling the world with CoMaps

CoMaps: powered by open source and OpenStreetMap

CoMaps in 2026: Planning for the future

How CoMaps focuses on Privacy

CoMaps and its community at the end of 2025

Mapping offline with CoMaps and Every Door

A living map of Zion National Park

Improving OpenStreetMap through CoMaps notes

Improving routing data by correcting 1% of errors

How I designed the logo for CoMaps - and the lesson it taught me

Why I Use CoMaps to Find Hiking Areas Near Me

The diversity of OpenStreetMap tools and how they help create a commons

CoMaps - Blog

Making CoMaps future-proof: How we are removing technical debt

3 million daily requests, zero CDN: optimizing CoMaps maps delivery

The architecture of comaps-it1</h2> In a CDN, the HTTP server acts as the intermediary between the user and the data; therefore, it must be efficient and optimized.</p>

This couple is traveling the world with CoMaps

CoMaps: powered by open source and OpenStreetMap

Why we use OpenStreetMap and other open source data</h2>

You can help improve CoMaps by improving OpenStreetMap and other data sources we use</h3> OpenStreetMap is a strong supporter of open source data, and so are we! OSM works primarily through crowd-sourced data, meaning from data it's users create. This means:</p>

CoMaps in 2026: Planning for the future

How CoMaps focuses on Privacy

CoMaps and its community at the end of 2025

Mapping offline with CoMaps and Every Door

A living map of Zion National Park

Driving Directions to Zion National Park</h2> You probably weren't expecting me to mention getting to Zion National Park in this post, but CoMaps makes a great navigation app.</p>

Improving OpenStreetMap through CoMaps notes

Improving routing data by correcting 1% of errors

How I designed the logo for CoMaps - and the lesson it taught me

Checklist to get started</h3> To help you get started, here's a short 5-Step Checklist for you to follow:</p> Pick your project (based on your interests)</li> Join the conversation in the forum/chat</li> Find the repo and create an account</li> Read the documentation for new contributors</li>

Sources - Codeberg Issues</h2> I have made an effort to always link my sources right in the text. For your convenience, I curated this list of relevant Codeberg issues in chronological order. Feel free to dig through the links if you wish to dive even deeper into the whole process!</p>

Why I Use CoMaps to Find Hiking Areas Near Me

The diversity of OpenStreetMap tools and how they help create a commons