Detta inlägg handlar om ännu ett sätt att centrallagra och versionshantera geodata distribuerat i ett nätverk. Till skillnad från en vanlig databas så hanteras alla data i en lokal version av den centrala databasen och ändringar eller uppdateringar synkas mot databasen när man har möjlighet eller så önskar. Versionshanteringen gör även att man kan ”checka ut” en namngiven kopia på databasen som man kan arbeta med, på flera håll, och sedan går det att kontrollera skillnader mot centraldatabasen och ”merga” ändringarna tillbaka. Detta även om någon annan ändrat i data på sitt håll.
Allt bygger på ”Git” och det är inte första gången som vi ser det här för geodata (exempelvis geogig). Det handlar om ”Sno” (https://sno.earth/), som för närvarande finns för Mac och Linux, men en Windowsversion är på väg.
Efter installation kan man initiera ett ”repository” med ett befintligt dataset.
Jag kommer att använda ett mycket enkelt geopackage lager, vilket är det format som för närvarande stöds.
sno init testprojekt --import GPKG:sno_test.gpkg
Ovanstående kommando ber mig välja en tabell att importera, så jag har inte riktigt koll på om det går att importera flera tabeller på en gång. Hur som helst så skapar kommandot ett repository där det finns ett nytt geopackage som det är meningen att man skall använda och journalfiler som spårar alla ändringar.
Det projekt som skapats har en del extra tabeller med ”dolda” namn som sannolikt är en del i hanteringen av versionshanteringen.
När jag redigerar data så kommer sno att känna av detta och presentera det i terminalgränssnittet.
>sno status
On branch master
Changes in working copy:
(use "sno commit" to commit)
(use "sno reset" to discard changes)
polygoner/
modified: 1 feature
new: 1 feature
Vill jag spara ändringarna (som är sparade i arbetskopian av databasen) så gör jag en ”commit”, annars kan jag köra kommandot ”reset” för att återgå.
>sno commit -m "Mina ändringar"
Precis som med git så kan man skapa en ”gren” (branch).
>sno checkout -b gren_1
Ovanstående kommando skapar en ”gren” av databasen som blir ”aktiv” i det lokala biblioteket, och den databas som redigeras i QGIS (om man öppnar tabellen där). Ändringar som görs hamnar i denna grenen, och man kan enkelt hoppa mellan ”master” och förgreningar med switch kommandon. Du måste dock använda ”commit” innan du byter.
Slå samman förgreningar med master med ”merge” kommandot, eller radera förgreningar med ”sno branch -d gren_namn”.
Alla ändringar spåras och kan listas med ”sno log”. Vill man gå tillbaka till en tidigare ”commit” så använder man ”checkout” och det autogenererade commit-namnet.
Normalt så skapar man sin ”master” på en server någonstans och jobbar med en lokal version med ett ”sno clone” kommando. Detta initierar en lokal kopia av ett repository på en fjärr-url. Ändringar som gjorts i den lokala kopian kan sedan ”tryckas” tillbaka med ”sno push”, eller uppdateras med de senaste ändringarna med ”sno pull”. En gren av databasen kan sedan slås samman med ”master” med ett ”merge” kommando.
Avslutning
Nu är detta den första publika versionen av sno, så det finns naturligtvis brister. Exempelvis kan inte ändringar i schema i databasen hanteras. Det går med andra ord inte att lägga till tabeller och få dessa att versionshanteras med sno.
Att endast geopackage hanteras är också en brist som man jobbar på.
Den som är van vid att hantera git kan säkert känna sig ganska hemma med sno, men för de flesta andra så kommer det att kännas krångligt. Det bästa vore såklart ett plugin i QGIS som kan göra en ”pull” från en url och sedan ha knappar för ”commit”, ”push” och ”pull”, kanske även ”status” och ”diff”.
Hur som helst så är sno ännu ett alternativ vi har att beakta när vi överväger hur vi vill hantera geodata distribuerat med flera som skall hantera och redigera dessa data. Och som vanligt är flera alternativ bättre än inget alternativ, även om alternativen i många fall är lite krångliga.