OpenStreetMap logins, localized labels, dates everywhere, and more

Hard to believe it’s already been three months since we deployed our big round of performance improvements and more. Since then, the development team has continued to push out periodic improvements to the site, some more noticeable than others. You just haven’t heard about it from me because I’ve been a little busy. I’ve started writing up similar announcements for OpenStreetMap too. Think of those announcements as a preview of things to come in OpenHistoricalMap the next time we update our codebase to match theirs.

OSM :heart: OHM

We hear it all the time from OSM mappers – don’t make me juggle yet another OSM-related account.

Now you can log into openhistoricalmap.org using your existing OSM account. Clicking the OSM logo at the bottom of the login screen takes you to openstreetmap.org. Authorize OHM to access your OSM 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 OpenStreetMap. When you click Save Changes, you’ll be taken to openstreetmap.org 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 OSM and OHM accounts.

With OSM account integration and renderers like OpenRailwayMap combining both projects, there’s never been a better time for history-minded mappers to dip their toes into historical mapping.

Many thanks to OSM developer @mmd for spearheading the effort to bring this feature to OHM!

Not your father’s babel fish

We switched the main map on the homepage to use your preferred language for as many labels as possible. This is more consistent with the embed site and many third-party OHM-based projects, which use localized labels to help their users comprehend the map. After all, there are not too many polyglots in the world and few of them speak all the languages that have ever existed. It’s important for us to see what we’re potentially showing to end users in the languages we do speak.

By default, the map chooses labels from your browser or operating system’s language preference. Logged-in users can adjust this setting: click your user name at the top-right corner of the page, choose My Preferences, click the Edit Preferences button, and set Preferred Languages to a space-separated list of ISO 639 language codes in order from most preferred to least preferred. For example, cy en means Welsh, then English. We’re looking forward to pulling in an enhancement from OSM that would replace this setting with a more user-friendly language menu.

This setting affects the entire user interface along with the main map’s OHM-based Historical, Railway, Woodblock, and Japanese Scroll layers. Any kind of label can be localized – boundaries, buildings, roads, rivers, and points of interest. The OSM-based Standard, CyclOSM, and Humanitarian layers do not respect this preference, since they’re based on raster tile technology that cannot be personalized on the client side.

For now, the map only considers the first language in the list, falling back to the same name=* tag that we always used to use before, but we’re hoping to implement a cascading fallback in the future. If you do want the name=* tag on everything like before, you can set mul (the code for multilingual content) as your preferred language.

All of this map localization is subject to limitations in coverage of keys like name:en=* for English and name:ar=* for Arabic. After we announced vector tile support for language-qualified name tags, we saw usage of some of these keys rise, but there’s still plenty of room for improvement, especially beyond English. For performance reasons, the vector tiles are currently limited to any language-qualified name key that appears 50 or more times in the database. Already, 162 languages meet this threshold, but we’re working to lower this threshold in order to accommodate the hundreds more indigenous and historical languages in our database in which not as many names are known.

Speaking of map labels, we tweaked label priorities in the Historical style to favor a larger country over a smaller city-state whenever the two labels would collide. There’s still some room for improvement, like shifting the labels so they don’t collide with each other in the first place, but the results should be less surprising most of the time.

Mopping up

A couple months ago, you might’ve noticed land going completely missing from our styles. No, this wasn’t a gross overestimate of sea level rise centuries ago. It was fallout from a performance optimization to move landmasses to a less frequently updated set of vector tiles, plus a rework of how we update and deploy the stylesheets. Hopefully the spring floods are over. :crossed_fingers:

A different kind of spill has been surprising some iD users when typing an errant backslash or other syntax error into the Extended Date/Time Format portion of the Start Date or End Date field. iD now suppresses the extra parsing information that you probably didn’t expect to spend your afternoon reading.

In some other cases, iD was incorrectly flagging a Start Date or End Date that falls on the first or last day of the EDTF date range. Some mappers have been accommodating this error by shifting the start or end date by one day. This workaround is no longer necessary.

Now that the date validator is in better shape, help us fix our malformed date tags to ensure that the map and time slider make sense:

Dates everywhere

In historical GIS, start and end dates are crucial to a feature’s identity; mappers and end users need to see a feature’s dates of significance anywhere they see the feature. A year ago, we added date labels to iD, and now we’ve expanded that to the rest of the website and (part of) JOSM (after some configuration).

