Samenwerken op een survey project
4. Projectbeheer
4.2. Synchronisatieproblemen oplossen
Er kunnen synchronisatieproblemen optreden wanneer twee gebruikers enkele bestanden in een gedeeld project tegelijk bewerken. De technologie achter de Mergin-service probeert om wijzigingen van individuele gebruikers automatisch samen te voegen en daarom treden synchronisatieproblemen normaliter niet op, zelfs niet als meerdere mensen een enkele gegevensbron (bijvoorbeeld een GeoPackage) bewerken. Er zijn echter nog steeds gevallen waarin Mergin niet in staat is om automatisch synchronisatieproblemen op te lossen. In die gevallen zal Mergin conflictbestanden in de projecten creëren.
Allereerst is het belangrijk om deze situaties zoveel mogelijk te voorkomen.
Hier zijn enkele good practice aanwijzingen om problemen te voorkomen:
- Gebruik altijd GeoPackage voor survey lagen. Als je andere formaten gebruikt, zoals ESRI-shapefile, kan Mergin geen wijzigingen van andere gebruikers detecteren en zal het bestand overschrijven. Overschreven bestanden worden opgeslagen in een conflictbestand.
- Voeg wat extra back-up veldattributen toe bij het maken van een survey laag met verschillende typen (bijvoorbeeld een paar teksten, int, real, datum/tijd) en verberg ze in het formulierontwerp. Deze kunnen als back-up dienen: als je later in het veldformulier extra velden nodig hebt, maak dan een alias voor deze extra velden en voeg ze toe aan het formulier.
- Als je een veld niet nodig hebt, verwijder het dan van het formulier. Je hoeft het niet uit de tabel te verwijderen.
- Wijzig de alias van een veld in plaats van de naam van een veld te wijzigen.
- Voeg nieuwe lagen toe aan je project als afzonderlijke GeoPackages. Voeg geen nieuwe tabel toe aan je bestaande GeoPackage met een survey laag. Voor de zekerheid is het beter om één GeoPackage te hebben voor elk van uw survey lagen.
- Gebruik het GeoTIFF-formaat voor uw rasterbestanden of sla ze op in een aparte GeoPackage-database
Het is dus belangrijk om vooraf de survey lagen goed te ontwerpen voordat ze gebruikt worden. Veranderingen in het aantal attributen en data types kunnen problemen veroorzaken!
Er kunnen twee soorten synchronisatieproblemen zijn:
- Problemen met edits
- Conflicterende kopieën
Problemen met edits
Laten we als voorbeeld het grondwater project nemen, waarbij het veldwerk wordt uitgevoerd door Jan en Petra. Ze splitsen de taak in tweeën en gaan het veld in om de putten te observeren. Per ongeluk observeert Jan ook een put die aan Petra is toegewezen - ze bewerken allebei attributen van hetzelfde punt, met iets andere waarden. Hoe gaat Mergin daarmee om?
Als Jan de eerste is die zijn wijzigingen synchroniseert en Petra vervolgens haar wijzigingen synchroniseert, weet Mergin op het moment van Petra's synchronisatie dat er een conflict is in bewerkingen voor die ene put. De gebruiker die het laatst synchroniseert "wint", dus in dit geval zouden Petra's wijzigingen behouden blijven en Jan's wijzigingen worden overschreven (natuurlijk zouden al zijn niet-conflicterende bewerkingen voor de andere putten behouden blijven). Mergin houdt dit bij, voor het geval een projectbeheerder het bewerkingsconflict zou willen onderzoeken: als het probleem zich voordoet in putten.gpkg, dan zou een JSON-bestand met de naam putten (edit conflict, jan v123).json worden gemaakt, met daarin een lijst met conflicten. Voor elke conflicterende attribuutwaarde vermeldt het bestand de oorspronkelijke waarde en de twee verschillende gewijzigde versies.
Als Jan de eerste is die zijn wijzigingen synchroniseert en Petra vervolgens haar wijzigingen synchroniseert, weet Mergin op het moment van Petra's synchronisatie dat er een conflict is in bewerkingen voor die ene put. De gebruiker die het laatst synchroniseert "wint", dus in dit geval zouden Petra's wijzigingen behouden blijven en Jan's wijzigingen worden overschreven (natuurlijk zouden al zijn niet-conflicterende bewerkingen voor de andere putten behouden blijven). Mergin houdt dit bij, voor het geval een projectbeheerder het bewerkingsconflict zou willen onderzoeken: als het probleem zich voordoet in putten.gpkg, dan zou een JSON-bestand met de naam putten (edit conflict, jan v123).json worden gemaakt, met daarin een lijst met conflicten. Voor elke conflicterende attribuutwaarde vermeldt het bestand de oorspronkelijke waarde en de twee verschillende gewijzigde versies.
Conflicterende kopieën
Mergin kan geen wijzigingen detecteren als je het gegevensschema wijzigt, zoals het verwijderen of toevoegen van attributen aan je survey laag of het wijzigen van het gegevenstype van een veld. Als je een laag probeert te synchroniseren met een gewijzigd gegevensschema, krijgt je een conflictbestand.
Hier kan je meer informatie vinden als het echt noodzakelijk is om het schema van een survey laag te veranderen.