Almost a thousand features have end_date:edtf=* set to exactly one more than end_date=* – one day, one month, or one year later, depending on the precision. For example, the Czech Republic has end_date=1948-05-08end_date:edtf=1948-05-09. This is incorrect: end_date=* needs to fall on the date or within the date range specified by end_date:edtf=*. Now that we’ve fixed an off-by-one error in iD, iD will flag this as an error.
If the intent is that the end date is, for instance, either 1925-04-13 or 1925-04-14, then the correct tag would be end_date:edtf=1925-04-13/1925-04-14 and we can choose either date as the end_date=*, depending on whether you’re concerned about spatiotemporal conflicts with other features. Otherwise, are some mappers using EDTF tags for some other purpose, perhaps?
This is a workaround to prevent multiple entities being rendered on the “transition” day. Basically the entity using the end_date(:edtf) needs (or needed if something has changed since then) to be “removed” from the map the day (or month or year) before the start_date of its successor using end_date:edtf for the “actual” date and end_date for the day/month/year prior was the compromise/workaround. In other words end_date is “for the renderer” while end_date:edtf is the “actual” date.
Unfortunately I can’t find where exactly it was talked about at the moment.
@Alphathon is right on target. I believe I was doing this (hopefully not recently…) in the belief (or experience) I was avoiding having 2 temporally sequential objects rendered in an overlapping display.
For situations where we are down to specific days, the way things works now, with our day-resolution time slider kind of makes sense. But, when we are looking at things with wider time ranges, say, years, I wonder if that’s just something we’ll have to deal with.
For example, if we know a transition took place during 1783, but we don’t know when, and object a has an end date of 1783 and object b has a start date of 1783, does it make sense to imply through rendering that the transition occurred on Jan 1, 1783?
OK, that’s what I was trying to get to the bottom of here:
If you tag start_date=1783 on something, the renderer interprets that as January 1, 1783, at the earliest. However, if you tag end_date=1783 on something, the renderer interprets it as the stroke of midnight at the end of December 31, 1783, as the latest possible end date. And the time slider on the homepage always assumes noon on the selected date, just to be on the safe side.
Therefore, I think the approach you’re describing may have the opposite effect and meaning than what you expect. Keeping the end and start dates a year apart means the changeover took place on January 1. Similarly, if two successive features have day-precision dates, keeping the dates one day apart means the changeover took place at the stroke of midnight. A renderer cannot choose to infer otherwise.
Right, so if you were to tag two successive features with end_date=1784 and start_date=1784, they’d appear to coexist for an entire year – the year during which we’re unsure which one exists. While this may not look very intuitive, it’s more correct than tagging an EDTF date that contradicts the basic date. The best way to keep them from coexisting is to determine more precise dates.
With the recent changes to boundaries, the renderer recognizes that the end_date=1783 of one feature and the start_date=1784 of a coincident, identically named feature represent a continuous series and conflates the two boundaries’ common edges together. This also works with end_date=1784 and start_date=1784. So the issue of overlapping features no longer affects boundaries as badly as before.
If you must keep two features one date apart because of a midnight changeover, you can use EDTF tags to affirm this fact:
However, this is probably overkill in most cases, since it’s the default interpretation. I’ve only taken this approach for a couple of time zone boundaries that changed over at midnight, since hour-level precision is important for those boundaries.
Conversely, if you must keep two successive features from coexisting, you could use a less precise set of EDTF dates.
end_date=1784-06-30end_date:edtf=1784
start_date=1784-07-01start_date:edtf=1784
Personally, I would only add that additional detail if I have some hunch that the changeover happened mid-year. Otherwise, arbitrary fudge factors like this will only give us headaches down the line as users come to expect micromapping and we have to verify these dates.
I only recently started doing this because of features appearing during the same time, and I saw it being done this way everywhere. But I don’t really like to micro map this much. I often do try to find the exact treaty date so I can tag the exact day. But if you say it’s a bad way of doing it, then I won’t do it like that.
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.
What would you recommend in situations like these?
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?
That seems bad, as well… but it does reflect two things that are known, even if the date during the year is unknown: area a transitioned to area b at a single point in time and that they did not simultaneously coexist.
You’re not wrong (although it can make for some pretty ugly/confusing maps at times). Most of the one’s I’ve done have been for specific days though.
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”?)
I suppose what I’ve been doing now would really be represented as
Same for me really, although I’ve been doing it for quite a while. I just sort-of assumed it was a “necessary evil” until a better solution was found and didn’t really question it much.
That’s certainly my interpretation and I think it’s intentional? At least mappers would know that the entity didn’t have a precise start_/end_date.
I tend to agree, assigning an arbitrary “fake” date seems bad, although that’s kind-of what we’re already doing if you think about it – it’s just based on renderer assumptions instead of being explicit. That does make it “feel” more “neutral” though. 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.
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.
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:
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.
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.
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.
![Czechoslovak Republic [1947 – 1948] has an end date that falls outside of the EDTF end date](https://forum.openhistoricalmap.org/uploads/db6154/original/1X/2894444c500b2ec8ed889d66e42cd6a8a91742c9.png)
) at some point in the middle of the year? E.g., ![Relation: Karelian Autonomous Soviet Socialist Republic (1956-1987) [1956 – 1986] (2852350)](https://forum.openhistoricalmap.org/uploads/db6154/original/1X/c3e27f07c1bcfccbd09f15e2c8e502e186732e9b.png)