If you’re still stuffing date ranges in name=* tags, it’s time to start weaning yourself off that practice, which has been deprecated for a couple years now. We need your help to clean up tens of thousands of name=* tags that now result in redundant labels.

Countering recentism

Recentism is an undue focus on recent events at the expense of a more historical perspective. We welcome data about the present, but history doesn’t stop there. Which is why many of you were probably frustrated that the time slider kept stubbornly resetting to the world 100 years ago with the option to slide backward to only 200 years ago. Now you can adjust the date or date range – and the site will remember these settings on your next visit.

We’re still looking for ways to make it more obvious that we cover a wider time period while keeping the slider from getting too coarse. But for those who know, at least you won’t be constantly reminded about the time periods you’re less interested in. Thanks to @Charlie_Plett for posting a clever browser extension that nudged us to make this improvement for everyone. Keep experimenting!

Another way we’re countering recentism is by switching the basemap on OSMCha to an unfiltered OHM basemap. Changesets adding historical data no longer look like vandalism just because the same area looks very different today in reality. If you’re looking at a changeset affecting an area where we didn’t previously have coverage, click the :world_map: button to set the basemap back to Mapbox or Bing imagery like before.

Dotting the t’s, crossing the i’s

We rewrote the About and Copyright pages from top to bottom to better reflect our vision for historical mapping and our best understanding of how you can legally obtain data for OHM or reuse OHM data. This comes with clearer guidance on how to cite OHM, even if you aren’t somehow integrating an interactive slippy map and time slider into your next academic paper.

We wouldn’t be OpenHistoricalMap without open source software. We’ve not only forked many OSM’s open source projects but also built some of our own. For example, we develop a “tiler” that transforms OHM data into vector tiles. Due to an oversight, the Git repository that holds our custom software lacked a license, which meant it was technically proprietary, all rights reserved. Of course, we’d never get on someone’s case just for building great things off the software we’ve written. To avoid any misunderstanding, we applied a permissive license to the repository, so the historical map really is open.

In brief

Whew!

The huge improvements over the past few months are thanks to a small but mighty team of @erictheise @Rub21 @tsinn, plus a new contributor from the community – welcome @Bauer33333! We hope to interest more of you in helping us out, whether it’s reporting bugs and suggesting ideas in our central issue tracker, contributing features to one of our many software projects, or translating our software on Translatewiki.net.

10 Likes

Thank you and the team for all the hardwork. This is the most amazing ambitious project on the internet.

3 Likes

This is a great help in reducing the barrier to adding historical data to OHM.

As somebody who mostly contributes to OSM, but would occasionally add/move historical detail e.g. old railway lines / stations, the current biggest obstacle is configuring JOSM so that I can switch between OSM and OHM.
Is there a guide to maintaining separate “profiles” so you can launch OSM-JOSM and OHM-JOSM? Ideally I’d want to cut and paste between, not least because the I’m confident about the alignment of the OSM data.

1 Like

Welcome to the forum @phodgkin!

I don’t know of a way (outside of a VM!) to switch between the 2 without changing the API and resetting the OAuth token. I’m pretty sure that regardless of how you run JOSM (local install, Java quick start, etc.), it stores the app environment variables in the same place.

In addition, we would caution against copying and pasting from OSM to OHM for a variety of license-related questions well documented/discussed elsewhere on the forum and in our issues tracker.

The idea I like best is authoring initially in OHM and then transferring the data to OSM, which has no issues at all. And, of course, if you’re the original and only editor of the data in OSM, you’re free to move that data from OSM to OHM.

On my computer the api address gets saved in the suggestion list and it seems with OAuth I don’t need to switch accounts, so it’s very easy to switch between OSM and OHM on JOSM.

1 Like

Good to know - I’ll give it a try.

Yes, I’m thinking primarily of historical railway data that I have added to OSM, but which better belongs in OHM.

2 Likes

I use a script under Ubuntu to start JOSM. I also use it to link to the correct profile so I can switch between OSM and OHM

ln -s "$DIR" .josm
1 Like

This was broken for several days due to a mixup in the site configuration, but it’s working again. If you were getting an error about authentication failure when attempting to log in using OSM, try again and it should take you to OSM’s login or authorization screen as expected.

1 Like

If you want to share the map in a particular language, you can use the Share feature to get a URL to embed.openhistoricalmap.org, then append &language= and the language code. Or if you want to share the map in the context of OHM, you can use the openhistoricalmap.org URL you’re looking at and append &locale= and the language code. For example, here’s OHM in Greek.