Tagging end_date:edtf=* as an increment of end_date=*?

[Minh_Nguyen]

@jeffmeyer

This seems to imply that both areas will be rendered for the entire year of 1783, no? If so, that seems suboptimal visually, even if it represents the appropriate fuzziness.

Maybe it helps to consider the base case. Let’s say there’s a building that had a lot of turnover last year, so three different shops occupied it in 2024. If we know that they came in a certain order, we can guesstimate some months and use EDTF tags to indicate uncertainty. But if we only know they were all there in 2024, all three will have the same date tags. There’s no avoiding overlap.

Now consider a map with a year-precision time slider, such as Gramps Web, OSM–Wikidata Map, or OpenRailwayMap. The developers made a conscious decision to provide less granularity at the expense of some feature overlap, in order to simplify the user interaction. The time slider is essentially a date range picker. Our own time slider is too: when you set a date, it shows everything that existed within that day, even if multiple features could coexist within the day. Data consumers should be able to make such choices.

@Alphathon

I don’t really think there is a good solution (at least not without some way of displaying the uncertainty visually) since an assumption has to be made somewhere for almost all changes.

Yes, when the time slider is more precise than the data, the map needs to hedge about the feature’s existence. It currently treats existence as a binary proposition, but we could vary the opacity or (in some cases) annotate the label to point out the potential discrepancy:

Features that are uncertain or unlikely to exist should be translucent

Not every data consumer is a rendered map. The website now labels features with dates automatically. If the site says a feature existed “1702–1783”, users will take that at face value. They may also notice that our end year differs from what other sources give as the end year and therefore lose trust in us. We could mitigate this issue somewhat by preferring EDTF dates over basic dates, but the database would remain internally self-contradictory.

@jeffmeyer

Choosing an arbitrary date (you know… like 29 Feb? ) at some point in the middle of the year? E.g., start_date:edtf = 1783 and start_date = 1783-06-31?

The EDTF date is always the more correct date, because EDTF is more expressive. The basic date tag’s value should always fall within the range of possibilities indicated by the EDTF tag. Any fudging for the renderer should happen in the basic date tag.

@Alphathon

Does this take time zones into account, and if not how would that be done? (If it doesn’t I would assume that’s either UTC or some fictitious “universalised global time” where everywhere non-UTC is “shifted”?)

According to the EDTF specification, if you omit the time zone, the local time zone is assumed. (This is really handy for recording times of day before time zones were standardized.) You can specify the time zone as an offset, like +01 or +01:00 for Central European Time, or Z for UTC. If a source gives the time according to some other unknown time zone, you could use something like 2024-04-14T02:00+XX, though I don’t know if the popular EDTF parsers support this.