Tagging why a feature started or ended

Mappers are currently using a variety of keys to describe why a feature began or ended. Should we standardize on one of these schemes?

1 Like

Quite a few of these occurrences of start_date:cause and end_date cause are the result of some imports, so please don’t hesitate to speak up if you think there’s a better way of doing things - those results may reflect less careful thinking than it appears! (not saying it’s not the right answer, just saying, “Please speak up!”).

Personally, I started using *_date:cause just because I was seeing it so often, but I find that *_event makes more sense. The value doesn’t isn’t what caused the date, it’s what caused the start or end. Still, it’s only slightly awkward; if a mass tag refactoring would be impractical, we could paper it over with a more intuitive field name in iD.

1 Like

This continues to bother me about start_date:cause and end_date:cause. If I happen to be able to explain how something was created but have no idea when it was created, then there would be a dangling start_date:cause without a corresponding start_date. This situation is underscored by the new EDTF fields in iD: iD strongly associates start_date:* subkeys with start_date in the inspector.

A proposed import of U.S. county boundaries would include a full sentence in the start_date:cause of some 17,000 more features. I think most of these sentences would fit right in with a start_event key. After all, the field in the import source is called CHANGE, so it’s really about an immediate, instantaneous event that “causes” us to create the relation, rather than a phenomenon that indirectly gives rise to the boundary. And either way, it definitely isn’t what caused the date to happen – that’s just the inexorable march of time.

Given no further input here, let’s shift from *_date:cause to *_event for the great reason that @Minh_Nguyen points out: :cause doesn’t really describe the date; it describes the change that is described in the geometry.

Should we go back and make a mass conversion across the OHM database?

If so, let’s document it in the wiki first.


1 Like

Geez… look who’s eager for an automated tag cleanup… :sunglasses: