Grontmij Polska wykonywała plan utrzymania wód dla Regionalnego Zarządu Gospodarki Wodnej w Poznaniu. Podstawą do pracy była baza danych odcinków rzek z całego dorzecza Warty podzielona na odcinki wedle ustalonej z Zamawiającym metodyki. 4 osoby z działu GIS pozyskały wszelkie potrzebne dane z różnych źródeł i doprowadziły je do spójnej postaci. Kluczową częścią całego projektu było dokonanie oceny odcinków wód oraz zaproponowanie wariantów ochrony. Z technicznej strony polegało to na opisaniu każdego odcinka za pomocą ok. 30 atrybutów. Nad całością oceny miało pracować ok 20 osób. Czasu było bardzo mało. Do pracowników działu GIS należało zaplanowanie prac wraz z oszacowaniem ryzyka.

Wariant pierwszy, klasyczny, zakładał podzielenie warstwy z 2700 odcinków na 20 „paczek” i rozesłanie ich e-mailem do pracowników i podwykonawców. Po zadanym czasie „paczki” miały wrócić e-mailem i zostać ponownie scalone. Z pozoru błaha sprawa okazała się jednak bardzo ryzykowna. Oto główne ryzyka:

• przekazanie plików edytowalnych (geobazy) do 20 osób spowoduje utratę kontroli nad spójnością bazy danych. Może się zdarzyć, że ktoś doda lub usunie kolumnę, zmieni jej nazwę lub typ danych. Spowoduje to ogromne problemy podczas scalania danych.
• Zdawano sobie sprawę, że specjaliści z zakresu ochrony środowiska nie są doświadczeni w GIS. Rodziło to obawy o techniczną jakość pracy (przypadkowo zmieniona geometria, usunięcie rekordu, powolna praca) oraz o problemy techniczne (różne oprogramowanie i związane z tym przekształcenia plików, zmiany kodowania, układów itp.).
• W tym wariancie, administratorzy danych nie mieli żadnej kontroli nad materiałami pomocniczymi na bazie których miała nastąpić ocena (głównie formy ochrony przyrody). Istniało ryzyko, że niektórzy nie użyją przekazanych danych, ale swoją ocenę oprą na bazie innych danych (z różnych względów: przyzwyczajenie, znajomość danych itp.).
• obawiano się zmian w strukturze atrybutów, które mogły pojawić się po rozpoczęciu oceny, na bazie wniosku/sugestii zamawiającego. W takim wypadku administratorzy nie mieli by pewności, że wszyscy pracownicy samodzielnie dodaliby zmian w źródle danych.
• Przesyłanie danych e-mailem lub udostępnianie ich przez dysk sieciowy również stanowi problem. Pliki składowe plików shp mogą się pogubić lub uszkodzić powodując trudne do określenia problemy. Zwrócono również uwagę na problem dosyłania poprawionych danych po scaleniu
• Gisowcy najbardziej obawiali się scalania danych, które ze względu na powyższe zagrożenia mogłyby się nie nadawać do połączenia
• Menadżerowie obawiali się rozmycia odpowiedzialności za wykonaną pracę ze względu na wielokrotne przekształcenia danych źródłowych.

Kolejnym wariantem była współpraca z GIS Support i wykorzystanie DIVI, który przechodził wtedy fazę intensywnych testów. Jako główne ryzyka wskazano:

• Wykorzystanie zupełnie nowego, nieprzetestowanego systemu
• Obawiano się reakcji pracowników i podwykonawców na pracę w środowisku sieciowym

Lista korzyści okazała się jednak zdecydowanie dłuższa:

• Praca na jednej warstwie niwelowała problemy wynikające z dzielenia, dwukrotnego przesyłania i scalania danych
• DIVI dawał pełną historię edycji każdego odcinka rzeki. Historia mogła posłużyć w celu rozwiewania wątpliwości
• Gisowcy mieli mieć 100% pewności, że wszyscy  używają tych samych danych referencyjnych o formach ochrony przyrody
• Nikt oprócz osób uprawnionych nie mógł zmieniać struktury warstwy oraz wartości słownikowych

Wygrał wariant z DIVI. Gisowcy zostali administratorami konta DIVI i utworzyli konta dla wszystkich osób biorących udział w projekcie. Warstwa z odcinkami rzek oraz formy ochrony przyrody (na bazie której miała nastąpić ocena) została załadowana do systemu. Ze względu na bardzo dużą ilość atrybutów do edycji, praca na zwykłej tabeli atrybutów okazała się niewygodna. Zdecydowano się na stworzenie prostego i bardzo wygodnego web edytora danych na bazie DIVI API (stworzenie aplikacji trwało kilkanaście godzin).

Praca przebiegła szybko i sprawnie. Oczywiście w trakcie edycji nastąpiło kilka „zmian koncepcji” i trzeba było dokonać zmian w edytowanej warstwie. Ze względu na wykorzystanie DIVI nie spowodowało to żadnego problemu. Edytorzy nawet nie musieli być o tym informowani, bo nie wpływało to na ich pracę.

Tempo w jakim praca została przeprowadzona oraz osiągnięta jakość (żadnych danych uszkodzonych, wymagających poprawy, zero żmudnego szukania i rozwiązywania problemów) zaskoczyły wszystkich. Najbardziej zadowoleni byli jednak sami specjaliści z zakresu ochrony środowiska. Bardzo obawiali się wykonywania ogromu pracy w środowisku GIS, do którego nie byli przekonani. Praca na bardzo prostej aplikacji webowej była dla nich bardzo wygodna. Mogli skupić się na faktyczniej ocenie merytorycznej, a nie na walce z danymi, oprogramowaniem i gisowcami. Najlepszym podsumowaniem wykorzystania DIVI jest cytat z e-maila, który otrzymaliśmy po zakończeniu projektu:

Ja jestem nieGISowy,
ja się QGISa nie tykam…
Ja robię w DIVI