Approximative dates in start_date tag are not working

[svergeylen]

Bug description
Using approximating dates as described on the wiki does not work.
The elements using approximating dates are shown at all dates, even if they should appear on the mpa only when their start_date is reached.

The interpretation of the straing start_dates should match the wiki documentation (or the documentation should be adapted to reflect what is recommended AND working). Approximative dates are necessary for OHM projects, so the conversion of tags as start_date=C11 to reflect 11th century should be used as start_date=01/01/1000.

Repro Steps
Set an approximative start_date on an object (eg building : start_date=C11 for 11th century)
Go to OHM after update and set a date before 11th century (as 01/01/500)
Check that the building is still visible, even it should not.

Screenshots & URL
Exemple : https://www.openhistoricalmap.org/way/199484461#map=19/44.81613/1.14859&layers=O&date=0200-12-16&daterange=0200-12-16,1850-01-02
This building has a start_date=C17 but is visible all the time.

Wiki page --> Approximations

To be reviewed :

start_date=~1855 (some time around 1855)
start_date=1860s (during the 1860s (i.e 1860 → 1869 inclusive))
start_date=~1940s (probably during the 1940s)
start_date=480 BC (for something that happened in that year)
start_date=before 1855 (during 1854 or before)
start_date=before 1910-01-20 (before a specific date - possibly when a photo was taken)
start_date=after 1823 (after 1 January 1823 - possibly based on the year in which a map was produced)
**start_date=C18 (during the 18th century)**
start_date=mid C14 (some time during the middle of the 14th century)
start_date=late 1920s
start_date=~C13 (probably in the 13th century)
start_date=1914..1918 indicates some time during WW1.
start_date=2008-08-08..2008-08-24 indicates some time during the Beijing Olympics.
start_date=mid C17..late C17
start_date=j:1918-01-31 (a date using the Julian calendar, equivalent to 1918-02-13 in the Gregorian calendar)
start_date=jd:2455511 (Using the [Julian day](https://en.wikipedia.org/wiki/Julian_day) system, equivalent to 2010-11-10 in the Gregorian calendar)
Muslim calendar?

[Kovoschiz]

Notice the banner, and read the discussion page. Those almost are entirely made up, and for OSM. It's not supposed to be supported. start_date:edtf= is the standard used, and an indicative year should be used in start_date= .

[1ec5]

The documentation for approximate dates in OpenHistoricalMap was a bit scattered, so I wrote up some more concrete documentation for both keys:

• start_date:edtf
• end_date:edtf

[jeffreyameyer]

Thank you, @1ec5 & @Kovoschiz

@svergeylen - for now, both start_date & end_date need to be in YYYY-MM-DD to work with our renderer.
For approximate data support, please see: #15

[Kovoschiz]

@1ec5 Before, it is said support is aimed to start at Level 1, so this should be distinguished. If you are using seasons =1814-23 , semantically it is better to use the set notation alongside in Level 2 =[1906..1908] to show one of the years, instead of adopting the interval =1906/1908 for something that's a point in time.
Perhaps an interval in start_date= and end_date= may mean gradual or varying opening and closing of a whole feature or event, which is otherwise not shown by the enclosed or related objects. Sometimes it might be difficult to define one time point. Or it can mean construction and demolition of a structure, as the process for large buildings in history can take very long time for finish, but still formed a significant presence. This is also unclear, with a moderately used construction_date= , and an awkward year_of_construction= in OSM, assuming they could have such meaning differing from start_date= for beginning of use.
(If both of the wiki pages focus on the same syntax, they could be combined to make the suffix the subject)

[1ec5]

Before, it is said support is aimed to start at Level 1, so this should be distinguished. If you are using seasons =1814-23 , semantically it is better to use the set notation alongside in Level 2 =[1906..1908] to show one of the years, instead of adopting the interval =1906/1908 for something that's a point in time.

I was unaware that we were aiming for level 1. I just assumed we wanted the *:edtf keys to accept any valid EDTF, with the assumption that additional levels would be strict supersets of previous levels. No data consumer supports these keys yet, so we have an opportunity to set the most forward-thinking expectations around them.

For the documentation, I was going off @rwelty1889’s SotMUS ’22 talk and the existing common values in taginfo, which are dominated by the interval notation (actually using .., which is probably not as precise as without). There appear to be some attempts at the set notation, but without the required square or curly braces. I’ve added the correct set notation as an alternative for now.

The set notation makes it possible to indicate a set of possibilities for both ends of an interval. It makes me wonder if we even need two EDTF keys, or whether we could unify them in a single key that takes an interval. Combined with repeating intervals from ISO 8601-2, we’d even have a way to represent the schedule of a festival that occurs on the same day every year, that sort of thing.

Level 2 also introduces hemisphere-specific seasons. The examples just use location-independent seasons, just as they omit the time zone when specifying the time of day, since the feature inherently comes with location context. But if the location-independent seasons are problematic for data consumers, I suppose we could encourage the more specific syntax.

Perhaps an interval in start_date= and end_date= may mean gradual or varying opening and closing of a whole feature or event, which is otherwise not shown by the enclosed or related objects. Sometimes it might be difficult to define one time point. Or it can mean construction and demolition of a structure, as the process for large buildings in history can take very long time for finish, but still formed a significant presence. This is also unclear, with a moderately used construction_date= , and an awkward year_of_construction= in OSM, assuming they could have such meaning differing from start_date= for beginning of use.

I think OHM has an opportunity to avoid the proliferation of overlapping lifecycle keys that OSM has seen. Since a single real-world feature can have multiple representations in OHM, we can micromap the life cycle in more detail. I agree that there are different definitions of “start” and “end” for something like a large building that can be difficult to pin down, but it basically depends on what the sources are able to tell us:

• This building under construction started when the construction crew laid the foundation, while this building under construction started the day of a groundbreaking ceremony before the foundation was laid.
• This finished building started on the day of a ribbon-cutting ceremony after all the details were complete. Similarly, this building under construction ended when the building was completed, several months after the building was “topped out”. I had recorded the topping-out in a note, but perhaps it would’ve been better to split out two buildings under construction and only set building:levels on the latter.

(If both of the wiki pages focus on the same syntax, they could be combined to make the suffix the subject)

It could be useful to split out a page specifically about the EDTF syntax, just as there is for the opening hours syntax. But I think there would still need to be articles on start_date:edtf and end_date:edtf specifically, so that tools such as iD can pull up descriptions of these keys easily.

[1ec5]

OpenHistoricalMap/iD#185 turns the date fields into a structured form to keep mappers from mistakenly using OSM’s ad hoc format with the main date keys. OpenHistoricalMap/iD#187 adds EDTF fields to iD for discoverability.