Ring in the new year with rails, dates, and more!

OpenHistoricalMap’s development team has been hard at work over the past month to bring you some long-planned improvements to viewing and editing the map. These changes are live starting today. Here are some of the most noticeable changes:

Rails are back on the map

The Historic style has been revised in response to your feedback. Through railroad tracks have regained some of the prominence they lost in the November update, while yard tracks and and sidings remain deemphasized.

Fainter yard tracks beside more prominent railroad tracks.

Another regression from November, invisible highway=tertiary_link roadways, has been fixed.

Date editing for humans

If, like me, you rely on iD for editing the map, you’ll quickly notice some quality-of-life improvements related to managing dates.

The all-important Start Date and End Date fields used to be plain text fields that expected you to know ISO 8601 syntax. Easy enough, but when’s the last time you remembered that 1000 BCE is supposed to be -0999 in this syntax (because there’s no year zero)? Now the field sports more structured date component fields, so you no longer have to offset BCE years or remember that December is the twelfth month of the year.

Even when it’s complicated

To the right of the Start Date and End Date fields, you can press a :heavy_plus_sign: button to reveal an Extended Date/Time Format field. This is how you elaborate on the machine-readable date, in case the date is uncertain or approximate, or your source only gives a season or quarter, or you happen to know the time at which a tree is planted right down to the millisecond.

One syntax to forget, another one to remember. :persevere: Hopefully we can come up with a more intuitive interface for entering EDTF dates in the future. In the meantime, a validation rule catches any invalid EDTF dates you enter or any that contradict the machine-readable dates in the main Start Date and End Date fields:

Speaking of the validator, another new rule detects several common OpenStreetMap date format patterns and offers to convert them to EDTF. This will make it a lot easier to clean up the streets of Columbus, Ohio:

(If you’ve seen these suggested fixes on date-related validation errors before, you’ve probably been frustrated that they do nothing except trigger a JavaScript error. We fixed that too.)

Dates everywhere

Start and end dates are not only visible while editing a feature but also while browsing the map in iD, reviewing issues, or selecting relations. This makes it more convenient to manage the many copies of a feature that tend to result when mapping a frequently changing structure or a recurring event:

Find the OHM community

iD’s post-save screen now lists some ways to connect with the OpenHistoricalMap community more specifically, including this forum:

MapLibre inside

We’ve upgraded the slippy map on the homepage from an ancient, unsupported version of Mapbox GL JS to the latest version of MapLibre GL JS. You shouldn’t notice any difference yet, but this will allow future style updates to incorporate bug fixes and features developed as open source software by the MapLibre project. Eventually, we hope to remove the Leaflet-based compatibility shim, so the map will feel smoother and faster – like a real vector map.

Find changesets in OSMCha

OSMCha is a crucial tool for the OSM community to review and visualize changesets. Now we have our own OSMCha instance for OHM. Some functionality isn’t quite working yet, like the map and the list of changes in a changeset, but some filters are working, and you can rate changesets as good or bad.

Hey, you too!

These improvements have been a team effort, especially in the process to get them deployed. Much thanks to @danrademacher, Eric Theise, @Rub21, Sanjay Bhangar, @vanessa_GIN, @wille, and anyone I missed for your help this time around.

Changes like these are possible because folks like you use OHM frequently and let us know what you like and don’t like about the experience. Supporting a project as ambitious as OHM requires a lot of attention to detail, but we’re a very small team and could use any help we can get. Please pitch in with your ideas and pull requests and mention OHM to any tech-savvy friends who might be interested in bringing OSM software to new fields of endeavor.

In 2024, enjoy an increasingly more livable OHM!


This is great!
Thank you team for all the fine work you do.

Re: dates
Love the presence of [date] everywhere in iD and the easy addition of edtf. Makes life much easier.
Minor quibble is that I used to be able to copy/paste the date and now can’t (although I am increasingly using raw format to duplicate data anyway). Also, month-day-year is largely only standard in the US :slight_smile: (perhaps it’s possible make localilised preference setting?)

Re: railways
Does it take time for this change to propagate? The distinction between usage=main and usage=industrial is not evident where I am editing: OpenHistoricalMap

(the dual lines are main, the unnamed line is industrial)

Cheers, Andrew

PS all the best for the new year

1 Like

The order should automatically switch based on your browser or operating system’s locale, which you can override in user preferences.

If I’m not mistaken, the latest style update only factors in the service=* tag, not usage=* yet. Here’s the main issue about exposing more rail-centric keys in the vector tiles:

1 Like

Hi Minh,
Okay, I changed the language preference to en-AU (Australia, where I live), en-UK, and en-CA and these all appear as MDY. Setting to language of es changed it to DMY.

In the hocus pocus sandbox area the railway styles correctly render and only main=* tags appear on those lines. I’m no railway guru but service=* seems to be only used for spur, yard, crossover.


1 Like

Ah, it’s discarding the region part of the locale code. This will fix it hopefully the next time we deploy a new release:

1 Like

Changeset visualization is working now:

1 Like

Hey @Minh_Nguyen
I’ve tracked down the reason ‘main’ railway lines aren’t rendering correctly.

The tag usage=main is the correct way to designate main train lines. However the correct rendering of the main line with more prominent features only seems to work when the tag ‘name=usage=main’ is also included.

Example, the only difference in tagging between the two lines shown here (at top left) at OpenHistoricalMap is the presence of the name tag:



1 Like

Thanks for investigating! Let’s track the issue on GitHub:

1 Like