In the half a year since we started letting you log in using your OpenStreetMap account, localize map labels into your language, and more, our development team has been busier than ever.
Keeping the lights on
The last couple months have been unusually stressful for @Rub21, who thoughtfully implements the backend features and bug fixes you ask for. As a project on a shoestring budget, we also make him do double duty as our site reliability engineers. Like much larger sites you love, we’re seeing a rise in script kiddies who scrape as much as they can off as many sites as possible in order to feed LLM chatbots.
We can only shrug at their thirst for knowledge. We’re an open data project, so we’d be more than happy to save them the trouble and hand it all to them as one massive database dump, free of charge. But these are brute-force operations that would treat even their friends as adversaries. Lately they’ve gone too far. Multiple times a day, they attempt to send us tens of thousands of requests in a single hour, often in much shorter bursts than that. Multiple times a day, this kills services such as our main site, taginfo, or Overpass, forcing our team to respond at odd hours of the night.
We’re coping. The services usually restart automatically, so you get annoyed as you get logged out multiple times a day, but at least no data gets lost. Unfortunately, all this traffic still drives up the cost of running the servers, which means less money to spend on improving OHM and a less certain future for the project. We’ve tried obvious steps like blocking IP addresses and browser user agents, but they can get around that easily using botnets and user agent spoofing. Sorry if you got caught in our dragnet at times. We’re continuing to look into mitigation strategies. The thing we need most right now is your patience and understanding. Donations couldn’t hurt.
A well-oiled machine
We’re standing on the shoulders of the giant OSM project, which is constantly improving their software. @erictheise has updated our main website and API to incorporate changes to OSM’s website and API as of July and August. This includes niceties like inline Wikidata previews, easier language switching, and more efficient pagination. You can link your profile to your OSM account and social media profiles. There’s a whole lot more, which you can read about on the OSM forum. Merging upstream changes is the bane of any fork’s existence. Your eyes glaze over pretty quickly reading the diffs, and there are thousands more to go. It’s a minor miracle every time we deploy these catchups and things more or less continue to function just fine.
Until recently, anyone submitting a pull request to the ohm-website project would be greeted by hundreds of automated test failures, even if the code submission was impeccable. @erictheise has been whittling away at these test failures, so that it’s easier to catch actual bugs before they go into production. Most of the failures were due to stale translations. If you speak a language besides English, please join our website translation project on Translatewiki.net and review any outdated or untranslated messages. We’ve also started a translation project for the OHM Tasking Manager on Transifex. Besides these projects, you can translate a number of other OSM projects that we’ll deploy for OHM.
We’ve historically relied on Osmosis to generate the daily planet dumps. To improve the database’s stability, @Rub21 has migrated us to planet-dump-ng, the same software that OSM uses for their weekly planet dumps. He has also upgraded the database server to PostgreSQL 17 to further improve performance.
Imperial micromappers and bulk importers will be relieved that OSMCha can load larger changesets than before. @Rub21 had to set up a completely new backend that Jake Low developed for OpenStreetMap U.S.
E-mail notifications were listing the OHM advisory group in the To: field, so some of you inadvertently replied to us instead of whoever you were conversing with. We changed the To: field to a nonexistent address that’ll bounce, so your private conversations will remain private.
Wikimedia 
OHM
You can use your Wikimedia account to log into OHM. To get started, click the Wikipedia icon at the bottom of the login page. Authorize OHM to access your Wikimedia account, provide your e-mail address and a display name that hasn’t been taken yet, and you’re in! After that, you can even log into this forum using the same account.
If you already have an OHM account, go to your settings and set the External Authentication setting to Wikipedia. When you click Save Changes, you’ll be taken to Wikimedia Meta-Wiki to log in and authorize OHM, but you won’t have to reenter an e-mail address or choose a new user name, because the site will automatically link your existing Wikimedia and OHM accounts.
We hope this integration will attract more contributors from Wikipedia, Wikidata, Wikivoyage, and Wikimedia Commons. It’s a small step toward bringing the Wikimedia and OHM communities closer together.
Ancient writing on the wall map
Just like OSM, we avoid favoring one language over another by prioritizing the name of each feature in the local language, and allow other localized names to appear in secondary tags. This distinction is especially relevant when we map the past and present of indigenous peoples, colonized societies, and minority ethnic groups.
Previously, the rendered map would only show names in languages that occur 50 or more times in the database. Otherwise, exposing upwards of 2,000 name:*=* keys would’ve drastically slowed down the map tile generator. Fortunately, @Rub21 found a way to lower this minimum to just five, increasing the total number of exposed languages from less than 150 to more than 400. If you want to see a new language on the map, tag it five times or more with a valid ISO 639 language code, such as name:cst=* for the Ohlone languages. Then wait a day for the tile generator to detect it automatically.
Unlike Ohlone, many of the newly exposed languages are extinct, even ancient languages. Not only are we language-agnostic, but we also avoid favoring one time period over another by prioritizing the name of the feature in the contemporary local language, relegating everything else to secondary tags. In other words, we’re making an accidental map of the history of writing.
Unfortunately, some of the most popular map rendering libraries for the Web only support one seventeenth of the Unicode standard, excluding most obsolete writing systems. Labeling Cairo in hieroglyphs and Babylon in cuneiform is only cool if the hieroglyphs and cuneiform show up on the map. Now if you share an embedded map of OHM, all the text shows up, as long as the required fonts are installed on your device and you opt to label the map in these languages. This upgrade will come to the main site the next time we pull in OSM’s latest software changes.
In case you don’t speak Akkadian, we’re also working on dual language labels, so you can explore the map in a familiar language while simultaneously getting a feel for past writing systems.
Tip
The A文 button in the upper-right corner of the homepage changes the language of not only the interface but also the map labels. However, the language menu only lists languages that the interface is translated into. To view the map in an unsupported language, visithttps://www.openhistoricalmap.org/?locale=xyz, where xyz is an ISO 639 language code.
Style fixes
The official stylesheets have gotten lots of incremental updates, particularly regarding landuse and landcover areas. @Charlie_Plett made his first contribution, enhancing the prominence of military reservations (boundary=military) and military exclusion zones (military=danger_area). @Rub21 made them appear at lower zoom levels, so demilitarized zones are easier to spot. Similarly, @jeffmeyer made airports visible at lower zoom levels. @Rub21 updated the tile generator to expose large landuse areas at lower zoom levels while weeding out the centroid points of smaller areas so they no longer clutter up those zoom levels. He also fixed an issue where a street mapped as a closed highway=* loop appeared as an area even though it lacked an area=yes tag.
@David_Straub made his first contribution, adding an attribution line to all the map styles, so that websites loading the stylesheets directly will link to OHM automatically.
Looking ahead, we’ve started publishing a specialized boundary tileset that represents each boundary relation as a polygon, like it used to be before our performance optimizations earlier this year. None of the official stylesheets use this tileset, but your custom map can use it to fill in a specific territory without sending an expensive query to the Overpass API. Explore this and other OHM tilesets on our Tegola UI instance.
The main Historical tileset has a new route_lines layer that exposes highway, public transportation, and recreational routes in a structured format that will eventually facilitate specialized historical transportation maps.
A new chapter
As we close out 2025, the OHM team would like to thank all of you in the community for hanging in there with us, through good and bad. Your care and fervor keep us going further when it would otherwise be so tempting to accept the status quo.
2026 will bring some changes behind the scenes. For the last eight years or so, @danrademacher and GreenInfo Network have infused this project with innovative features and designs and coordinated help from all over the world whenever we needed it urgently. Dan has moved on to help lead iNaturalist’s product team. We thank him for many years of support and wish him the very best as he devotes his skills to yet another worthy cause.
Going forward, we’ll be leaning on OSMUS a little more, taking advantage of our affiliation to build stronger relationships with their other charter and community projects. (Maybe you’ve noticed some of us have gotten fancy new @openhistoricalmap.org e-mail addresses, courtesy of OSMUS.) Meanwhile, GreenInfo Network will always have a special place in OHM history.
Most things won’t change. @jeffmeyer, @nfgusedautoparts, and I are still your ragtag band of advisors. @erictheise and @Rub21 will continue working on our development priorities. You’ll continue to see us in various communication channels, hopefully for as many happy occasions as scary ones.