Maybe we should deprecate the date=* tag?

General talk Tagging general discussion
1

This tag should be used for two things:

  1. Together with historic=* to indicate the date of an event (ISO 8601)
  2. Together with amenity=clock to indicate whether the clock shows the date. (date=yes/no)

I already consider this combination of meanings to be incorrect, because, surprise, there are historic=memorial + amenity=clock overpass turbo

In practice, I consider this tag to be as cursed as id= and I suggest getting rid of it before it’s too late.

So, the tag values ​​are: date | Keys | OpenStreetMap Taginfo

1500×1306 159 KB

No more than 20% used for its intended purpose:

1768×1254 352 KB

Out of 9000 amenities, only 5000 are amenity=clock.

Let’s see where date=6/18/2010-7/7/2010 is used

1920×1051 180 KB

https://osm.org/user/AnnaHight89/history?after=13519967

It seems that the top values are similar incorrect uses.

Well, maybe historic + date is used more successfully? overpass turbo

Most of the relations are boundary=historic_parish in Ireland. I don’t understand how I’m supposed to interpret a tag, like start_date=*? Relation: ‪Galloon Parish‬ (‪11029235‬) | OpenStreetMap

And most of the ways are the date on the tombs: Way: 1173656326 | OpenStreetMap

But actually we have Key🧑date_of_birth - OpenStreetMap Wiki and Key🧑date_of_death - OpenStreetMap Wiki

Looks pretty valid historic=battlefield + date=*. It seems that most of the correct values ​​are here, however, non-ISO values ​​are also found

Remaining ~1000 POIs overpass turbo

There are a lot of historic=memorial, but here I want to ask: are we sure that the cartographers did not add start_date=*?
…

Potential RFC

Disclaimer: I’m not a native English speaker, so feel free to suggest other, more correct new tags.

  • Deprecate date=*
  • amenity=clock + date=yes/no → amenity=clock + with_date=yes/no
  • Most historic + date can be replaced with start_date=* or other documented tags. More complex cases can be replaced with something like historic:date=*

Side effects:

  • we can standardize the date value so we no longer see 20001231
  • We can link more Wikidata in the process, and this can provide more accurate information to the end user

The affected projects mostly use amenity=clock. date | Keys | OpenStreetMap Taginfo But I don’t think this change will be painful, due to the limited usefulness of the date=yes/no tag for the end user.

p.s. I was inspired by the idea of ​​adding the date: keyword to Overpass Wizard Add operator `date:` into Wizard · Issue #784 · tyrasd/overpass-turbo · GitHub So I decided to check if there is such a tag in OSM and realized that the practice of using it is terrible

4 Likes
2

Replacing historic + date with start_date is problematic because the historic ‘thing’ may have been created long after the significant event that the ‘thing’ is meant to memorialize. I would say that using something like historic:date= should be for all cases of historic, so that start_date can be used to tag when the thing was built/opened/brought into existence, as it is (or at least is supposed to be) for every other kind of thing in OSM.

2 Likes
3

there is still some fuzzyness in the tag, because of things that get relocated (e.g. an egyptian obelisk some thousand years after its creation gets brought to Rome by the Roman Empire and another thousand years later is brought to another site again.

Or a cathedral is began to be built on top of an older church in the 13th century and is finally declared „finished“ in the nineteenth century, but in the meantime was already used („working“).

In such cases I am always unsure which is the date to put (generally I tend to use the oldest date even if the thing may have undergone significant changes)

1 Like
4

Thanks for looking into this issue. More clarity about the dates in OSM will prevent misleading dates from spreading to OpenHistoricalMap, where they could take on more importance.

I’m guessing this was the vintage of the Bing imagery or something like that. It seems to have been part of the EUROSHA mapping campaign that needed other retagging too. Thanks for deleting these occurrences.

Works of art are especially prone to this ambiguity. The tourism=artwork documentation has long interpreted start_date=* as the date of completion rather than the date of installation. I suspect the idea was that start_date=* is whatever the plaque would say. But a plaque could actually say the date of completion, installation, dedication, or rededication. I think we should keep our expectations low and avoid overthinking it. Even in the ideal scenario where the date comes from field observation, this is not a key you can really rely on to write a historical narrative of the feature. It’s just a slot for a date that needed to go somewhere.

(In OHM, where we do have a solution for things that move around and otherwise evolve over time, there can still be multiple kinds of start dates to choose from. But generally we’re clarifying that with start_event=* or note=*.)

with_date=* does solve the problem, though the use of a preposition is awkward and unusual. It reminds me of is_sidepath:of=*. How about something more descriptive, like date_display=*? Or since clocks are already tagged display=analog/digital/sundial, how about display:date=*?

3 Likes
5

I agree with deprecating the “date=” key.

  • For the 1st usecase (“Date when related event happened”), I’d use “historic:date=”. For memorials and plaques, “start_date=” would be when the it was installed at the present location.
  • For the 2nd usecase (“Clock (amenity=clock) also shows the current date”), I’d go " with_date=*" or display:date= suggested above or “date_display=” mentioned on Talk:Key:date. I haven’t used such tags yet, so I don’t have a preference beyond not combining it with actual dates.

Most current uses are probably for survey:date, maybe source:date or check_date. The key “date” likely invites this.