Consensus about dates


I found a big problem in OHM: the dates.

What the documentation says

In fact, when we check the wiki for know how tag the value changements of a key, we found this page: Comparison of life cycle concepts - OpenStreetMap Wiki

This page proposes some way to do, but doesn’t say explicitly wich one should be used.
So, I tried some of them (for exemple on this way), but it doesn’t appear on the map.

I think this subject is necessary to clarify in order to harmonize the way to map, and the possibilities to reuse the datas.

What's working

Actually, the tags whose working with the map are end_date= and start_date=. But the problems for these tags are that they define the strat-date and the end-date of the totality of the object, however, we need some tags for tag each small change of the object. The most currency exemple is the name of the objects, wich cans change many times. But this is valid too for each tag of a object.

An exemple of the size of the problem

Here is an exemple:
This objet is a French railway. During his “life”, it knew a lot of changes:

  • around 6 different signallings
  • around 10 differents maxspeed
  • a different number of track
  • a different type of electrification
  • a different loading gauge
  • differents ref

So, for me, it’s urgent to clarify the situation.

Personnal proposal

Datespec concept


Personally, I think that the keyname:DATESPEC= concept is the more advanced and clear one, because it permit to precise every different tags and changements.


Uncertain date

However, I think it’s necessary to develop the concept for map objects with an uncertain date, like something where we know a century of beginning, but no more precise.
For exemple, we could tag the start date of an road created in the 3rd century like that: highway:02xx- =

Before Jesus Christ (or our era)

Today, this system propose to write a tag like that: KEY:YYYY-MM-DD-YYYY-MM-DD=VALUE, with the first YYYY-MM-DD as the start date, and the second as the end date.
If we wanna tag an object from before JC, or the year 0, this concept doesn’t give the way to do.
So, the first idea should be to add an “-” symbole before the year. In this case it give something like that: KEY:-YYYY-MM-DD–YYYY-MM-DD=VALUE (in the case where the start date and the end date are before JC).


Here is my problem and the solution I propose.

Please forgive my English mistakes, and I’m impatient to read you answers.

1 Like

This documentation is specific to OpenStreetMap but doesn’t apply to OpenHistoricalMap. It probably needs some warnings to that effect; you aren’t the only one who’s confused by it. The documentation in other languages might be even more outdated.

The most current documentation about dates in OHM is on these pages:

Unlike OSM, OHM follows the EDTF standard to represent uncertain dates. This way we don’t have to devise our own syntax, which would be potentially messy and incomplete as you see in OSM. However, no software supports EDTF yet.

These pages don’t do a great job of spelling out the general approach, which is “One feature, multiple elements in OHM”. We’ve only started adjusting iD to better manage multiple copies of a feature, but there’s a lot of room for improvement.

As you’ve noticed, creating multiple copies of a feature doesn’t accommodate variations in minor details like maxspeed very well. There are some things like population that I currently hesitate to tag because of the explosion in required elements. This proposal would move most tags to relations so you can have multiple sets of tags per way. You can already do this for some things like routes, multipolygons, and maybe multilinestrings. The main renderer and Nominatim can handle some of these relation types but iD’s user interface would need a lot of work to default to relations.

OSM’s datespec proposal has seen some usage in OHM. However, as a personal observation, any method that relies on an infinite number of possible keys is extremely unlikely to ever enjoy significant software support, due to technical reasons. Regardless, feel free to use it as a quick placeholder for any dates you know of. It’s better to add the data imperfectly than to refrain from adding it at all.

1 Like

Hi @La_Voie_de_la_Raison - did Minh’s response answer your concerns? As he noted - there are others who are confused by dates, so we appreciate you taking the time to write down your concerns - merci!

Also! @La_Voie_de_la_Raison - we have a translation tool built in to this site, so maybe you could just write your questions in French?

Sorry for the time I took to answer to your message, I took a break with OHM.
So yes, it totally respond to my problem. Now I’ll map like that.
Thank’s to your answer.