Versioning based on temporality #733
Replies: 1 comment
-
I have used Kart for this (well, for the past), with some success. A data paper is in preparation, but in brief we wanted to represent roads over time, to capture the effect of new highways built over the last decade on an environmental index. Although we can't unambiguously identify whether a road that is present in a dataset in 2018 and was absent in the 2012 representation is because it was truly not there, or if it was just erroneously absent. However for major highways that I checked against, this model worked well as a rapid method of filtering a dataset of roads by time when they lack any kind of attribute that could otherwise be used directly. It would have been ideal to use syntax like: kart checkout `git rev-list -n 1 --first-parent --before="2018-01-01 12:00" main` This doesn't seem to work as anticipated for the layers I used it against (https://data.linz.govt.nz/layer/50329-nz-road-centrelines-topo-150k/). Instead I used the logs to statically determine an appropriate commit hash for each time step. This was mildly cumbersome but feasible for an annual timestep. Applied carefully, I can't see why Kart couldn't be used as a means to get temporal representation of data in a way that has been rather hard to do until now. |
Beta Was this translation helpful? Give feedback.
-
I was wondering if people work also with the concept of temporality, in aviation we have datasets that we work in the future with a specific date. I think Kart would be a great case to create a branch but include also a validity date on it, then upon commiting to master the versions will live but somehow temporal filters can be used to show only the data that is effective at specific points in times like snapshots. Maybe this is not a typical use case within GIS but I may be mistaken. Is this something that sounds feasible in the future?
Beta Was this translation helpful? Give feedback.
All reactions