Proposal talk:Key:date

Status

It would be useful (to me) to resurrect this proposal and take it forward to completion as either an approved or rejected feature. --Ceyockey 16:23, 29 November 2009 (UTC)

OSMdoc summary

OSMdoc link → http://osmdoc.com/en/tag/date/

As of 29 November 2009:

• 206 Nodes
• 22 Ways
• 2 Relations

Value review

There are 57 distinct values which fall roughly into 9 classes (in order of # of instances):

• (26) Year YYYY
  • ex. "1290", "1987", "635"
• (9) FullDate YYYYMMDD
  • ex. "20081207", "2008-08-29", "2008.04.04", "1945-5-7"
• (5) FullDate DDmonthYYYY
  • ex. "2.Juli 1704", "22nd June 1679", "13 september 2008"
• (4) FullDate DDMMYYYY
  • ex. "13.08.1704", "08-07-2009"
• (4) FullDate monthDDYYYY
  • ex. "October 6th 1921", "May 17, 2009", "Oct 16, 1813"
• (4) RangeDate
  • ex. "14-15 May 1982", "1840-1841", "yearly, Christopher Street Day"
• (2) RomanNumeral
  • ex. "XV", "X-XVII"
• (1) ApproxDate
  • ex. "7 ???????? 1812 ?."
• (1) FullDate MMDDYYYY
  • ex. "5/20/2009"
• (1) monthYYYY
  • ex. "Décembre 2010"

Recommendations based on OSMdoc summary

(section started) --Ceyockey 17:30, 29 November 2009 (UTC)

A de facto decision has been made for key:date that it should follow the principles for keys such as key:name rather than key:highway. In other words, values with multiple instances arise due to content contribution rather than by design as a matter of data organization.

A decision has not been made on whether values for key:date should be controlled to facilitate processing. In other words, no decision has been made / implemented which would allow a MMDDYYY date be interpreted as synonymous with a DDMMYYY date, or to enforce only use of MMDDYYY-format values. It would be very easy to propose something that is rule-heavy and usability-lite - that won't be done here.

Searching OSMwiki did not give clear guidance on the use of so-called 'composite tags' other than that they exist and are in some use. Composite tags are useful in that they could provide a fully optional extension to a core tag while retaining context which is informative to taggers and tag consumers.

Below are specific composite tag suggestions.

• year=* ← composite format date:year=* → example (two tag-value pairs) date=13 september 2008; date:year=2008
  • in principle, a bot could add a key:date:year value to an object with a date property given a handful of relatively straightforward rules. This would, in fact, crack a major proportion of current key:date values into a computationally tractable value set.
• month=* ← composite format date:month=* → example (three tag-value pairs) date=13 september 2008; date:year=2008; date:month=September
• day=*
• dayofweek=*
• calendar=*
  • The composite date:calendar is meant to capture one of several controlled values; multiple values should be semicolon-delimited (standard OSM practice). Suggested values (not proscriptive): "AD", "CE", "BC", "OS", "NS", "Julian", "Gregorian", "Islamic", "Hewbrew".
  • It should be assumed that dates are from the Gregorian calendar in the AD era unless otherwise stated. For the sake of data integrity, the date from the source should be used rather than a conversion of the date be done for inclusion in OSM data.

Outstanding questions

• How would internationalisation be implemented? Would language-specific (e.g. DE:date:month=Februar) keys be desirable? --Ceyockey 17:30, 29 November 2009 (UTC)