Opis Przedmiotu Zamówienia

Opis Przedmiotu Zamówienia

Wojewódzki Węzeł Integrujący oraz System WZGIK

I. Ogólny zakres prac

a. Zakres projektu

Przedmiotem zamówienia jest:

1.Utworzenie i implementacja systemu Wojewódzkiego Zasobu Geodezyjnego i Kartograficznego (System WZGIK) wraz z migracją danych, wdrożeniem systemu płatności internetowych, który będzie służył do elektronicznej obsługi klienta w tym a także do zarządzania wojewódzkim zasobem geodezyjnym i kartograficznym.

2. Aktualizacja i utworzenie metadanych wojewódzkiego zasobu geodezyjnego i kartograficznego oraz utworzenie metadanych RDF dla wybranych zbiorów i usług wojewódzkiego zasobu geodezyjnego i kartograficznego oraz e-usług wszystkich partnerów projektu.

3.Utworzenie Wojewódzkiego Węzła Integrującego, w tym Portalu Centrum Usług Wspólnych (Portal CUW), który stanowił będzie bramkę dostępową do e-usług poszczególnych Partnerów i który pełnił będzie funkcję brokera e-usług.

4.Utworzenie i Implementację e-usług Centrum Usług Wspólnych.

5. Modernizacja systemu Regionalnej Infrastruktury Informacji Przestrzennej (System OWI) stanowiącej element wspólny Wojewódzkiego Węzła Integrującego (WWI) oraz Systemu WZGIK (w tym utworzenie, konwersja i migracja istniejących danych i usług sieciowych).

6. Integracja z istniejącymi systemami : Elektronicznego Zarządzania Dokumentami (EZD) oraz płatności internetowych.

Rys.1 Schemat rozwiązania (integracja z FK jest planowana w przyszłości).

b. Etapy projektu

Realizacja niniejszego zamówienia została podzielona na następujące etapy:

• Etap I – Przygotowanie wdrożenia

W ramach Etapu I przewiduje się przeprowadzenie analizy przedwdrożeniowej oraz przygotowanie koncepcji wdrożenia obejmująej w szczególności uzgodnienia dotyczące przebiegu procesów biznesowych, co stanowić będzie podstawę do sporządzenia dokumentu „Plan wdrożenia” podlegający akceptacji Zamawiającego.

Zamawiający dopuszcza modyfikację i rozbudowę procesów opisanych w załączniku B.4. do OPZ po uzgodnieniu z Partnerem, w szczególności w zakresie:

• Zakresu usługi realizowanej po za logowaniu / przed zalogowaniem,

• Powiązania – bądź braku takiego powiązania z ePUAP,

• Szczegółów wybranego systemu płatności,

• Replikacji (lub braku) użytkowników tworzonych u Partnerów,

• Zakresu automatyzmu w rozpatrywaniu wniosku (zakres kontroli automatycznej

/wykonywanej przez Pracownika).

Wszystkie opracowane analizy będą stanowić podstawę do sporządzenia dokumentu Plan wdrożenia podlegający akceptacji Zamawiającego.

Jako Plan wdrożenia Wykonawca przedstawi:

⮚ Opis architektury oraz integracji komponentów: System WZGIK, Systemu OWI, Wojewódzkiego Węzła Integrującego (WWI), Powiatowego Węzła Integrującego (PWI).

⮚ Harmonogram realizacji prac, uwzględniający:

• Etapy projektu przedstawione w niniejszym rozdziale. W ramach Etapów powinny zostać uwzględnione zadania oraz:

o Spotkania w ramach poszczególnych zadań,

o Produkty dostarczane w ramach poszczególnych zadań,

o Czas dla Zamawiającego na weryfikację produktów,

o Czas dla Wykonawcy na dostosowanie produktów po ich weryfikacji przez Zamawiającego,

o Testy;

• Kamienie milowe;

• Terminy zgodne z wyznaczonymi ramami czasowymi projektu, dla wszystkich elementów harmonogramu (czas rozpoczęcia i czas zakończenia).

Opracowany Harmonogram musi być spójny i musi uwzględniać terminy realizacji poszczególnych etapów oraz zadań wchodzących w zakres prac w ramach etapów .

⮚ Projekt techniczny;

⮚ Strategia Zarządzania Jakością;.

⮚ Strategia Zarządzania Konfiguracją;

⮚ Strategia Zarządzania Komunikacją.

Akceptacja Planu wdrożenia jest warunkiem koniecznym do rozpoczęcia kolejnego etapu.

• Etap II – Opracowanie i wdrożenie na podstawie wymagań przedstawionych w dalszej części niniejszego dokumentu.

• Etap III – odbiór dokumentacji powdrożeniowej.

Wykonawca opracuje i dostarczy dokumentacje powdrożeniową.

Na koniec Etapu III dokonany zostanie formalny odbiór przedmiotu przez Zamawiającego. Sporządzony zostanie protokół końcowego odbioru.

Wymaga się, aby w Planie Wdrożenia Wykonawca dokonał uszczegółowienia poszczególnych etapów o zadania i produkty oraz określił w uzgodnieniu z Zamawiającym zasady komunikacji x.xx. organizację spotkań projektowych. Dopuszcza się wydzielenie dodatkowych podetapów, które powinny zostać uzgodnione i udokumentowane w Harmonogramie wdrożenia.

II. Szczegółowy zakres prac

W ramach realizacji przedmiotu zamówienia wymaga się wykonania następujących prac:

1. Opracowanie dokumentu Plan wdrożenia.

2. Opracowanie Projektu technicznego: Systemu WZGIK, Wojewódzkiego Węzła Integrującego

oraz Systemu OWI oraz integracji z Powiatowym Węzłem Integrujacym.

3. Opracowanie zasad organizacyjnych współpracy Partnerów przy wykorzystaniu zasobu jakim jest CUW, tak aby bezsporne było określenie praw i obowiązków wobec każdego z Partnerów Projektu.

4. Utworzenie, implementacja Systemu Wojewódzkiego Zasobu Geodezyjnego i Kartograficznego (System WZGIK), migracja danych systemu, obsługa płatności internetowej, który będzie służył do elektronicznej obsługi klienta, zgłoszeń prac geodezyjnych i kartograficznych oraz wniosków o udostępnienie danych z zasobu WZGiK, a także do zarządzania wojewódzkim zasobem geodezyjnym i kartograficznym.

5. System WZGiK musi spełniać następujące wymagania oraz zapewnić obsługę realizacji następujących zadań:

5.1.Pozyskiwanie, ewidencjonowanie, przechowywanie, udostępnianie oraz zabezpieczanie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego, o których mowa w §4 i §6 Rozporządzenia PZGiK,

5.2.Prowadzenie rejestru zgłoszeń prac geodezyjnych i kartograficznych,

5.3.Wsparcie i monitorowanie procesów związanych z obsługą zgłoszeń prac geodezyjnych i kartograficznych, w tym przekazywanych drogą elektroniczną,

5.4.Wsparcie i monitorowanie procesów przyjmowania, w tym kontroli materiałów i zbiorów danych, do wojewódzkiego zasobu geodezyjnego i kartograficznego,

5.5.Prowadzenie ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego, w tym tworzenie i publikację w postaci usług sieciowych metadanych dotyczących materiałów i zbiorów zasobu oraz ich aktualizację, zarządzanie, przeglądanie i wyszukiwanie wraz z integracją z geportalem OWI,

5.6.Opatrywanie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego klauzulami,

5.7.Obsługę wyłączania materiałów z wojewódzkiego zasobu geodezyjnego i kartograficznego, 5.8.Prowadzenie rejestru wniosków o udostępnienie materiałów wojewódzkiego zasobu

geodezyjnego i kartograficznego,

5.9. Integracja z systemem finansowo-księgowym i systemem Elektronicznego Zarządzania Dokumentacją (EZD);

5.10. Implementacje dedykowanych procesów prowadzenia i udostępniania materiałów z wojewódzkiego zasobu geodezyjnego i kartograficznego, w tym drogą elektroniczną, a także za pomocą usług sieciowych OGC Geoportalu OWI oraz za pomocą portalu CUW, zapewniającego co najmniej:

5.10.1. dostęp do materiałów oraz metadanych wojewódzkiego zasobu geodezyjnego i kartograficznego z możliwością ich przeglądania,

5.10.2. zgłaszanie prac geodezyjnych i kartograficznych oraz przekazywania wyników tych prac do wojewódzkiego zasobu geodezyjnego i kartograficznego,

5.10.3. składanie wniosków o udostępnienie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego oraz udostępnianie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego,

5.10.4. przyjmowanie drogą elektroniczną opłat za udostępnianie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego,

5.10.5. udostępnianie i korzystanie z usług infrastruktury informacji przestrzennej, o których mowa w art. 9 ust. 1 ustawy z dnia 4 marca 2010 r. o infrastrukturze informacji przestrzennej,

5.10.6. dostęp do wybranych usług infrastruktury informacji przestrzennej na urządzeniach mobilnych,

5.10.7. przyjazny i ergonomiczny interfejs użytkownika.

5.10.8. Integracja z systemem EZD;

5.11. Prowadzenie bazy Systemu WZGIK gromadzącej:

5.11.1. dane niezbędne do prowadzenia: rejestru zgłoszeń, ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego oraz rejestru wniosków o udostępnienie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego,

5.11.2. materiały wojewódzkiego zasobu geodezyjnego i kartograficznego w postaci dokumentów elektronicznych (oraz ścieżek do tych zasobów);

5.12. Migracja danych z istniejących systemów;

5.13. Integracja z systemami:

5.13.1. Geoportal OWI,

5.13.2. Finansowo-Księgowym,

5.13.3. Elektronicznego Zarządzania Dokumentacją w zakresie obiegu dokumentów związanych z prowadzeniem i udostępnianiem wojewódzkiego zasobu geodezyjnego i kartograficznego, w tym integrację z platformami ePUAP;

5.13.4. płatności elektronicznych:

▪ Elixir,

▪ PayByNet;

5.14. Dostarczenie e-usług na poziomie 4 w tym z wykorzystaniem danych geoprzestrzennych pochodzących z wojewódzkiego zasobu geodezyjnego i kartograficznego prezentowanych na Geoportalu OWI;

5.15. Zapewnienie minimalnych wymagań dla systemów teleinformatycznych określone w przepisach wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne;

5.16. Realizacja systemu musi być poprzedzona następującymi działaniami:

5.16.1. Opracowanie struktury bazy danych koniecznej do zaimplementowania Systemu WZDGiK i jego elementów, zgodnej z obowiązującymi przepisami prawa i uwzględniającej konieczność przeprowadzenia integracji z bazami danych i systemami dziedzinowymi funkcjonującymi w Województwie Opolskim (WODGiK Opole),

5.16.2. Przeprowadzenie migracji danych koniecznych do uruchomienia i wdrożenia Systemu WZGIK,

5.16.3. Utworzenie metadanych dla Wojewódzkiego Zasobu Geodezyjnego i Kartograficznego oraz metadanych RDF dla wybranych zbiorów i usług.

6. Modernizacja Geoportalu OWI

Fundamentalnym elementem Projektu jest integracja i wykorzystanie zrealizowanego projektu

„Opolskie w Internecie (OWI) – system informacji przestrzennej”. Jest to Regionalna Infrastruktura Informacji Przestrzennej województwa opolskiego, projekt Współfinansowany przez Unię Europejską ze środków Funduszu Rozwoju Regionalnego oraz środków budżetu województwa opolskiego w ramach działania 2.2 Regionalnego Programu Operacyjnego Województwa Opolskiego na lata 2007-2013. Modernizacja geoportalu musi zachować wszystkie dotychczasowe funkcjonalności.

Modernizacja funkcjonującego systemu Regionalnej Infrastruktury Informacji Przestrzennej, tj. Systemu OWI stanowiącej element wspólny Wojewódzkiego Węzła Integrującego oraz Systemu WZGIK (w tym utworzenie, konwersja i migracja istniejących danych i usług sieciowych) poprzez minimum dostawę, implementację elementów typu :

6.1. Budowa lub udoskonalenie usługi umożliwiającej wyszukiwanie obiektów w Geoportalu OWI, w tym:

-obiektów Centralnej Bazy Danych np. :działki, obiekty istotne dla służb ratowniczych,

- działki wykorzystując usługę zintegrowaną działek (xxxxxxxxx.xxx.xx),

-numeru porządkowego nieruchomości, wykorzystując usługę zintegrowanych numeracji porządkowej nieruchomości (xxxxxxxxx.xxx.xx).

6.2. Utworzenie usług sieciowych zgodnych z aktualnymi wersjami standardów OGC (x.xx.: WMS, WMSC ,WMTS , REST, ECWP, WFS ,REST, WCS, CSW, WCTS, WMC,WPS.Usługi powyższe powinny być kompatybilne również z poziomu geoportalu krajowego.

6.3. Utworzenie usług w standardzie OGC, w tym usług bazujących na nowych opracowaniach topograficznych i tematycznych oraz usług bazujących na funkcji czasu.

6.4. Utworzenie aplikacji www do uproszczonej aktualizacji wybranych danych w Centralnej Bazy Danych przez autoryzowanych użytkowników wewnętrznych i zewnętrznych (np. departamenty UMWO, służby ratownicze) wraz z możliwością tworzenia własnych procesów biznesowych tzw.workflow.

6.5. Zapewnienie bezpieczeństwa przetwarzania i udostępniania danych.

6.6. Zapewnienie minimalnych wymagań dla systemów teleinformatycznych określone w przepisach wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.

6.7. Modernizacja struktury bazy danych koniecznej do zaimplementowania Systemu OWI i jego elementów, zgodnej z obowiązującymi przepisami prawa i uwzględniającej konieczność przeprowadzenia integracji z bazami danych i systemami dziedzinowymi.

6.8. Przeprowadzenie migracji danych oraz zasilenie nowzmi danymi niezbdnymi do uruchomienia i wdrożenia Szstemu OWI.

6.9. Utworzenie metadanych dla dla wybranych zbiorów i usług.

6.10. Utworzenie wersji mobilnej strony Geoportalu.

6.11. Realizacja procesu udostępnienia materiałów wzgik z wykorzystaniem geoportalu poprzez wybranie materiałów zasobu z mapy oraz jego automatyczne przygotowanie do postaci pliku (w tym wypełnienie wniosku o wybrane elementy) i przesłanie wniosku do kolejnego etapu procedury.

6.12. Modernizacja elementów: Serwer Danych Przestrzennych OWI, Moduł Zarządzania Danymi, Repozytorium Danych OWI wraz z niezbędnymi pracami implementacyjnymi, w tym migracja danych.

6.13. Rozbudowa obecnej strony startowej w kontekście informacyjnym oraz dostosowana do wymogów WCAG 2.0 (Web Content Accessibility Guidelines) - wytyczne dotyczące ułatwień w dostępie do treści publikowanych w Internecie.

7. Utworzenie Wojewódzkiego Węzła Integrującego (WWI) będącego bramką dostępową do e-usług wszystkich Partnerów projektu w oparciu o następujące założenia:

7.1. Rolę WWI spełnia portal Centrum Usług Wspólnych (CUW) udostępniający e-usługi poszczególnych Partnerów Projektu poziomu powiatowego oraz wojewódzkiego.

7.2. E-usługi poziomu wojewódzkiego dostarczane są przez System WODGiK.

7.3. CUW wykorzystuje geoportal OWI, za pośrednictwem którego udostępniane są zbiory i usługi danych przestrzennych oraz informacje o e-usługach wszystkich Partnerów Projektu.

7.4. WWI składa się z następujących elementów:

7.4.1. Moduł Bezpieczeństwa Usług Sieciowych,

7.4.2. Portal CUW,

7.4.3. Centralną Bazę Danych CUW,

7.4.4. Moduł Administracji CUW,

7.4.5. Broker e-usług PODGIK,

7.4.6. Repozytorium Tożsamości CUW,

7.4.7. Moduł ETL,

7.4.8 .Serwer Metadanych,

7.4.9. Centralna Baza Danych CUW.

8. Asysta Techniczna i Gwarancja dla części wojewódzkiej.

9. Przeprowadzenie wdrożenia i testów :

9.1. wdrożenia preprodukcyjnego i testów akceptacyjnych,

9.2. wdrożenia produkcyjnego i testów zatwierdzających.

10. Opracowanie dokumentacji powdrożeniowej, w tym dokumentacji technicznej, dokumentacji użytkownika oraz dokumentacji administratora Systemu.

11. Przeprowadzenie instruktażu dla grupy użytkowników i administratorów Systemu.

12. Przeprowadzenie szkoleń z rozwiązania CUW w zakresie części dedykowanej województwu.

III. Ogólny opis realizacji elementów projektu

Elementy: WWI, System OWI oraz System WZGIK muszą być ze sobą zintegrowane. Element PWI również musi być zintegrowany z wybranymi elementami WWI.

Portal CUW

Portal CUW jest miejscem, z którego klient rozpoczyna realizację e-usługi i w której kończy proces. Procesy są fizycznie realizowane przez odpowiednie miejscowo i rzeczowo organy administracji publicznej. Portal CUW jest miejscem kontaktowym dla klienta dla realizowanych procesów. W portalu CUW klient musi zobaczyć opis usług, opis procesu, przestrzenny zasięg występowania danej usługi, informację o konieczności realizacji płatności, która odbywa się dla każdego z organów administracji publicznej niezależnie. Klient musi zostać poinformowany na wstępie oraz w trakcie realizacji procesu/ow na jakim etapie jest dana sprawa/y i jakie kroki ma dalej poczynić aby sfinalizować sprawę u danego Partnera. Klient nie musi logować się na początku. Ma wybór. Zanim zostanie poproszony o zalogowanie się może przeglądać dostępnie informacje przykładowe próbki oraz zasięgi występowania zbiorów i usług i e-usług. Może również realizować część zamówienia w zakresie materiałów zasobu, zweryfikować wstepna wycenę i dopiero wtedy się zalogowac i złożyć wniosek/ki do odpowiedmniego organu.

Rozwiązanie powyższe nie wyklucza równoległej indywidualnej ścieżki realizacji sprawy. Poniżej przedstawiono przykładowy schemat przebiegu jednej z form realizacji wniosku w zakresie wojewódzkiego zasobu geodezyjnego i kartograficznego (formularz W/W1 w formie elektronicznej).

Centralna Baza Danych CUW służy do zarządzania danymi przestrzennymi (gromadzenie, przetwarzanie i udostępnianie) udostępnianymi przez Partnerów Powiatowych dla celów realizacji e usług w CUW oraz zadań statutowych UM Województwa oraz zarządzania użytkownikami. Dane gromadzone w CBD CUW wykorzystywane są przez poszczególne komponenty systemu, w tym serwery e-usług, serwer metadanych, moduł ETL, LDAP, system WZGiK, portal mapowy (geoportal OWI). CBD stanowi podstawowy elementem CUW, w którym magazywnowane są zasoby udostępnione użytkownikom systemu poprzez Dostawcę danych przestrzennych wojewódzkich. Z CBD CUW korzystają bezpośrednio aplikacje projektu OWI, w tym Geoportal. Szczegółowe wymagania znajdują się w dalszej części dokumentacji.

W ramach projektu przewiduje się powstanie zintegrowanej bazy danych grupującej dane w zależności od miejsca węzła, w którym powstają oraz w zależności od sposobu ich wykorzystania (np. Dane Referencyjne, System WZGIK, Portal CUW, publikacja w Geoportalu OWI, dane z PWI).

Architektura CBD ma zapewnić bezpieczeństwo danych oraz ochronę przed nieuprawnionym dostępem. Moduły udostępniane publicznie mają dostęp do specjalnie spreparowanych danych pozbawionych wrażliwych atrybutów.

Wykonawca systemu powinien w maksymalny sposób ma wykorzystać istniejącą infrastrukturę serwerową i środowisko baz danych Zamawiającego lub w przypadku konieczności zastosowania rozwiązań alternatywnych uzgodnić je z Zamawiajacym. System bazodanowy musi zapewnić skalowalność pionową i poziomą w zakresie wykorzystania infrastruktury.

Moduł Administracji CUW

Moduł Administracji CUW to jednolita platforma zarządzająca usługami i danymi udostępniania e usług, zapewniająca:

• centralne zarządzanie użytkownikami i ich uprawnieniami,

• zabezpieczanie usług udostępniających dane,

• monitorowanie wydajności i niezawodności usług,

• replikację i harmonizację danych.

Platforma będzie zbiorem oprogramowania narzędziowego, które służy administratorom do zarządzania wszystkimi komponentami budowanej infrastruktury węzła. Szczegółowe wymagania odnośnie Modułu Administracji CUW znajdują się w dalszych rozdziałach.

Moduły replikacji i harmonizacji ETL

Zarządzanie migracją zbiorów danych pomiędzy bazami realizowane jest przez narzędzia ETL na których to będą zbudowane odpowiednie schematy migracji i weryfikacji danych tak jak w narzędziach ETL powiatowych węzłów.

Dane transferowane z powiatowych baz danych ewidencji gruntów i budynków muszą być pozbawione treści dotyczących danych osobowych. Zintegrowane dane będą wykorzystane do realizacji zadań WWI, w tym Systemu OWI (np. do wsparcia procesu automatycznego wypełnienia wniosku w tym określenia zasięgu przestrzennego w geoportalu OWI poprzez przestrzenne wyszukanie adresu, wskazanie działki lub powiatu przed złożeniem wniosku i w trakcie składania wniosku), do części informacyjnej, w procesie wyboru organu do którego będzie kierowany wniosek.

Dane do realizacji zadań WWI muszą być zasilane w sposób umożliwiający częstą lub on-line ich aktualizację (np. wms lub eksport wybranych elementów baz danych).

Dane te będą również wykorzystane do realizacji zadań województwa ( np. prowadzenia bazy danych BDOT10k oraz analizy struktury władania i użytkowania gruntów- działki, budynki, użytki, klasoużytki, grupy i podgrupy rejestrowe). Dane do realizacji zadań województwa wymagają szerszego zakresu baz danych oraz bardziej złożonej formy ich przekazania zawierającej dane i relacje wynikające ze schematu bazy danych (np. GML, WFS).

Zadaniem WWI jest pobieranie z powiatowych komponentów ETL udostępnionych i przygotowanych wybranych danych celem zapisu i w Centralnej Bazie Danych CUW. Formaty danych i usług sieciowych w jakich będą wymieniane dane oraz sposób zapisu w CBD CUW zostanie określona z Zamawiającym na etapie analizy i projektu technicznego. Z uwagi na czasochłonność procesów eksportów, specyfikę kilku systemów Partnerów Powiatowych, wielkość baz danych, cel jakiemu mają służyć zintegrowane dane rozwiązanie na etapie Koncepcji należy dostosować do częstotliwości i zakresu przekazywanych danych.

W portalu CUW klient będzie logował się raz. Repozytorium tożsamości CUW powinno umożliwiać transfer danych i ich synchronizację, aby nie dublować danych klienta w systemie EZD i systemach dziedzinowych.

Jest to istotny moduł systemu, gdyż odpowiedzialny jest za przepływ danych przestrzennych dla i z wszystkich węzłów. Pomimo iż w każdym węźle występuje w różnym charakterze, jest to identyczne funkcjonalnie rozwiązanie zbudowane z wykorzystaniem oprogramowania ETL. Jego uszczegółowienie zależy od położenia modułu w architekturze Systemu oraz od zadań a dokładnie zbiorów danych które przetwarza. W zależności od źródła danych w ramach projektu powinny powstać odpowiednie schematy pobierania, aktualizacji, harmonizacji danych przestrzennych z każdego z węzłów powiatowych, oraz wojewódzkich. Wiele z tych schematów będzie powielona w wielu węzłach a szczególnie tam gdzie będą identyczne systemy wewnętrzne, źródłowe. Ze względu na uniwersalność narzędzia będzie możliwość rozszerzenia zakresu danych przestrzennych, które System będzie przetwarzał czy to na potrzeby lokalne czy na potrzeby całego Systemu. Każdy zbiór powstały w ramach owego Systemu powinien być przechowywany lokalnie zaś jego kopia przekazywana do repozytorium węzła centralnego.

E- usługi o czwartym stopniu dojrzałości w ramach Centrum Usług Wspólnych

Każda udostępniania e-usługa zasobu geodezyjnego i kartograficznego stanowi oddzielny moduł (aplikację) świadczący użytkownikom konkretny zakres usług. Procesy realizowane w ramach konkretnych usług mogą korzystać ze wspólnych zasobów lub innych usług zewnętrznych przykładowo usług Udostępniania danych przestrzennych, usługi obsługi podpisu kwalifikowanego,

profilu zaufanego czy bramki płatności elektronicznych. Podstawowa korzyść e-usług w tym Projekcie to fakt, że klient w jednym miejscu uzyska informację o zasobach geodezyjnych i kartograficznych województwa opolskiego szczebla powiatowego i wojewódzkiego i w jednym miejscu uzyska odpowiedź od wybranej liczby (właściwych miejscowo lub rzeczowo) Partnerów (organów administracji publicznej).

Wymagania ogólne

Utworzenie CUW wymaga zbudowania rozwiązań integracyjnych poprzez odpowiednią rozbudowę OWI oraz stworzenia integracyjnego węzła powiatowego. Ze względu na administrację rozwiązania zalecane jest aby każdy z Partnerów powiatowych posiadał identyczny węzeł integrujący. Węzeł integrujący będzie składał się z serwera aplikacji, serwera usług danych przestrzennych zintegrowanych z niezależnym środowiskiem bazodanowym. W ramach rozwiązań bazodanowych będzie okresowo (ustalenia indywidualne na etapie implementacji) wykonywana synchronizacja danych oraz metadanych przestrzennych z powiatu do bazy danych w ramach powiatowego węzła integrującego - odpowiednia duplikacja. Inteligentne duplikowanie danych jest realizowane ze względów bezpieczeństwa, gdyż nie przewiduje się udostępnienia za pomocą e-usług danych z bazy danych produkcyjnych, dziedzinowych systemów Partnerów Projektu. Przewiduje się również możliwość synchronizacji odpowiednich danych z baz danych integracyjnego węzła powiatowego bezpośrednio do bazy danych zlokalizowanej w części wojewódzkiej CUW.

Pod kątem przekazywania danych do wojewódzkiego węzła integrującego i e-usług Portalu CUW, powiatowy dostawca danych przestrzennych powinien spełniać wymagania funkcjonalne realizujące założenia projektu, tj. minimum najnowsze wersje:

• udostępnianie usługi sieciowej przeglądania powiatowych danych przestrzennych w standardzie WMS, w postaci „kafelek” w standardzie WMTS,

• udostępnienie możliwości pobierania powiatowych danych wektorowych za pomocą usługi sieciowej WFS,

• udostępnienie możliwości pobierania powiatowych danych rastrowych za pomocą usługi sieciowej WCS,

• udostępnianie usługi przeszukiwania metadanych – CSW, w zakresie danych przetwarzanych w węźle powiatowym.

Pod kątem obsługi wojewódzkiego węzła integrującego i e-usług Portalu CUW, WWI (geoportal OWI) powinien spełniać minimum wymagania funkcjonalne opisane w dalszej częśći dokumentu.

Metadane powiatowe powinny być również możliwe do wyszukania w geoportalu OWI, aby informacje były dostępne również dla klienta Portalu CUW w momencie wyboru elementów zasobu do składanego wniosku.

Pod kątem pobierania danych z powiatowych baz danych przestrzennych do baz danych powiatowego węzła integrującego wymagania nie definiują usług, za pomocą których komunikacja powinna być realizowana, ze względu na różne realizacje fizyczne powiatowych baz danych. Niemniej jednak w zakresie komunikacji ze źródłowymi powiatowymi bazami danych, powiatowe węzły integrujące powinny spełniać następujące wymagania funkcjonalne:

• zapewnienie możliwości pobierania danych z odpowiednich baz danych w trybie „na żądanie” za pośrednictwem aplikacji do obsługi danych przestrzennych,

• zapewnienie możliwości stawiania zapytań o dane w celu selekcji żądanych danych do pobrania.

• Moduł Administracji - tak jak Moduł Administracji CUW

• Integracja z systemami (w zależności od posiadanych systemów i stopnia integracji z nimi u poszczególnych Partnerów Projektu):

• Finansowo-księgowymi,

• Elektronicznego Zarządzania Dokumentacją (EZD),

Poniżej przedstawiono przykład procesu, w którym występują elementy integracji z systemami.

Zapewnienie systemu do zarządzania wojewódzkim zasobem geodezyjnym i kartograficznym

Na poziomie wojewódzkim utworzony zostanie System WZGiK, który będzie służył do elektronicznej obsługi wniosków i zgłoszeń, które trafiają do Systemu, a także do zarządzania ewidencją zasobu. Podstawowymi funkcjonalnościami Systemu będą:

• Zarządzanie zasobem – w tym x.xx. ewidencjonowanie materiałów i dokumentów, zarządzanie stanem magazynowym i przeprowadzanie inwentaryzacji, generowanie raportów, weryfikacja autentyczności licencji oraz Dokumentów Obliczenia Opłaty, generowanie metadanych oraz klauzul XML.

• Obsługa zgłoszeń prac geodezyjnych i kartograficznych – w tym x.xx. wycena i wygenerowanie DOO oraz licencji, wydanie materiałów niezbędnych do wykonania pracy, przyjęcie zawiadomienia o wykonaniu pracy i wydanie protokołu kontroli.

• Obsługa wniosków o udostępnienie danych z zasobu WODGiK – w tym x.xx. automatyzacja przygotowania wybranych elementów zasobu z wykorzystaniem geoportalu, automatyzacja wypełniania wniosku, wycena i wygenerowanie DOO oraz licencji, wydanie materiałów

• Zarządzanie modułem WZGiK – w tym x.xx. zarządzanie pozycjami słownikowymi i cenowymi.

Obecnie WODGiK, w przeciwieństwie do pozostałych Partnerów Projektu, nie posiada dziedzinowego systemu informatycznego przeznaczonego do obsługi w/w zadań. Zapewnienie takiego rozwiązania jest konieczne z punktu widzenia celów Projektu, w zakresie automatyzacji procesów i docelowego powiązania z Centrum Usług Wspólnych. Zapewnienie takiego rozwiązania jest również wymagane przepisami prawa (Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego).

Ze względu na obowiązujący system zniżek bądź możliwość bezpłatnego udostępniania materiałów zasobu dla określonych rodzajów odbiorców, system musi zawierać rozwiązanie wymuszające zdeklarowanie przez użytkownika w jakim charakterze (profilu) korzysta z systemu. Deklaracja profilu pozwoli na właściwe dopasowanie oferty do określonego rodzaju użytkownika, w tym zakres dostępu do określonych zasobów, zastosowanie właściwych stawek opłat za udostępnienie zasobów lub zakres danych dostępnych nieodpłatnie.

Metadane WZGIK

a)Wykonawca zaktualizuje bazę metadanych dla zbiorów i usług sieciowych, utworzy metadane dla zaewidencjonowanych materiałów zasobu oraz utworzy usługę katalogową.

Wykonawca wykona analizę zasobów danych przestrzennych, na co składa się: identyfikacja i ustalenie zasobów koniecznych do opisania metadanymi, uzgodnienie i przydzielenie zbiorom, seriom i usługom wybranych słów kluczowych. Wymagana jest akceptacja Zamawiającego w zakresie wykonania powyższego zakresu zadań.

b) Utworzy metadane w formacie XML zgodnie z profilem metadanych zawartym w Rozporządzeniu:

- utworzy na podstawie zebranych i uporządkowanych metadanych pliki XML,

- dokona walidacji utworzonych metadanych oraz przygotuje raport z walidacji.

c) Dokona konfiguracji i uruchomienia usługi wyszukiwania (katalogowej) oraz publikacji metadanych, na co składa się:

- konfiguracja usługi CSW,

- import metadanych do bazy danych usługi katalogowej,

- publikacja usługi katalogowej,

- uruchomienie usługi wyszukiwania (katalogowej) na serwerze Zamawiającego,

- testy poprawności działania usługi wyszukiwania i ewentualne korekty.

Metadane RDF

Wykonawca utworzy metadane RDF oraz je opublikuje dla wszystkich e-usług powiatowych i wojewódzkich, rejestru BDOT 10K oraz wybranych 4 usług sieciowych publikowanych w geoportalu OWI. Celem utworzenia metadanych RDF jest zwiększenie efektywności wyszukiwania informacji na temat dostępnych zasobów i e-usług województwa opolskiego zgodnie z ideą danych połączonych (ang. Linked Data), udostępnienie informacji w postaci dokumentów HTML wraz z semantycznymi adnotacjami.

Proces utworzenia metadanych RDF będzie polegał na:

1) opracowaniu ontologi dla zbiorów danych przestrzennych;

2) dokonaniu konwersji wybranych zbiorów danych przestrzennych do modelu RDF;

3) opublikowaniu danych opracowanych w modelu RDF (w repozytorium CKAN oraz w bazie danych AllegroGraph);

4) utworzeniu relacji semantycznych pomiędzy stworzonymi zasobami RDF, a zasobami dostępnymi w sieci WWW.;

5) opublikowaniu danych w postaci dokumentów HTML wraz z semantycznymi adnotacjami;

Dane połączone, dokumenty HTML muszą być opracowane z wykorzystaniem najnowszych standardów i praktyk W3C i OGC w zakresie technologii sieci semantycznych i danych połączonych tj. GeoSPARQL, XXX, XXX, XXXX, SPARQL.

W ramach prac zostanie opracowana baza wiedzy, na którą będą składały się: część terminologiczna (ang. T-Box), czyli opracowane ontologie oraz część asercyjna (A-Box), w której zgromadzone zostaną konkretne instancje (obiekty przestrzenne).

Etapy prac:

1. Opracowanie ontologii dla wybranych zbiorów i usług

Ontologie będą reprezentowane w językach z zakresu technologii sieci semantycznych tj. OWL2 lub RDFS. Wybór języka służącego do opisu danych będzie dokonany przez Wykonawcę, po szczegółowym przeanalizowaniu zakresu informacyjnego danych.

2. Konwersja zbiorów danych przestrzennych do modelu RDF zgodnie z opracowanymi ontologiami

Należy dokonać konwersji wybranych zbiorów i usług Zamawiającego do modelu RDF.

Proces konwersji będzie obejmował konfigurację mapowania do postaci semantycznej. W procesie konwersji do opisu części terminologicznej, będą wykorzystane opracowane ontologie. Obowiązkowe jest również wykorzystanie ontologii zewnętrznych służących do opisu danych, tj. standard OGC GeoSPARQL, Dublin Core, SKOS i inne, w zależności od specyfiki. W ramach prac należy również opracować, w porozumieniu z Zamawiającym, zasady nadawania obiektom przestrzennym w modelu RDF unikalnych identyfikatorów (URI).

Dla powstałych zasobów RDF należy opracować metadane w formacie RDF, zawierające podstawowe informacje o publikowanych zbiorach i usługach, np. autor, data utworzenia. Do opisu metadanych wykorzystać należy ontologię Dublin Core.

3 Publikowanie danych w modelu RDF

Opracowane zbiory i usługi w modelu RDF należy opublikować w repozytorium CKAN oraz w bazie danych AllegroGraph. Dane zostaną opublikowane w ten sposób, aby zapewniony był dostęp do danych poprzez usługę dostępu – SPARQL endpoint. 4 Utworzenie relacji semantycznych pomiędzy obiektami przestrzennymi a zewnętrznymi zasobami internetowymi

Należy utworzyć powiązania pomiędzy stworzonymi zasobami RDF, a zasobami dostępnymi w sieci WWW. Wymagane jest utworzenie połączeń pomiędzy zbiorami i usługami Zamawiającego, a zbiorami pochodzącymi z zewnętrznych serwisów oferujących dane w formacie RDF np. Geonames, DBpedia, GEMET, dane RDF pochodzące z OpenStreetMap.

5 Publikowanie w postaci dokumentów HTML wraz z semantycznymi adnotacjami

W celu zwiększenia efektywności wyszukiwania opracowanych danych połączonych w sieci WWW z wykorzystaniem powszechnie wykorzystywanych wyszukiwarek tj. Google, Yahoo, obiekty będą reprezentowane w postaci HTML wraz z semantycznymi adnotacjami w postaci RDFa lub Microformats.

Wymagania w zakresie ontologii:

1. Ontologie mają być sformalizowane przy pomocy formalnego języka reprezentacji wiedzy w standardach Semantic Web tj. język OWL2 lub RDFS.

2. Zakres informacyjnych elementów języka OWL2 musi obejmować co najmniej klasy, właściwości i instancje.

3. Ontologie muszą być zserializowane z wykorzystaniem notacji RDF/XML.

4. Ontologie muszą być opracowane zgodnie z dobrymi praktykami tworzenia ontologii przy zastosowaniu wybranej, powszechnie znanej metodologii, przy czym etapy tworzenia ontologii muszą obejmować etapy konceptualizacji, formalizacji i ewaluacji.

5. Ontologie powinny wykorzystywać ontologie lub słowniki zewnętrzne np. standard SKOS (Simple Knowledge Organization System) czy GeoSPARQL.

Wymagania odnośnie zbiorów i usług:

1. Wymagana jest reprezentacja danych w modelu RDF (Resource Description Framework), co najmniej w serializacjach RDF/XML lub Turtle.

2. W przypadku posiadania informacji o geometrii wymagany jest zapis geometrii publikowanych zasobów przestrzennych. Geometria może być reprezentowana zgodnie ze standardem GeoSPARQL lub ontologią WGS84 Basic Geo (WGS84 lat/long)

3. Nazwy zasobów dla konwertowanych obiektów przestrzennych powinny być reprezentowane w postaci unikalnych, identyfikatorów URI (Uniform Resource Identifier)

4. Identyfikatory URI powinny być dereferowalne.

5. Wymagane jest opracowanie zasad tworzenia identyfikatorów URI dla publikowanych zasobów.

6. Publikowane dane muszą być powiązane za pomocą relacji semantycznych z innymi zasobami zewnętrznymi (np. DBpedia, Geonames, GEMET, OSM).

Wymagania w zakresie dokumentów HTML:

1. Dokumenty HTML muszą posiadać semantyczne adnotacje z wykorzystaniem standardu RDFa lub Microformats

2. Wymagane jest zdefiniowanie powiązań do innych zasobów zewnętrznych, np. pochodzących z DBpedii, Geonames.

3. Wymagane jest osadzenie w dokumencie HTML mapy z wizualizacją zasięgu przestrzennego danych lub usługi.

IV.Wymagania dotyczące budowy Systemu WZGIK oraz Wojewódzkiego węzła integrującego

a. Interoperacyjność ODGIK i CUW

Identyfikator	Opis Wymagania
	CUW
INT. 1.	Podstawą dla realizacji Systemu muszą być wymagania zawarte w rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (KRI).
INT. 2.	Interoperacyjność Systemu musi być zagwarantowana poprzez jego budowę w modelu usługowym (§ 8.1. KRI), zorientowanym na świadczenie e-usług (Service Oriented Architecture – SOA), w którym wszystkie funkcjonalności systemu teleinformatycznego dostępne są z poziomu przeglądarki internetowej, bez konieczności instalowania jakiegokolwiek oprogramowania po stronie użytkownika korzystającego z Systemu.
INT. 3.	Interoperacyjność Systemu musi być osiąganą poprzez: • jego jednolitość, rozumianą jako stosowanie kompatybilnych norm, standardów i procedur przez różne jednostki realizujące zadania publiczne, posiadające dostęp do Systemu, • jego zgodność, rozumianą jako przydatność produktów, procesów lub usług przeznaczonych do ich wspólnego użytkowania. Interoperacyjność Systemu musi być osiągana na poziomach: • organizacyjnym, gwarantującym: o dostęp do aktualnego Systemu, o przepływ informacji w Systemie, • semantycznym, gwarantującym: o stosowanie struktur danych i znaczenia danych w tych strukturach, zgodnych z KRI, o stosowanie jednolitych i zgodnych modeli danych Systemu, o wzajemną referencyjność i harmonizację danych Systemu, • technologicznym, gwarantującym: o jednolitość zastosowanych rozwiązań technologicznych Systemu, o neutralność technologiczną Systemu.
INT. 4.	Interoperacyjność zbiorów danych przestrzennych musi być zapewniona poprzez stosowanie regulacji zawartych w przepisach odrębnych, a w przypadku ich braku

	uwzględnienia postanowień odpowiednich Polskich Norm, norm międzynarodowych lub standardów uznanych w drodze dobrej praktyki przez organizacje międzynarodowe (§ 5. 4. KRI), w tym: • zapewniać dostęp do danych przestrzennych zawartych w Systemie zgodnie ze standardami OGC, gwarantując wyświetlanie/edycje map z wykorzystaniem standardowych e-usług np.:WMS/WFS, • zapewniać integrację danych przestrzennych zawartych w Systemie zgodnie ze standardami OGC, gwarantując tworzenie dowolnych kompozycji mapowych z wykorzystaniem standardowych e- usług, np.: WMS/WFS, • zapewniać stosowanie otwartych i jawnych formatów zapisu danych przestrzennych zgodnie z normą PN-EN-ISO 19125-2 - Informacja geograficzna – Środki dostępu do obiektów prostych (odpowiednik - Standard OGC: OpenGIS Simple Features - SQL - Types and Functions), gwarantującą neutralność technologiczną i jawność używanych standardów i specyfikacji zapisu danych przestrzennych w Systemie.
INT. 5.	System musi zapewniać realizację zasadę re-use, czyli rozwiązania z zakresu ponownego wykorzystania informacji na wielu poziomach, w tym na poziomie organizacyjnym, semantycznym i technologicznym.
INT. 6.	System musi pozwalać na wzajemne udostępnianie online danych Systemu, tak, aby nie kopiować i nie powielać zasobów utrzymywanych przez poszczególne Moduły, a tym bardziej uniknąć ich wielokrotnego i kosztownego opracowywania, a jednocześnie zapewniać ich wiarygodność i aktualność.
INT. 7.	System musi zapewniać zgodność z dyrektywą INSPIRE i Ustawą z dnia 4 marca 2010 r. o infrastrukturze informacji przestrzennej.

b. Wymagania ogólne

Identyfikator	Opis Wymagania
	CUW
CO.1.	Portal CUW musi zapewniać dostęp do e-usług, wdrożonych u wszystkich 13 Partnerów Projektu, w ramach Projektu w tym: • 5 e-usług WODGiK Opole, • 12 e-usług PODGIK Partnerów Projektu.
CO.2.	Interfejs Portalu CUW oraz Portalu WZGIK musi być zgodny ze standardami WCAG 2.0 (Web Content Accessibility Guidelines) z uwzględnieniem poziomu AA, co zapewni, że udostępniane dzięki systemowi treści i usługi będą dostępne dla osób

	niepełnosprawnych.
CO.3.	Przed podpisaniem Umowy, Wykonawca przedstawi Zamawiającemu wykaz wszystkich niezbędnych licencji oraz zestawienie ewentualnych niezbędnych opłat w latach kolejnych związanych z bieżącym utrzymaniem.z. W sytuacji, gdy Zamawiający nie zgodzi się na wykorzystywanie danego rozwiązania/danej licencji, Wykonawca w porozumieniu z Zamawiającym wybierze inne, dogodne dla Zamawiającego rozwiązanie.
CO.4.	Dostęp do Portalu CUW oraz Portalu WZGiK oraz jego funkcjonalności musi być możliwy bez konieczności posiadania konta użytkownika. (szczegółowy zakres dostępu publicznego zostanie określony w pierwszym etapie projektu i zapisany w projekcie technicznym).
CO.5.	Wykonawca zapewni system zarządzania treścią Portalu CUW i Portalu WZGIK(CMS – Content Management System). System CMS musi posiadać wbudowane zabezpieczenia (x.xx. ochrona przed próbą nieautoryzowanego dostępu do panelu sterowania, panel administracyjny dostępny poprzez połączenie szyfrowane), narzędzie do edycji treści w trybie WYSIWYG, usuwanie/podmiana/wersjonowanie dokumentów, podgląd Portalu CUW przed publikacją treści.
CO.6.	Wymaga się aby Portal CUW oraz Portal WZGIK były skalowalne, umożliwiając obsługę zwiększającej się liczby użytkowników i dokumentów oraz udostępniając mechanizmy „load balancing”, cache stron i „failover”.
CO.7.	Portal CUW oraz Portal WZGIK musi być zgodny z aktualnie obowiązującymi przepisami i wytycznymi, w tym przede wszystkim: • ustawą z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (tj. Dz.U. z 2017 r. poz. 570) wraz z aktami wykonawczymi; • ustawą z 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (tj. Dz.U. z 2017 r. poz. 1219 z późn. zm) wraz z aktami wykonawczymi; • ustawą z dnia 10 maja 2018 r. o ochronie danych osobowych (tj. Dz. U. z 2018 r., poz. 1000 z późn. zm.); • rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE; • rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2012 poz. 526 z późn. zm.).

	• Wykonawca zapewni zgodność Portalu CUW oraz Portalu WZGIK z przepisami UE dotyczącymi obowiązków informacyjnych w zakresie zaprojektowania i oznaczania stron internetowych oraz Wytycznymi ministra właściwego ds. rozwoju ww. zakresie, w szczególności Podręcznikiem wnioskodawcy i beneficjenta programów polityki spójności 2014-2020 w zakresie informacji i promocji z dnia 14 czerwca 2016r., a także uwzględni estetykę charakterystyczną dla stron internetowych urzędów administracji publicznej.
CO.8.	Zamawiający dostarczy Wykonawcy elementy graficzne związane z realizacją projektu x.xx. logotypy, które Wykonawca jest zobowiązany uwzględnić w projekcie graficznym Portalu CUW, portalu WZGIK oraz Geoportalu OWI.
CO.9.	Wykonawca przedstawi Zamawiającemu do akceptacji: projekty graficzne, layouty, mockupy, przed jego uruchomieniem.
CO.10.	Dostęp do Portalu CUW, Portalu WZGIK, Geoportalu OWI musi być możliwy przez 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku w roku poprzez sieć Internet z wykorzystaniem przeglądarki internetowej, przy zachowaniu wymogów bezpieczeństwa informacji.
CO.11.	Portal CUW, Portal WZGIK, Geoportal OWI muszą umożliwiać dostęp do wszystkich zawartych w nim informacji poprzez przeglądarkę internetową: • Graficzny interfejs (GUI) musi być poprawnie interpretowany i wyświetlany przez przeglądarki: Microsoft Edge, Google Chrome, Mozilla Firefox, Safari, Opera oraz ich odpowiedniki w wersjach mobilnych wspieranych przez producentów na moment odbioru, • GUI jest skalowalny do różnych rozdzielczości ekranu (responsywny).
CO.12.	Dopuszcza się, aby rolę aplikacji mobilnej pełniła wersja dostępna on-line o odpowiedniej responsywności i dostosowaniu ergonomii do pracy w mniejszych rozdzielczościach.
CO.13.	Do poprawnego działania, nie może być wymagana instalacja żadnego dodatkowego oprogramowania na stacji roboczej klienta.
CO.14.	interfejs użytkownika.musi być prosty i przejrzysty.
CO.15.	Wykonawca zapewni mechanizm, umożliwiający szybkie uruchomienie wyświetlania informacji o czasowej niedostępności Portalu CUW i portalu WZGIK z przyczyn technicznych.
CO.16.	Utrzymywanie i prowadzenie: Portalu CUW i Portalu WODGIK oraz Geoportalu OWI musi być realizowane w infrastrukturze Zamawiającego. Uruchomienie wraz ze

	wszystkimi niezbędnymi elementami w infrastrukturze Zamawiającego przeprowadzi Wykonawca pod nadzorem i zgodnie z zasadami bezpieczeństwa Zamawiającego
CO.17.	Zamawiający udostępni Wykonawcy, niezbędną posiadaną dokumentację i dostęp do elementów do których Wykonawca ma obowiązek zintegrowania.
CO.18.	Wykonawca przeniesie na Zamawiającego prawa autorskie rozumianego jako utwór w rozumieniu ustawy o prawach autorskich i prawach pokrewnych, w tym przeniesienie praw autorskich do projektu graficznego, kodu źródłowego, elementów graficznych oraz oprogramowania CMS wraz z kodem źródłowym do tego oprogramowania.
CO.19.	Kody źródłowe oraz oprogramowania CMS muszą być jawne i dostarczone w takiej postaci, aby Zamawiający był w stanie prześledzić funkcjonowanie x.xx. pod kątem bezpieczeństwa.
CO.20.	Wraz z rozwiązaniem, Wykonawca dostarczy narzędzia do administrowania (konfiguracja, ustalanie praw dostępu, wersjonowanie, postępowanie w przypadku awarii, backup & restore). . Narzędzia nie mogą wymagać specjalistycznej wiedzy od administratora, który będzie z nich korzystał.
CO.21.	Wykonawca jest zobowiązany do ścisłej współpracy z Zamawiającym, który udostępni Wykonawcy: • Specyfikację adresów URL do poszczególnych KEU, w celu umożliwienia bezpośredniego przekierowania do konkretnych e-usług obsługiwanych przez dany KEU; • Opisów technicznych i koncepcji poszczególnych KEU w celu umożliwienia przekierowania użytkowników do poszczególnych e-usług, świadczonych przez 12 KEU.
CO.22.	Wymaga się, aby jednym z podstawowych elementów interfejsu użytkownika Portalu CUW i Portalu WODGIK była interaktywna mapa Geoportalu OWI pełniąca funkcję Portalu Informacji Przestrzennej Projektu wspierającego wizualizację danych i materiałów PZGiK zarządzanych przez poszczególnych Partnerów Projektu.
CO.23.	Wykonawca zapewni kodowanie zgodne ze standardami W3C, tzn. rozwiązanie musi zostać zbudowane w oparciu o technologię HTML 5 oraz CSS 3.

V. Wymagania szczegółowe

Interesariusze poprzez interfejs użytkownika Portalu CUW powinni móc kompleksowo załatwić wszystkie sprawy opisane e-usługami bez konieczności przechodzenia do konkretnych powiatów i powtarzania tam tych samych czynności. Portal CUW powinien pełnić funkcję brokera e-usług i stanowić bramkę wejścia do tych e-usług. Rozwiązanie powższe nie wyklucza funkcjonowania autonomicznych rozwiązań częśći powiatowych.

Portal CUW
CU.1.	Wykonawca musi wykonać i dostarczyć Zamawiającemu Portal CUW zintegrowany z geoportalem OWI zawierający katalog wszystkich e-usług wraz z listą 13 Partnerów, wdrożonych we wszystkich KEU i WODGIK dla 13 JST, w ramach Projektu.
CU.2.	Strona startowa Portalu CUW - Wykonawca zaprojektuje stronę strtową CUW oraz przedstawi ją do akceptacji zamawiającego. Elementem strony startowej CUW będzie ineraktywna mapa geoportalu OWI.
CU.3.	Portal CUW zintegrowany z GeoPortalemOWI musi co najmniej następującą strukturę: • Strona główna; • Aktualności; • Wykaz jednostek; • E-usługi: ▪ Mapa interaktywna geoportalu OWI, ▪ Sekcję informacyjna, ▪ Sekcję rejestracji konta, ▪ Sekcję logowania; • Pomoc; • Kontakt; • Wyszukiwarka; • Mapa strony.
CU.4.	Szczegółowa struktura będzie przedmiotem koncepcji sporządzonej przez Wykonawcę, uzgodnionej z Zamawiającym i przez niego zatwierdzonej.
CU.5.	Portal CUW na stronie startowej musi prezentować aktualne informacje dotyczące projektu CUW oraz e-usług realizowanych przez 13 JST.
CU.6.	Wymaga się aby na podstronie „Aktualności” możliwe było zamieszczanie bieżących informacji o projekcie CUW, w formie tekstowej, graficznej, dźwiękowej i nagrań audiowizualnych oraz e-usługach świadczonych przez 13 JST.
CU.7.	Wymaga się aby edycja i zamieszczanie treści było możliwe z poziomu administratora Portalu CUW.

CU.8.	Wymaga się aby umieszczony był wykaz, wraz opisem, wszystkich JST świadczących e usługi.
CU.9.	Portal CUW musi zawierać wykaz wszystkich e-usług świadczonych w ramach 13 JST.
CU.10.	Wraz z wykazem świadczonych e-usług muszą być dostępne ich opisy i sposoby realizacji wraz z ewentualną informacją o: • odbiorcach usługi • wymaganych dokumentach • podstawą prawną • trybie odwoławczym • opłatami • terminami realizacji Zakres udostępnianej informacji powinien być adekwatny do charakteru świadczonej usługi.
CU.11.	Na podstronie Portalu CUW musi znajdować się interaktywna mapa województwa opolskiego (Geoportalu OWI), uwzględniająca Świadczone usługi i podział na JST. Obszar danego powiatu na mapie powinien odzwierciedlać zasięg przestrzenny świadczonej e-usługi . Wymaga się, aby po wybraniu konkretnej e-usługi nastąpiło automatyczne przekierowanie wniosku/ów do organu który świadczy wybraną e usługę.
CU.12.	Część mapowa Portalu CUW powinna być realizowana przez Geoportal OWI: • Wspierać realizację e-usług przez zapewnienie niezbędnej informacji przestrzennej koniecznej do lokalizacji i sprawnego pozyskania poszukiwanych materiałów, • Zapewniać możliwość korzystania z usług sieciowych danych przestrzennych zewnętrznych serwisów mapowych, z wykorzystaniem usług • Uwzględniać odmienny zakres danych udostępniany w e-usługach przez partnerów powiatowych i wojewódzkich • Udostępniać podstawowy zakres funkcji obsługi mapy obejmujący co najmniej: ▪ Płynną nawigację na mapie, ▪ Zmianę skali mapy, ▪ Wybór i zmianę układu współrzędnych, ▪ Dodanie/usunięcie warstw, ▪ Wybór i zmianę predefiniowanych kompozycji mapowych.
CU.13.	Sekcja pomocy musi zawierać pomoc kontekstową oraz listę najczęściej zadawanych pytań i odpowiedzi na nie (FAQ), dotyczące obsługi Portalu CUW. Musi również

	zawierać filmy instruktażowe opisujące jak załatwić konkretna usługę i jaką ścieżką załatwiany jest wniosek i gdzie i w jakim czasie uzyska informację zwrotną.
CU.14.	Podstrona „Kontakt” musi zawierać aktualne informacje kontaktowe JST (w zakresie załatwianych usług) oraz administratora portalu.
CU.15.	Wymaga się aby w ramach podstrony „Mapa strony” automatycznie generowana była aktualna mapa serwisu umożliwiająca określenie poziomu zagłębienia w hierarchię kategorii i artykułów. Mapa serwisu musi przedstawiać strukturę drzewiastą menu wraz odnośnikami do każdej podstrony w serwisie. Wymaga się aby z każdego poziomu można było wrócić do poprzedniej strony oraz do strony głównej.

VI.Wymagania szczegółowe dotyczące Systemu WZGIK

ODGIK Województwa
	System WZGiK
WO.1.	W skład Systemu WZGIK będzie wchodzić: Portal WZGIK dostępny z poziomu sieci Internet oraz Moduł WZGIK , Mapy WZGIK dostępny wyłącznie w sieci lokalnej.
WO.2.	Baza danych Systemu WZGIK będzie prowadzona w Centralnej Bazie Danych CUW, w której znajdą się: 1. Wszystkie dane niezbędne do prowadzenia: rejestru zgłoszeń, ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego oraz rejestru wniosków o udostępnienie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego. 2. Dane i materiały wojewódzkiego zasobu geodezyjnego i kartograficznego w postaci dokumentów elektronicznych. Dla niektórych zasobów dostępnych w postaci plików, baza musi przewidywać przechowywanie ścieżek. Wykonawca w maksymalny sposób ma wykorzystać istniejący motor baz danych bądź zastosować w uzgodnieniu z Zamawiającycm rozwiązanie alternatywne.
WO.3.	System WZGIK zapewni obsługę wartości słownikowych dla wszystkich pól atrybutowych z klas przewidzianych przez Rozporządzenie PZGiK.
WO.4.	System WZGIK musi mieć zaimplementowany podręcznik użytkownika w formie

	filmów oraz systemu podpowiedzi bieżącej.
WO.5.	System WZGIK musi zostać zintegrowany z systemem Finansowo Księgowym , Systemem płatności internetowych oraz uwzględniać płatność poprzez terminal płatniczy.
WO.6.	System WZGIK musi zostać zintegrowany z systemem dziedzinowym EZD , W ramach integracji z rozumie się również integrację Elektroniczną Platformą Usług Administracji Publicznej (ePUAP). Każda sprawa niezależnie od sposobu jej złożenia jest najpierw rejestrowana w systemie EZD, w którym nadawany jest numer kancelaryjny sprawy, który uwidoczniony jest zarówno w licencji, zgłoszeniu prac jak i w dokumencie obliczenia opłaty. W systemie EZD są również wpisywane dne teleadresowe klienta oraz odbywa się rejestracja oraz wysyłka spraw (analogowo oraz poprzez ePUAP).
WO.7.	System WZGIK musi zostać zintegrowany z portalem katalogowym.
WO.8.	Pliki xml wymaganych klauzul muszą być generowane „w locie” na podstawie x.xx. danych z ewidencji materiałów zasobu.
WO.9.	Wypełnianie pól formularzy (np. licencji, zgłoszenia pracy, wniosku) musi być procesem zautomatyzowanym (wykorzystującym np. ewidencje materiałów zasobu, repozytorium tożsamości) oraz zintegrowanym (EZD, ePUAP, płatności).
WO.10.	System WZGIK musi zostać zintegrowany z platformą płatności elektronicznych. oraz z systemem płatności poprzez terminal płatniczy..
WO.11.	System WZGIK musi zapewnić reguły bezpieczeństwa zgodnie z obowiązującymi przepisami prawa dla systemów teleinformatycznych.
WO.12.	Zapewnienie minimalnych wymagań dla systemów teleinformatycznych zgodnie z rozporządzeniem z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych.
	Uszczegółowienie wymagań funkcjonalnych Portalu WZGIK
WO.13.	Portal WZGiK to element odpowiedzialny za realizację e-usług świadczonych na poziomie województwa. Może być zaprojektowany jako element Portalu CUW lub/i niezależny Portal WZGIK, do którego jest dostęp również z poziomu Portalu CUW. W Portalu WZGIK klient określa parametry wejściowe, od których jest uzależnione przejście do dalszych etapów realizacji wniosku oraz od których jest uzależniona

	dostępność materiałów zasobu widoczna w geoportalu np. w postaci zasięgów. Parametry wejściowe decydują również czy wniosek będzie realizowany odpłatnie/nieodpłatnie oraz czy są dostępne zniżki a także czy wniosek może być zrealizowany automatycznie.
WO.14.	Wykonawca zaprojektuje stronę strtową Portalu WZGIK oraz przedstawi ją do akceptacji zamawiającego. Elementem strony startowej WZGIK będzie ineraktywna mapa geoportalu OWI.
WO.15.	Wybór konkretnego „kafelka” określonego w wymaganiu powyżej powoduje preselekcję kompozycji/serwisów mapowych, które będą możliwe do przeglądania. W serwisie mapowym ma pojawić się zasięg dostępnych usług i materiałów mapowych. Ponadto ma możliwość odczytu informacji oraz podglądu fragmentu wybranego opracowania .Wykonawca przygotuje kompozycje mapowe oraz uzgodni je z Zamawiajacym.
WO.16.	Portalu WZGIK umożliwi: • Przeglądanie wniosków/ zgłoszeń/zawiadomień/ (w ramach wykazów dokumentów ze statusami poszczególnych etapów ich realizacji), • Przeglądanie wykazu DOO, • Przeglądanie wykazu licencji klienta, • Przeglądanie wykazu UPO, • Przeglądanie wykazu protokołów przekazania danych, • Interfejs do przyjmowania płatności drogą elektroniczną za udostępnione materiały z wojewódzkiego zasobu geodezyjnego i kartograficznego.
WO.17.	Portal WZGIK musi zapewnić możliwość udostępniania i korzystania z usług infrastruktury informacji przestrzennej poprzez integrację z geoportalem OWI w tym usług wewnątrzadministracyjnych (A2A), usług dla przedsiębiorstw (A2B) lub obywateli (A2C), które będą obejmować: • 1) wyszukiwania, umożliwiające wyszukiwanie zbiorów oraz usług danych przestrzennych na podstawie zawartości odpowiadających im metadanych oraz umożliwiające wyświetlanie zawartości metadanych; • 2) przeglądania, umożliwiające co najmniej: wyświetlanie, nawigowanie, powiększanie i pomniejszanie, przesuwanie lub nakładanie na siebie zobrazowanych zbiorów oraz wyświetlanie objaśnień symboli kartograficznych i zawartości metadanych; • 3) pobierania, umożliwiające pobieranie kopii zbiorów lub ich części oraz, gdy jest to wykonalne, bezpośredni dostęp do tych zbiorów; • 4) przekształcania, umożliwiające przekształcenie zbiorów w celu osiągnięcia interoperacyjności zbiorów i usług danych przestrzennych; • 5) umożliwiające uruchamianie usług danych przestrzennych.

WO.18.	Portal WZGIK musi zapewnić narzędzia do przeglądania dokumentów na koncie użytkownika zewnętrznego w tym : • Przeglądanie i możliwość pobrania w formacie PDF wygenerowanych przez Moduł WZGiK wniosków/zgłoszeń/zawiadomień/ (w ramach wykazów dokumentów ze statusami poszczególnych etapów ich realizacji). • Podgląd i pobranie w formacie PDF DOO wygenerowanego przez Moduł WZGiK. • Podgląd i pobranie w formacie PDF licencji wygenerowanej przez Moduł WZGiK. • Podgląd informacji o pobraniu materiałów zgodnie z wybraną we wniosku formą i sposobem przekazania (w przypadku usług sieciowych informacje o loginie i haśle dostępowym). • Podgląd protokołów przekazania oraz możliwość podpisania ich przez użytkownika zewnętrznego i zwrotne przesłanie. • Pobranie materiałów zgodnie z wybraną we wniosku formą i sposobem przekazania. • Identyfikacja organu prowadzącego WZGiK (automatyczne uzupełnianie pola teleadresowego we wnioskach, zgłoszeniach prac, zawiadomieniach). Dane dotyczące nazwy i adresu organu powinny być zesłownikowane z możliwością ich aktualizacji.
WO.19.	Obsługę e-usług WZGIK ma być realizowana poprzez Portal CUW lub bezpośrednio przez Portal WZGIK w połaczeniu z modułem WZGIK oraz geoportalem OWI.
WO.20.	Portal WZGIK musi zapewnić min. realizację wniosków o udostępnienie odpłatne i nieodpłatne udostępnienie wojewódzkiego zasobu geodezyjnego i kartograficznego, w tym: wniosku „W” o udostępnienie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego (a także „W1”), wniosku o udostępnienie danych zawartych w rejestrze publicznycm oraz obsługę zgłoszeń prac geodezyjnych i kartograficznych. Musi również uwzględniać obsługę wniosku, kiedy klient przychodzi osobiście lub zamawia wersję analogową.
WO.21.	Wykonawca zapewni mechanizm przekazania i zapisu wszystkich wniosków powstałych podczas działania e-usług w bazie danych Modułu WZGIK w postaci dokumentów elektronicznych w formacie zgodnym z rozporządzeniem w sprawie KRI.
WO.22.	Każdy użytkownik Systemu WODGIK musi być opisywany za pomocą wszystkich atrybutów niezbędnych do nadania uprawnień oraz do realizacji e-usług.świadczonych przez Portal WZGIK.

WO.23.	W szczególności Wykonawca może pogrupować funkcjonalności i wymagania w innym układzie obejmującym jeden lub więcej elementów funkcjonalnych Systemu WZGIK. Portal WZGIK powinien komunikować się z Modułem WZGIK za pomocą usług SOA..Powinna być wyodrębniona separacja tych dwóch elementów składowych. Interesariusz przycjhodząc do WODGIK ma możliwość złożenia bezpośrednio u pracownika ODGIK zamówienia. Moduł WZGIK jest komponentem autonomicznym. Na rzecz innego dostępu do funkcjonalności modułu WZGIK powinien dostarczać warstwę integracyjną w postaci usług, za pomocą których możliwa będzie realizacja e- usług świadczonych przez portal WZGIK.
WO.24.	Zaproponowane rozwiązanie musi umożliwiać rozbudowę o kolejne e-usługi.
WO.25.	PortalWZGiK oraz zintegrowany Portal CUW musi zapewnić Identyfikacje wnioskodawcy (automatyczne uzupełnianie pól we wniosku na podstawie danych z konta użytkownika).
	Płatności Internetowe e-płatność, (PI)
WO.26.	Element Płatności Internetowych (PI) musi zapewniać wykonanie płatności internetowych dla wszystkich e-usług wymagających wniesienia opłat.
WO.27.	Płatności Internetowe muszą umożliwiać wybranie przynajmniej następujących metod: • Elixir • PayByNet;
WO.28.	Po dokonaniu przez użytkownika płatności elektronicznej, element Płatności Internetowych musi posiadać możliwość sprawdzenia statusu płatności przez klienta i pracownika UMWO.
	Część mapowa portalu WZGIK stanowiąca zmodernizowany geoportal OWI (z wykorzystaniem wszystkich istniejących i nowych funkcjonalności)
	E-Usługi
WO.29.	E-usługi muszą być realizowana na 4 poziomie dojrzałości.
WO.30.	Wykonawca w ramach e-usług dostarczy i wdroży poniższe podprocesy e-usług opisane w załączniku B.4 do SIWZ.
WO.31.	E-usługi muszą udostępniać formularze wniosków wraz z możliwością automatycznego wypełniania i wspomagania uzupełnienia wniosku oraz możliwością określenia rodzaju obiektów i obszaru, dla którego mają być udostępnione dane oraz załączenia go do wniosku w postaci pliku. Wymaga się, aby walidacja poprawności formularza wniosku

	została dokonana automatycznie.
WO.32.	W ramach usług UW01 i UW02 Portal WZGIK musi: • Zapewnić wygenerowanie i wypełnienie przez użytkownika zewnętrznego wniosku • Określenie przedmiotu wniosku (dodatkowo wniosek „W1”). • Identyfikacja obszaru objętego wnioskiem poprzez: o jednostki podziału terytorialnego, o wykaz godeł arkuszy mapy, o identyfikatory operatów technicznych, o obszar określony na załączniku graficznym, o obszar określony w załączonym pliku wektorowym, o współrzędne poligonu, o szkic wykonany w zintegrowanym Geoportalu OWI przez użytkownika (przesłanie zidentyfikowanego obszaru do wniosku za pomocą pliku w formacie SHP lub txt).
WO.33.	W ramach usług U03 i U04 Portal WODGIK musi : • Zapewnić wygenerowanie i wypełnienie przez użytkownika zewnętrznego zgłoszenia pracy geodezyjnej lub zgłoszenia pracy kartograficznej. • Identyfikacja wykonawcy (automatyczne uzupełnianie pól w zgłoszeniu na podstawie danych z konta użytkownika zewnętrznego). • Dane identyfikujące osoby, którym przedsiębiorca lub kierownik jednostki organizacyjnej powierzył samodzielne wykonanie czynności składających się na zgłaszane prace geodezyjne/kartograficzne lub funkcję kierownika tych prac. • Cel, rodzaj, skala zgłaszanych prac geodezyjnych/kartograficznych. • Przewidywany termin wykonania zgłaszanych prac geodezyjnych/ kartograficznych. • Dane określające położenie obszaru/obszarów, które będą objęte zgłaszanymi pracami geodezyjnymi/kartograficznymi. • Lista zbiorów danych lub innych materiałów zasobu, które w ocenie wykonawcy prac geodezyjnych/kartograficznych są potrzebne do wykonania zgłaszanych prac geodezyjnych/kartograficznych wraz z numenami ewidencyjnymi zasobu. Ten element musi być automatycznie wypełniany poprzez zintergrowanie z geoportalem OWI oraz bazą gdzie przechowywana jest ewidencja materiałów zasobu oraz metadane poprzez kliknięciwe w geoportalu na wybrany materiał zasobu. W trakcie wyboru klient ma możliwość podflądu tych informacji przed zatwierdzeniem wyboru. • Dodatkowe wyjaśnienia i uwagi wykonawcy prac geodezyjnych/ kartograficznych. • Podpisanie wniosku przez wykonawcę poprzez ePUAP, podpis kwalifikowany lub inny sposób uwierzytelniania. • zapewnić wygenerowanie i wypełnienie przez użytkownika zewnętrznego zawiadomienia o wykonaniu zgłoszonych prac geodezyjnych/kartograficznych.

WO.34.	W ramach usług UW05 Portal WZGIK musi umożliwić, zapewnić : • Wygenerowanie i wypełnienie przez użytkownika zewnętrznego wniosku. • Podanie dane identyfikujące wnioskodawcę w sposób automatyczny gdy użytkownik jest zalogowany i oraz ręcznie. • Określenie przedmiotu wniosku poprzez podanie lub wybór informacji o dokumentach, których dotyczy wniosek. • Identyfikacja obszaru objętego wnioskiem. • Określenie lub wybór wykonawcę dokumentu. • Określenie lub wybór numeru identyfikatora zgłoszenia prac albo identyfikator ewidencyjny materiału zasobu. • Podanie liczby egzemplarzy dokumentu do uwierzytelnienia gdy jest większa niż 1. • Podpisanie wniosku przez wykonawcę poprzez ePUAP, podpis kwalifikowany lub inny sposób uwierzytelniania.
	Minimalne wymagania funkcjonalne Modułu WZGIK
WO.35.	Moduł WZGiK musi być dostępny dla następujących przeglądarek: Microsoft Edge, Mozilla Firefox, Google Chrome, Opera wyłącznie z poziomu sieci lokalnej.
WO.36.	Moduł WZGIK musi zapewnić min. zarządzanie użytkownikami zewnętrznymi i wewnętrznymi, ich uprawnieniami do danych, usług i funkcji Modułu WZGiK (w tym przeglądanie/edycja/usuwanie/blokowanie kont użytkowników).
WO.37.	Moduł WZGIK musi zapewnić możliwość przejęcia uprawnień innego użytkownika wewnętrznego na czas zastępstwa (zapisywanie w historii zdarzeń zawierających informacje o ustanowieniu zastępstw).
WO.38.	Moduł WZGiK musi zapewnić możliwość zarządzenia grupami użytkowników (administrator, użytkownik wewnętrzny, użytkownik zewnętrzny). Każda z grup użytkowników posiada odpowiednie uprawnienia do danych, usług i funkcji Modułu WODGiK (w tym przeglądanie/edycja/usuwanie grup użytkowników zewnętrznych i wewnętrznych).
WO.39.	Moduł WZGiK musi zapewnić rejestrację kont użytkowników zewnętrznych i wewnętrznych.
WO.40.	Moduł WZGiK musi zapewnić logowanie użytkownika wewnętrznego i zewnętrznegoprzez login i hasło.
WO.41.	Moduł WZGiK musi zapewnić rejestrację logowań i przeglądanie historii logowań: data, godzina, login, IP, wynik logowania (poprawne, błędne). Historia logowania możliwa do exportu w formatach CSV i PDF.

WO.42.	Rejestr zamówień.
WO.43.	W Rejestrze zamówień zamieszczone są wszystkie realizowane przez ODGIK, w tym e- uslugi udostępnione w portalu CUW lub Portalu WZGIK realizowanych w zakresie Wojewódzkiego Zasobu GIK.
WO.44.	Moduł WZGiK musi zapewnić narzędzia związane z dodawaniem wniosków z wymagania złożonych poza Portalem WZGiK (poza Portalem WZGiK ) analogicznie jak w/w podrozdziale e-usługi wraz z załącznikami.
WO.45.	Rejestracja wniosku w Systemie Obiegu Dokumentów EZD (w przypadku wniosku złożonego przez Portal WZGiK rejestracja odbywa się automatycznie, dla wniosków złożonych poza Portalem WZGiK rejestracji dokonuje użytkownik wewnętrzny).
WO.46.	Weryfikacja wniosku przez użytkownika wewnętrznego (w przypadku wniosków nieodpłatnych lub uwzględniających zniżki)
WO.47.	Wystawienie DOO dla wniosku (wysyłany automatycznie do klienta w przypadku złożenia wniosku standardowego, generowany i wysyłany przez użytkownika wewnętrznego dla wniosku wymagającego weryfikacji) lub wygenerowanie dokumentu obliczenia wartości nieodpłatnie udostępnionych materiałów (dokument wewnętrzny dla celów raportowania).
WO.48.	Potwierdzenie wpływu opłaty - w przypadku płatności poprzez przelew bankowy na konto Województwa Opolskiego (WZGiK Opole) lub automatycznie za pośrednictwem terminala przy wizycie osobistej.
WO.49.	Wygenerowanie protokołu przekazania (w przypadku udostepnienia nieodpłatnego).
WO.50.	Wystawienie licencji (wysyłana automatycznie do klienta w przypadku złożenia wniosku standardowego, generowana i wysyłana przez użytkownika wewnętrznego dla wniosku niestandardowego).
WO.51.	Dla wybranych standardowych produktów po wskazaniu w geoportalu OWI zasięgów materiałów zasobu i dalszej realizacji procedury ich zamówienia system przygotowuje automatycznie gotowe „paczki” z danymi.
WO.52.	Opatrywanie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego klauzulami zgodnie z załącznikiem nr 4 Rozporządzenia PZGiK (klauzule wysyłane automatycznie do klienta w przypadku złożenia wniosku standardowego po uiszczeniu opłaty; generowane i wysyłane przez użytkownika wewnętrznego dla wniosku niestandardowego): • Dla materiałów w postaci elektronicznej – logicznie powiązany

	z danym dokumentem.
WO.53.	Udostępnienie i uwierzytelnienie materiałów przez pracownika lub automatycznie przez system WZGIK z mozliwością weryfikacji,zgodnie z wybraną (we wniosku) formą przekazania i sposobem odbioru materiałów
	Rejestr zgłoszeń
WO.54.	Moduł WZGiK musi zapewnić narzędzia związane z dodawaniem zgłoszeń prac złożonych poza Portalem WZGiK analogicznie jak w wymaganiach e-usług.
WO.55.	W przypadku zgłoszenia pracy złożonego przez Portal WZGiK rejestracja zgłoszenia pracy w Systemie Obiegu Dokumentów EZD odbywa się automatycznie, dla zgłoszeń pracy złożonych poza Portalem WZGiK rejestracji dokonuje użytkownik wewnętrzny).
WO.56.	Weryfikacja zgłoszenia przez użytkownika wewnętrznego.
WO.57.	Rejestracja uzgodnień z Wykonawcą listy materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego niezbędnych lub przydatnych do wykonania zgłoszonych prac.
WO.58.	Wystawienie DOO (w przypadku realizacji zgłoszenia pracy nie będącej zamówieniem organu służby geodezyjnej i kartograficznej - DOO generowany i wysyłany przez użytkownika wewnętrznego).
WO.59.	Wygenerowanie dokumentu obliczenia wartości nieodpłatnie udostępnionych materiałów (w przypadku realizacji zgłoszenia pracy będącej zamówieniem organu służby geodezyjnej i kartograficznej generowany jest dokument wewnętrzny dla celów raportowania).
WO.60.	Potwierdzenie wpływu opłaty - w przypadku dokonania opłaty poprzez przelew bankowy na konto Województwa Opolskiego (WZGiK ) lub za pomocą terminalu płatniczego.
WO.61.	Wystawienie licencji (generowana i wysyłana przez użytkownika wewnętrznego).
WO.62.	Dla zgłoszenia niestandardowego, którego przedmiotem jest BDOT10k przygotowanie danych zrealizuje system dziedzinowy.
WO.63.	Opatrywanie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego klauzulami zgodnie z załącznikiem nr 4 Rozporządzenia PZGiK: • Dla materiałów w postaci elektronicznej – logicznie powiązany z danym dokumentem. • Dla materiałów w postaci nieelektronicznej – musi zapewnić możliwość

	wydruku klauzuli.
WO.64.	Moduł WODGIK musi zapewniać narzędzie do prowadzenia i zarządzania dokumentami. (w ramach wykazów musi być dostępny podgląd statusów poszczególnych etapów ich realizacji). a)Wykaz wniosków b)Wykaz zgłoszeń (w ramach wykazu zgłoszeń musi być dostępny podgląd statusów poszczególnych etapów ich realizacji. c) Wykaz zawiadomień, d) Wykaz DOO, e)Wykaz protokołów, f)Wykaz licencji.
	Dokument Obliczenia Opłaty
WO.65.	Moduł WZGIK musi zapewnić obliczanie wysokości opłat za udostępniane materiały wojewódzkiego zasobu geodezyjnego i kartograficznego zgodnie z ustawą PGiK
WO.66.	Dokument Obliczenia Opłaty DOO zgodny będzie ze wzorem zamieszczonym w Rozporządzeniu Ministra Administracji i Cyfryzacji z dnia 9 lipca 2014 r. w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty.
WO.67.	W wygenerowanym DOO wszystkie pola, za wyjątkiem podpisu organu lub upoważnionej osoby, będą automatycznie wypełnione informacjami znajdującymi się we wniosku i w wycenie. Musi być zapewniona integracja z EZD gdyż znak sprawy jest nadawany w EZD i musi być przyjmowany automatycznie w DOO i licencji.
WO.68.	Możliwy będzie podgląd DOO w formacie .pdf.
WO.69.	Wszystkie DOO znajdować się będą w wykazie, tabeli z informacjami: numer DOO, identyfikator wniosku, należna opłata, data wygenerowania, status.
WO.70.	Wykaz DOO umożliwi sortowanie i wyszukiwanie wniosków.
WO.71.	Z wykazu DOO można będzie przejść do formularza ze szczegółami zarejestrowanego wniosku.
WO.72.	DOO może zostać zaakceptowany lub odrzucony przez Interesanta.
WO.73.	Po odrzuceniu lub akceptacji DOO wnioskowi automatycznie nadawany będzie odpowiedni status, Pracownik otrzymuje komunikat.
WO.74.	Akceptacja DOO powoduje automatyczną zmianę statusu wniosku i wysłanie

	komunikatu do Pracownika.
WO.75.	Odrzucenie DOO wiąże się z podaniem powodu braku akceptacji, który przekazywany jest do Pracownika.
WO.76.	W sytuacji gdy odrzucono DOO, Pracownik może zakończyć procesowanie wniosku, wyjaśnić wątpliwości z Wykonawcą w wyniku czego Wykonawca zaakceptuje wcześniej odrzucony DOO lub może powtórzyć wycenę.
WO.77.	Decyzja podjęta przez Pracownika wiąże się będzie z nadaniem odpowiedniego statusu wniosku i z przesłaniem komunikatu na konto Interesanta.
WO.78.	W Module WZGIK Stawki opłat przechowywane będą w edytowalnym przez administratora słowniku, tabeli stawek podstawowych.
WO.79.	Aktualizacja słownika, tabeli stawek podstawowych, w tym możliwość utworzenia nowych tabel stawek podstawowych poprzez przekopiowanie tabeli i przemnożenie poprzednich przez współczynnik.
WO.80.	W Module WZGIK konieczna jest archiwizacja nieobowiązujących tabel stawek podstawowych.
WO.81.	W Module WZGIK konieczna jest stosowanie współczynników korygujących oraz innych opłat związanych z udostępnieniem.
WO.82.	Współczynników korygujące przechowywane będą w tabeli, słowniku z możliwością aktualizacji i archiwizacji.
	Opłacenie materiałów
WO.83.	Zatwierdzenie wyceny przez obie strony procesu, aktywuje przekierowanie do internetowej płatności.
WO.84.	Interesant dokonuje płatności za materiały osobiście bądź poprzez narzędzie e- Płatności, z którym moduł WZGiK jest zintegrowany.
WO.85.	Wpłata dokonywana przez płatności elektroniczne będzie automatycznie odnotowywana w module, wraz z informacją o dacie i sygnaturze.
WO.86.	W przypadku dokonania wpłaty inną drogą niż przez e-płatność, istnieć będzie możliwość ręcznego wprowadzenia kwot wraz z datą wpłaty i sygnaturą dokumentu.
WO.87.	Wprowadzoną ręcznie wpłatę można będzie modyfikować lub usunąć.

WO.88.	W przypadku nadpłaty lub niedopłaty, wyświetlony zostaje stosowny status DOO.
WO.89.	Po wpłynięciu całej należności za materiały, zmienia się status wniosku na opłacony.
WO.90.	W przypadku gdy opłata za materiały wynosi 0 zł, płatność elektroniczna się nie odbywa.
	Licencja
WO.91.	Licencja generowana jest automatycznie po opłaceniu materiałów.
WO.92.	Licencję dla wniosku złożonych poza Portalem WODGiK generuje na żądanie Pracownik. Dla wniosku „Standardowego” licencja generuje się automatycznie.
WO.93.	Licencja zgodna jest ze wzorem zamieszczonym w Rozporządzeniu Ministra Administracji i Cyfryzacji z dnia 9 lipca 2014 r. w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty.
WO.94.	Podczas uzupełnienia licencji, wszystkie pola, za wyjątkiem daty licencji i daty kopii, będą automatycznie wypełnione informacjami znajdującymi się we wniosku.
WO.95.	Po zatwierdzeniu licencji automatycznie nadawany jest numer, zgodny z Rozporządzeniem, który nadawany jest w systemie EZD.
WO.96.	Wszystkie licencje prezentowane będą w formie wykazu, tabeli z informacjami: numer licencji, identyfikator wniosku, data licencji, status.
WO.97.	Licencja posiada status, który zmienia się w momencie jej uzupełnienia i zatwierdzenia.
WO.98.	Wykaz licencji umożliwi sortowanie i wyszukiwanie wniosków.
WO.99.	Możliwy będzie podgląd wygenerowanej licencji w formacie .pdf.
WO.100.	Stała treść licencji będzie automatycznie uzupełniona danymi wprowadzonymi przez Interesanta w formularzu.
	Zarządzanie zasobem WODGiK
WO.101.	Moduł WZGiK musi zapewniać narzędzia do prowadzenia i zarządzania ewidencją materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego
WO.102.	Moduł WZGiK musi zapewniać Prowadzenie i zarządzanie ewidencją materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego wraz z automatycznym uzupełnianiem wartości dla części atrybutów podczas dodawania nowego materiału

	do wojewódzkiego zasobu geodezyjnego i kartograficznego z jednoczesną możliwością edycji wartości atrybutu oraz usuwanie, modyfikacja, przeglądanie materiałów i dokumentów.
WO.103.	Moduł WZGiK musi zapewniać opatrywanie materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego klauzulami zgodnie z załącznikiem nr 3 Rozporządzenia PZGiK: • Dla materiałów w postaci elektronicznej – logicznie powiązany z danym dokumentem. • Dla materiałów w postaci nieelektronicznej – musi zapewnić możliwość wydruku klauzuli.
WO.104.	Moduł WZGiK musi zapewniać wyłączanie materiałów z wojewódzkiego zasobu geodezyjnego i kartograficznego, w tym wykonywanie wykazu materiałów do wyłączenia, protokółu przekazania do archiwum wraz z wykazem oraz eksport metadanych do przekazywanych archiwalnych materiałów zasobu zgodnie do przewidzianych do tego celu formatem i struktura.
WO.105.	Moduł WZGiK musi zapewniać prowadzenie i zarządzanie magazynem map drukowanych, w tym prowadzenie ewidencji ilościowo – wartościowej map drukowanych w magazynie, sygnalizowanie przekroczenia założonego stanu minimalnego oraz wykonywanie inwentaryzacji zgodnie z przepisami ustawy o rachunkowości.
WO.106.	Moduł WODGIK w powiązaniu z Modułem Mapy WZGIK powinien sygnalizować przekroszenie stanu minimalnego analogowych map WZGIK.
WO.107.	Do obszaru zarządzania zasobem WZGiK ma dostęp jedynie Pracownik posiadający odpowiednie uprawnienia.
	Ewidencjonowanie materiałów w zasobie
WO.108.	Element ewidencjonowania materiałów umożliwi ewidencjonowanie materiałów w wojewódzkim zasobie geodezyjnym i kartograficznym zgodnie z Rozporządzeniem Ministra Administracji i Cyfryzacji z dnia 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego.
WO.109.	Element Ewidencjonowania materiałów umożliwi generowanie metadanych dla ewidencjonowanego materiału zgodnie z przepisami prawa.
WO.110.	Element Ewidencjonowania materiałów umożliwi generowanie klauzuli dla ewidencjonowanego materiału.

WO.111.	W przypadku przyjęcia materiału na podstawie zgłoszenia, możliwy będzie wybór identyfikatora zgłoszenia prac z listy zgłoszeń, których procesowanie zostało zakończone.
WO.112.	Wybranie pozycji z listy identyfikatorów zgłoszeń powoduje automatyczne wstawienie minimum danych twórcy materiału zasobu.
WO.113.	Wybór podmiotu powoduje automatyczne wypełnienie danych o twórcy materiału zasobu.
WO.114.	Funkcjonalność tabeli z listą osób/firm umożliwi dodawanie nowych osób, modyfikację i archiwizację istniejących.
WO.115.	Tabela z listą osób/firm umożliwi filtrowanie i sortowanie.
WO.116.	Tabela z listą osób/firm posiada filtr przeglądana w trzech trybach, umożliwiających wyświetlenie podmiotów aktywnych, archiwalnych lub wszystkich.
WO.117.	Położenie zaewidencjonowanego materiału zaznacza się na zintegrowanym geportalu OWI,
WO.118.	Z portalu mapowego przekazywane są współrzędne centroid X i Y oraz zasięg narożników zasięgu zaznaczonego zasięgu dla zasobu.
WO.119.	Element umożliwi załączenie pliku do ewidencjonowanego materiału.
WO.120.	Istnieje możliwość podglądu i usunięcia załączonego pliku.
WO.121.	Zarejestrowanie materiału powoduje wprowadzenie materiału do Rejestru materiałów.
WO.122.	Zarejestrowanie materiału powoduje automatyczne nadanie identyfikatora ewidencyjnego materiałowi.
WO.123.	Zarejestrowanie materiału powoduje wygenerowanie klauzuli materiału.
WO.124.	Zarejestrowanie materiału powoduje możliwość automatycznego wygenerowania metadanych dla materiałów zasobu zgodnie z ust. 11 oraz ust. 12 Specyfikacji struktury i treści metadanych dla materiałów zasobu stanowiącej załącznik nr 2 do Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego. Umozliwia również automatyzację procesu dodania do serwera katalogowego celem

	utrzymania w aktualności usługi CSW .
	Ewidencjonowanie dokumentów w zasobie
WO.125.	Umożliwi ewidencjonowanie dokumentów w wojewódzkim zasobie geodezyjnym i kartograficznym zgodnie z Rozporządzeniem Ministra Administracji i Cyfryzacji z dnia 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego.
WO.126.	Umożliwi ewidencjonowanie dokumentów w ramach operatów technicznych w wojewódzkim zasobie geodezyjnym i kartograficznym.
WO.127.	Umożliwi generowanie metadanych dla ewidencjonowanego dokumentu.
WO.128.	Umożliwi edycję i wprowadzenie metadanych dokumentu.
WO.129.	Istnieje możliwość podglądu i usunięcia załączonego pliku.
WO.130.	Umożliwi załączenie treści dokumentu do operatu.
WO.131.	Zarejestrowanie dokumentu powoduje nadanie identyfikatora ewidencyjnego wprowadzenie dokumentu do Rejestru materiałów, przypisanego do wybranego operatu technicznego.
	Rejestr Materiałów
WO.132.	W Rejestrze Materiałów zamieszczone są wszystkie zaewidencjonowane materiały i dokumenty.
WO.133.	W ramach rejestru możliwe będzie jest przeglądanie zarejestrowanych materiałów i dokumentów zarejestrowanych w ramach operatów.
WO.134.	Materiały w rejestrze będzie można filtrować i sortować.
WO.135.	Narzędzie umożliwi wygenerowanie zestawienia zbiorczego, będącego raportem, który zawiera zestawienie wszystkimi zaewidencjonowanymi materiałami wraz ze szczegółami.
WO.136.	W rejestrze, możliwe jest ustawienie dostępu do wybranego materiału zasobu (z ograniczeniami lub bez).
WO.137.	Narzędzia rejestru umożliwi wprowadzenie i podgląd podstawy ograniczenia w dostępie do materiału.

WO.138.	W rejestrze możliwe będzie ustawienie statusu materiału: zarejestrowany lub wyłączony z zasobu.
WO.139.	Narzędzia rejestru umożliwi: • wprowadzenie szczegółów dotyczących dokumentu o wyłączeniu z zasobu; • podgląd zasięgu wybranego materiału na zintegrowanym geoportalu OWI; • podgląd klauzuli materiału; • podgląd metadanych materiału lub dokumentu; • pobranie meta danych.
	Magazyn analogowy – Mapy WZGIK
WO.140.	W magazynie analogowym zamieszczone są zarejestrowane materiały w postaci nieelektronicznej.
WO.141.	Funkcjonalność magazynu analogowego pokrywa się z funkcjonalnością rejestru materiałów.
WO.142.	Mechanizmy i raporty charakterystyczne wyłącznie dla magazynu to inwentaryzacja i przeglądanie stanów magazynowych oraz ilości sztuk zarezerwowanych.
WO.143.	Zarządzanie stanem magazynowym poprzez przeprowadzenie inwentaryzacji.
WO.144.	Zarządzanie stanem magazynowym poprzez przyjmowanie dostaw materiałów w postaci poligraficznej na magazyn.
WO.145.	Generowanie raportów magazynowych.
WO.146.	Aplikacja umożliwi generowanie raportów magazynowych dotyczących: • Ilości wydawanych materiałów, • Aktualnego stanu map, • Wartości magazynu według cen sprzedaży, • Przekroczenia stanu minimalnego, • Zestawienia obrotu analitycznego, syntetycznego i chronologicznego, • Udostępnionych map, • Dla potrzeb inwentaryzacji, • Dla potrzeb GGK.
WO.147.	Aplikacja umożliwi wybór parametrów zawężających wyniki wyświetlone na raporcie.
WO.148.	Raporty będą generowane w formacie .pdf.
WO.149.	Wszystkie raporty będą generowane w aplikacji posiadają miejscowość i datę, tytuł, nagłówek, tabelę z danymi, imię i nazwisko osoby sporządzającej raport, numerację

	stron.
WO.150.	Aplikacja umożliwi przeglądanie zamówionych materiałów w ramach wniosków i zgłoszeń
WO.151.	W magazynie analogowym zamieszczone są zarejestrowane materiały w postaci nieelektronicznej.
WO.152.	Przeglądanie zamówionych materiałów w ramach wniosków i zgłoszeń.
WO.153.	Formatka dotycząca dostępu do zasobu umożliwi wyświetlenie listy materiałów zamówionych w ramach wybranego wniosku lub zgłoszenia. Moduł prezentuje w oddzielnych panelach wysłane wnioski i zgłoszenia. Moduł umożliwia umożliwiają sortowanie i wyszukiwanie tabel wniosków i zgłoszeń. W ramach wyszukiwania możliwe jest zawężenie listy wniosków do zasięgu przestrzennego wrysowanego na zintegrowanym geoportalu OWI Pod tabelą prezentowane są wnioskowane materiały lub lista zbiorów danych, przypisane do wybranego w tabeli wniosku bądź zgłoszenia.
WO.154.	Generowanie raportów kasowych.
WO.155.	Aplikacja umożliwi generowanie raportów kasowych dotyczących: • Zestawienia niezapłaconych lub wystawionych DOO, • Raportu kasowego syntetycznego i analitycznego, • Zaległych opłat; Danych zbiorczych (raport zbiorczy – kasowy).
WO.156.	Aplikacja umożliwi wybór parametrów filtrowania zawężających wyniki wyświetlone na raporcie.
WO.157.	Raporty będą generowane do formatu .pdf.
WO.158.	Weryfikacja autentyczności licencji oraz Dokumentów Obliczenia Opłaty.
WO.159.	Aplikacja umożliwi sprawdzenie autentyczności licencji oraz Dokumentów Obliczenia Opłaty na podstawie identyfikatora dokumentu.
WO.160.	Wynikiem sprawdzenia autentyczności dokumentu będzie ocena numeru pod kątem jego poprawności oraz zakresu udzielonej licencji.
WO.161.	Weryfikacja odbywa się będzie w odniesieniu do wszystkich licencji i DOO

	zarejestrowanych w aplikacji.
WO.162.	Moduł WZGIK musi zapewniać prowadzenie i zarządzanie metadanymi dla zbiorów danych zgodnie z §12 ust. 1 pkt 1 i §12 ust. 2 Rozporządzenia PZGiK.
WO.163.	Moduł WZGIK musi zapewniać • Tworzenie i modyfikacja serii metadanych. • Tworzenie i modyfikacja zbioru metadanych. • Tworzenie i modyfikacja serii i zbiorów metadanych będzie zintegrowane z informacjami zawartymi w ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego. • Generowanie poprawnych plików XML metadanych (dla zbiorów i serii) zgodnie z normą ISO19115 i ISO19139 i zasilanie bazy danych portalu katalogowego. • Generowanie podglądów graficznych zawierających miniaturki zbioru lub serii danych wraz z zasileniem do struktury plikowej portalu katalogowego. • Generowanie plików metadanych • Przeglądanie, wyszukiwanie wygenerowanych metadanych w postaci tabelarycznej.
WO.164.	Moduł WODGIK musi zapewniać prowadzenie i zarządzanie metadanymi dla dokumentów elektronicznych wchodzących w skład operatów technicznych i innych materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego zgodnie z §12 ust. 1 pkt 2 i 3 Rozporządzenia PZGiK i §12 ust. 2 Rozporządzenia PZGiK.
WO.165.	Moduł WODGIK musi zapewniać : • Tworzenie i modyfikacja metadanych dla operatu technicznego. • Tworzenie i modyfikacja metadanych dla dokumentów wchodzących w skład operatów technicznych. • Tworzenie i modyfikacja metadanych dla operatu technicznego oraz dokumentów wchodzących w jego skład będzie zintegrowana z informacjami zawartymi w ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego. • Generowanie poprawnego pliku XML metadanych zgodnie ze schematami aplikacyjnymi umieszczonymi w pkt 10 i 12 załącznika nr 2 do Rozporządzenia PZGiK. • Przeglądanie, wyszukiwanie wygenerowanych metadanych w postaci tabelarycznej.
WO.166.	Moduł WZGiK musi zapewniać narzędzia do generowania i zarządzania kopiami bezpieczeństwa dla: • Danych stanowiących wojewódzki zasób geodezyjny i kartograficzny, wymagane przepisami prawa (na żądanie lub co określony okres) wraz z funcją sumy kontrolnej

	• Archiwizacja danych Systemu WODGIK (automatyczn co określony czas)).
WO.167.	Moduł WZGIK musi zapewniać narzędzie do generowania rejestrów i raportów oraz exportu do formatu CSV i PDF.
WO.168.	Moduł WZGIK musi zapewniać: • Rejestr wniosków generowany jest na określony przedział czasowy z możliwością sortowania. • Rejestr zgłoszeń generowany jest na określony przedział czasowy z możliwością sortowania. • Raport z odpłatnego udostępniania – DOO (według asortymentu, daty udostępnienia, wnioskodawcy, współczynnika CL, sposobu płatności). • Raport z nieodpłatnego udostępniania - dokumentu obliczenia wartości nieodpłatnie udostępnionych materiałów (według asortymentu, daty udostępnienia, wnioskodawcy). • Raport z wykazu protokołów (możliwość sortowania po rodzaju protokołu). • Raport z wykazu licencji (możliwość sortowania). • Raport o danych osobowych (dane identyfikujące osobę w Systemie WZGIK, datę i login użytkownika, który wprowadził dane, datę i login użytkownika, który ostatnio modyfikował dane, udostępnienie danych). • Raport z ewidencji materiałów wojewódzkiego zasobu geodezyjnego i kartograficznego (z całości lub według podanych atrybutów).
WO.169.	Udostępnienie aplikacji do aktualizacji danych przez departamenty UMWO lub autoryzowanych użytkowników wraz z możliwością tworzenia własnych cashflow.

VII.Wymagania szczegółowe dotyczące Moduł Administracji Wojewódzkiego Węzła Integrujacego (WWI) wraz z modułem Bezpieczeństwa usług sieciowych oraz Systemu WZGIK

OPROGRAMOWANIE ZARZĄDZAJĄCE CUW

CADM.1.

Oprogramowanie służy pracownikom i administratorom do zarządzania komponentami budowanej infrastruktury WWI oraz systemu WZGIK. Zadaniem oprogramowanie będzie: • Stałe monitorowanie i informowanie administratora o występowaniu ewentualnych problemów z działaniem poszczególnych komponentów, • zarządzanie użytkownikami i ich uprawnieniami do danych i usług, • zabezpieczanie danych, w szczególności usług dot. ich pobierania, • dostosowaniem narzędzi do realizacji nowych zadań (obsługa nowych wykazów, rejestrów, zbiorów danych).

CADM.2.	Oprogramowanie zarządzające składa się z komponentów: • Usługę monitorowania serwisów, • Zarządzanie klientem usług, • Zarządzanie usługami sieciowymi, • Usługa bezpieczeństwa usług sieciowych, • Narzędzia replikacji i importu danych.
CADM.3.	Interfejs graficzny oprogramowania zarządzającego umożliwia zdalne zarządzanie wszystkimi komponentami Narzędzie jest dostępne za pośrednictwem przeglądarki internetowej.
	Zarządzanie i bezpieczeństwo usług sieciowych
CADM.4.	Dane pochodzące z Systemu udostępniane są użytkownikowi publicznemu za pomocą usług sieciowych po odpowiednim zabezpieczeniu.
CADM.5.	Zabezpieczanie usług odbywa się w dedykowanej aplikacji wchodzącej w skład Oprogramowania Zarządzającego.
CADM.6.	Podstawowe cechy aplikacji: • webowy interfejs aplikacji działający w oparciu o „cienkiego klienta” • wspierający standardowe przeglądarki internetowe, • usługa bezpieczeństwa będzie wykorzystywała centralne repozytorium tożsamości w oparciu o katalog LDAP w celu jednolitego zarządzania użytkownikami, rolami i ich uprawnieniami do usług, funkcji i serwisów, usługa bezpieczeństwa będzie wykorzystywała mechanizmy SSO.
CADM.7.	Aplikacja umożliwia zabezpieczenie najnowszych wersji typów i wersji usługi sieciowej, minimum: WMS, WMSC,WMTS, REST, ECWP, WFS, REST, WCS, CSW, WCTS, WMC,WPS.
CADM.8.	Aplikacja umożliwia badanie usługi w celu sprawdzenia jego możliwości i wspieranych wersji przez aplikację.
CADM.9.	Mechanizm aplikacji: • mechanizm usługi sieciowej polegający na enkapsulacji • zabezpieczanego serwisu i następnie udostępnianiu go w formie ograniczonej i zabezpieczonej wymagającej uwierzytelnienia i autoryzacji użytkownika, • dostęp do zabezpieczonego serwisu umożliwia sieciowa aplikacja generująca URL ograniczonego serwisu (w formacie natywnym usługi bezpieczeństwa) po uwierzytelnieniu i autoryzacji użytkownika.

CADM.10.	Aplikacja umożliwia tworzenie uprawnień dla ról w zakresie: • ograniczeń do poszczególnych warstw serwisów mapowych, • ograniczeń przestrzennych do serwisów mapowych, • ograniczenia dostępu do żądań (request) zgodnych ze specyfikacją danego serwisu, • ograniczenia czasowych w dostępie do serwisów.
CADM.11.	Zarejestrowane usługi sieciowe prezentowane są w formie tabelarycznej wraz z podstawowymi informacjami o usłudze: • status usługi, • Kategorie usługi, • Poziom dostępu oraz narzędziami zarządzania które umożliwiają: • Utworzenie nowej usługi, • Dostosowanie, modyfikację usługi, • Opublikowanie przygotowanej usługi, • Wycofanie opublikowanej usługi, • Zarchiwizowanie nieaktywnej usługi, • Odblokowanie usługi.
CADM.12.	Tabela usług umożliwia wyszukiwanie.
CADM.13.	Aplikacja dokonuje rejestracji sieciowych usług fizycznych publikowanych przez serwery danych przestrzennych oraz wirtualnych udostępnianych użytkownikom z określonymi prawami. Sieciowe Usługi fizyczne mogą być udostępniane wielokrotnie poprzez usługi wirtualne.
CADM.14.	Rejestracji usługi wirtualnej wymaga podania parametrów typu: • typu usługi (WMS WMSC,WMTS, REST, ECWP, WFS, REST, WCS, CSW, WCTS,WMC, WPS), • Wskazania sieciowej zarejestrowanej usługi fizycznych, • hosta translatora – adresu wirtualnego, • parametrów metadanych usługi, • ewentualnie wskazujemy folder z repozytorium XSLT dla usługi • określamy ścieżkę plików logów dla usługi. • Określamy użytkowników lub wskazujemy grupę użytkowników. • Określamy parametry bezpieczeństwa usługi typu: o Czas dostępności usługi o Autoryzowane operacje na usłudze (np. : GetCapabilities, GetMap, GetFeatureInfo) o Parametry pliku graficznego publikowanego dla usług WMS, WMTS o Określamy które warstwy będą udostępniane w ramach usługi wirtualnej, jej zakres skal udostępnianych oraz zakres przestrzenny.

Dla usług WFS określany jest zakres udostępnianych warstw.
CADM.15.	Zarejestrowane usługi wirtualne prezentowane są w tabeli usług wirtualnych.
CADM.16.	Tabela umożliwia wyszukiwanie.
CADM.17.	Należy uwzględnić odpowiednie sposoby ograniczenia serwisów : • ograniczenie w dostępie do poszczególnych operacji • ograniczenie w dostępie do poszczególnych warstw serwisu, • ograniczenie przestrzenne w dostępie do określonego obszaru ograniczenie czasowe w dostępie do danych.
Monitorowanie serwisów i e-usług
CADM.18.	Głównym zadaniem usługi monitorowania wszystkich e-usług i zarejestrowanych serwisów OGC dla 13 JST Projektu jest bieżące raportowanie dostępności i wydajności e-usług i serwisów OGC, informowanie administratorów systemu o ewentualnych problemach z ich funkcjonowaniem. Usługa muszą umożliwić osobne raportowanie poszczególnych usług dla poszczególnych partnerów projektu.
CADM.19.	Podstawowe, wymagane cechy oprogramowania: • aplikacja internetowa działająca w oparciu o „cienkiego klienta” wspierająca standardowe przeglądarki internetowe, • aplikacja umożliwia monitorowanie dostępności i wydajności serwisów dostępnych w systemie poprzez cykliczne odpytywanie w zdefiniowanym interwale czasowym, • aplikacja umożliwia powiadamianie mailowe administratorów w przypadku spadku ustalonych granicznych kryteriów monitorowania serwisów, • aplikacja pozwoli na zbieranie statystyk w zakresie dostępności i wydajności serwisów.
CADM.20.	Wymagane funkcjonalności w zakresie definiowania monitoringu serwisów: • aplikacja może obsługiwać serwisy komunikujące się protokołem HTTP metodami GET i POST, • aplikacja i posiada obsługę zapytań do serwisów WMS WMSC,WMTS, REST, ECWP, WFS, REST, WCS, WCS, CSW, WCTS,WMC, WPS • aplikacja umożliwia definiowanie wielu adresów email, na które będą wysyłane powiadomienia o wystąpieniu problemów w komunikacji z serwisem, • aplikacja umożliwia definiowanie interwału odpytywania serwisu, • aplikacja umożliwia definiowanie parametrów krytycznych po których nastąpi wysłanie powiadomienia do administratorów tj.: czas

	nieaktywności serwisu, limit czasu odpowiedzi serwisu, dostępności serwisu.
Zarządzanie użytkownikami
	Rejestracja użytkownika zewnętrznego
CADM.21.	Autoryzacji Klienta musi być możliwa przez uwierzytelnienie użytkownika za pomocą profilu zaufanego lub certyfikatu kwalifikowanego minimum loginu i hasła.
CADM.22.	Aplikacja musi zapewnić możliwość zakładania konta nowego użytkownika i jego rejestracji w WWI lub Komponencie e-usług Systemu WZGiK.
CADM.23.	Aplikacja musi zapewniać automatyczną synchronizację danych użytkownika posiadającego już konto /WZGIK.
CADM.24.	Po pozytywnej autoryzacji użytkownika za pomocą Profilu Zaufanego, Aplikacja musi automatycznie zweryfikować istnienie konta w bazie danychWWI.
CADM.25.	W przypadku, gdy użytkownik loguje się pierwszy raz za pomocą Profilu Zaufanego, Aplikacja musi automatycznie założyć konto w bazie danych WWI lub komponencie e- usług Systemu PZGiK/WZGIK Partnerów Projektu.
CADM.26.	Aplikacja musi umożliwiać wprowadzanie zmian danych zarejestrowanego użytkownika w bazie danych Portalu CUW lub komponencie e-usług Systemów PZGiK Partnerów Projektu.
CADM.27.	Formularz rejestracji musi zawierać pola, które należy wypełnić danymi osobowymi oraz danymi firmy, jeżeli użytkownik reprezentuje firmę.
CADM.28.	Hasło wprowadzone przez użytkownika powinno zawierać przynajmniej jedną małą i wielką literę, cyfrę i przynajmniej 8 znaków.
CADM.29.	Formularz zawiera pole z obrazem, z którego użytkownik przepisuje tekst do odpowiedniego pola, w celu potwierdzenia swojej wiarygodności.
CADM.30.	Pola w formularzu są objęte regułami walidacyjnymi, które wyświetlają się jako podpowiedzi.
CADM.31.	Aplikacja musi umożliwiać użytkownikowi bezpieczną zmianę hasła oraz jego odzyskanie poprzez nadanie nowego hasła.
CADM.32.	Aplikacja musi umożliwiać uzupełnianie informacji o załączniki w postaci dokumentów

	elektronicznych potwierdzających uprawnienia lub pełnomocnictwa.
CADM.33.	Aplikacja musi umożliwiać zapisanie wniosku o założenie konta użytkownika wraz z załącznikami w bazie danych WWI.
CADM.34.	Aplikacja musi umożliwiać edycję i zmiany metadanych konta przez użytkownika.
CADM.35.	Aplikacja musi umożliwiać weryfikacje i autoryzację utworzonego konta użytkownika przez pracownika ODGIK.
CADM.36.	Nowo zarejestrowanemu użytkownikowi zewnętrznemu automatycznie nadawane są uprawnienia klienta WWI wraz z dostępem do wszystkich usług 13 JST Projektu.
CADM.37.	Wszyscy zarejestrowani użytkownicy zewnętrzni są widoczni dla administratora na liście użytkowników zewnętrznych.
CADM.38.	Tabela z użytkownikami umożliwia ich wyszukiwanie.
Rejestracja użytkownika wewnętrznego
CADM.39.	Tylko administrator będzie miał możliwość rejestrowania użytkowników wewnętrznych.
CADM.40.	Formularz rejestracji zawierać będzie pola, które należy wypełnić danymi osobowymi użytkownika i nazwą organizacji.
CADM.41.	Formularz rejestracji zawierać będzie listę dostępnych uprawnień do wszystkich aplikacji powstałych w ramach WWI i Systemu WZGIK.
CADM.42.	Możliwy będzie wybór wielu uprawnień jednocześnie.
CADM.43.	Pola w formularzu są objęte regułami walidacyjnymi, które wyświetlą się jako podpowiedzi.
CADM.44.	Wszyscy zarejestrowani użytkownicy wewnętrzni będą widoczni dla administratora na liście użytkowników wewnętrznych.
CADM.45.	Tabela z użytkownikami umożliwi ich wyszukiwanie.
CADM.46.	Musi być możliwość ograniczenia przestrzennego do danych.
	Rejestracja firmy lub podmiotu
CADM.47.	Formularz rejestracji zawierać będzie pola, które należy wypełnić danymi firmy.

CADM.48.	Pola w formularzu są objęte regułami walidacyjnymi, które wyświetlają się jako podpowiedzi.
CADM.49.	Wszystkie zarejestrowane firmy/podmioty będą widoczne dla administratora na liście firm i podmiotów, wraz z powiązanymi użytkownikami.
CADM.50.	Tabela z firmami/podmiotami umożliwia ich wyszukiwanie.
Użytkownicy reprezentujący firmę lub podmiot
CADM.51.	Użytkownikowi zewnętrznemu, który podczas rejestracji zaznaczył opcję reprezentowania firmy, Administrator przypiszą odpowiednią firmę lub podmiot.
CADM.52.	Użytkownicy, którzy oczekują na przypisanie firmy/podmiotu, są nieaktywni i mogą zostać aktywowani dopiero po uzupełnieniu danych przez Administratora.
CADM.53.	W ramach przeglądania danych firmy lub podmiotu z poziomu listy podmiotów, możliwe będzi wyświetlenie danych powiązanych użytkowników.
Edycja użytkowników oraz firm i podmiotów
CADM.54.	Aplikacja umożliwi edycję danych użytkowników zewnętrznych, użytkowników wewnętrznych (w tym reprezentujących firmę lub podmiot) oraz edycję danych firm i podmiotów.
CADM.55.	Podczas edycji danych firm i podmiotów, zablokowane do edycji będą pola identyfikujące podmiot w Systemie (nazwa i REGON).
CADM.56.	Administrator ma możliwość edycji wszystkich danych dotyczących zarejestrowanych użytkowników/firm, w tym hasła i uprawnień.
CADM.57.	Podczas wprowadzania zmian pola na formularzu edycji są walidowane.
CADM.58.	Administrator ma możliwość przypisania firmy/podmiotu użytkownikom.
CADM.59.	Administrator ma możliwość aktywacji oraz dezaktywacji zarejestrowanych użytkowników oraz firm i podmiotów.
CADM.60.	Administrator ma możliwość zablokowania użytkownika.
CADM.61.	Udostępnianie danych osobowych użytkownika.
CADM.62.	Aplikacja umożliwia wygenerowanie i wydruk raportu danych użytkownika.

CADM.63.	Aplikacja umożliwia udostępnienie (wydruk) danych osobowych użytkownika w wybranym zakresie.
CADM.64.	Raport i udostępnienie danych są funkcjami dostępnymi dla administratora.

VIII. Wymagania szczegółowe dotyczące zarządzania Danymi Przestrzennym

Zarządzanie Danymi Przestrzennymi
ZDP.1.	Funkcje Zarządzania Danymi Przestrzennymi podlegają uprawnieniom edycyjnym lub informacyjnym.
ZDP.2.	Funkcjonalności Zarządzania Danymi Przestrzennymi dotyczą: a. autoryzowanych Użytkowników Systemu Back-Office Geoportalu Publicznego, b. autoryzowanych Użytkowników Systemu produkcyjnego.
Drukowanie mapy
ZDP.3.	System musi zapewniać automatyzację generowania wydruków poprzez wykorzystanie szablonów wydruków i związanych z nimi kompozycji map.
ZDP.4.	Drukowanie musi realizować tryb WYSWYG, zapewniając zgodność drukowanych map z tym, co Użytkownik wyświetla na ekranie komputera.
ZDP.5.	Szablon wydruku musi zawierać takie parametry jak: • Określenie organu oraz niezbędnych elementów wymaganych prawem przy udostępnianiu materiałów wzgik oraz znaku wodnego. • tytuł, • dowolny tekst, • skalę, • format wydruku, do wyboru formaty od AO do A4 oraz format wstęgowy, • ramkę wydruku, • kompozycja mapy, • drukowane warstwy mapy, • Legenda, z możliwością określenia jakie warstwy mapy są widoczne w drukowanej • legendzie oraz z możliwością określenia nazw tych warstw dla potrzeb wydruku, • strzałkę północy,

• skala liniowa (mianowana i liczbowa), • klauzule.
ZDP.6.	System musi zapewniać drukowanie z poziomu mapy, które musi polegać na: a. wyborze szablonu wydruku, b. określeniu na mapie położenia kartek wydruku, wraz z możliwością indywidualnego określenia dla każdej z kartek wydruku jej skali, formatu wydruku oraz jej kąta obrotu, c. określeniu warstw mapy generowanych na wydruku, przy czym Użytkownik musi posiadać możliwość włączenia i wyłączenia wybranych warstw z legendy mapy, x. xxxxxxxxxx legendy drukowanej na wydruku, przy czym Użytkownik musi posiadać możliwość włączenia i wyłączenia warstw w drukowanej legendzie mapy, wraz z możliwością określenia nazw warstw dla potrzeb drukowanej legendy mapy, e. określeniu tytułu, opisu dodatkowego, ewentualnych klauzul.
ZDP.7.	System musi zapewniać drukowanie z poziomu dedykowanej aplikacji do generowania wydruków polegające na: a. wyborze szablonu wydruku, b. wyborze kompozycji mapy powiązanej z wydrukiem lub zmiany kompozycji mapowej, c. określeniu warstw generowanych na wydruku, przy czym Użytkownik musi posiadać możliwość włączenia i wyłączenia wybranych warstw z legendy mapy, d. określeniu legendy drukowanej na wydruku, przy czym Użytkownik musi posiadać możliwość włączenia i wyłączenia warstw w drukowanej legendzie mapy, wraz z możliwością określenia nazw warstw dla potrzeb drukowanej legendy mapy, e. określeniu tytułu, opisu dodatkowego, ewentualnych klauzul, f. określeniu, czy wybrane obiekty muszą być drukowane na jednej czy na wielu kartkach.
ZDP.8.	Użytkownik musi posiadać możliwość umieszczania na drukowanych mapach następujących elementów: a. wskazania obiektów na mapie i określenia ich odrębnej stylizacji dla potrzeb ich prezentacji na wydruku, b. rysowania obiektów punktowych, liniowych i obszarowych, wraz z określeniem ich stylu, c. umieszczania adnotacji, wraz z umieszczaniem odnośników.
ZDP.9.	Musi istnieć możliwość wstawienia na generowanych wydrukach znaków wodnych.

ZDP.10.	Zlecenia generowania wydruków muszą być przez System automatycznie kolejkowane.
ZDP.11.	Użytkownik po uruchomieniu funkcji generowania wydruku, musi posiadać możliwość kontynuowania pracy w Systemie. Po jego wygenerowaniu, Użytkownik musi otrzymać powiadomienie i wówczas może taki wydruk pobrać na stanowisko komputerowe.
ZDP.12.	Generowane wydruki muszą posiadać oznaczenia: a. daty wygenerowania wydruku, b. Odpowiedniej klauzuli ograniczającej wykorzystanie wydruku,znak wodny.
Eksportowanie Kompozycji Mapowych
ZDP.13.	Z poziomu okna mapy Użytkownik powinien mieć możliwość:
ZDP.14.	System musi umożliwiać zapisywanie wyświetlanych Kompozycji Mapowych do plików w formatach TIFF, JPG, PNG.
ZDP.15.	Zlecenia eksportowania plików muszą być przez System automatycznie kolejkowane. Użytkownik po uruchomieniu funkcji eksportu, musi posiadać możliwość kontynuowania pracy w Systemie. Po jego wyeksportowaniu Użytkownik musi otrzymać powiadomienie i wówczas może taki plik pobrać na stanowisko komputerowe.

IX. Wymagania szczegółowe dotyczące raportowania

Oprogramowanie szczegółowe dotyczące raportowania
RAP.1.	Raporty muszą być sformatowanymi wynikami zapytań do Bazy danych, działającymi w trybie on-line.
RAP.2.	Użytkownik musi posiadać możliwość określenia liczby rekordów wyświetlanych na stronie Raportu.
RAP.3.	Użytkownik powinien mieć możliwość wybrania kolumn, których treść ma być wyświetlana w Raporcie i określić kolejność ich wyświetlania.
RAP.4.	Użytkownik powinien mieć możliwość ukrywania i ponownego wyświetlania, treści wybranej kolumny Raportu.
RAP.5.	Użytkownik powinien mieć możliwość określenia zawartości Raportu poprzez zdefiniowanie filtru wyszukiwania, to znaczy określenie warunku, który musi spełniać

	treść wyświetlanych rekordów.
RAP.6.	Użytkownik powinien posiadać możliwość zdefiniowania filtru wyszukiwania dla każdej z wybranych kolumn, przy użyciu standardowych operatorów Bazy danych (=, !=, not in, between), znaku globalnego (%) i wprowadzeniu odpowiedniego wyrażenia.
RAP.7.	Użytkownik powinien posiadać możliwość zdefiniowania filtra wyszukiwania poprzez wpisanie złożonego zapytania SQL.
RAP.8.	Użytkownik powinien móc wyłączyć, ponownie włączyć, usunąć zdefiniowany filtr wyszukiwania.
RAP.9.	Użytkownik powinien mieć możliwość sortowania treści Raportu według wybranych kolumn rosnąco lub malejąco.
RAP.10.	Użytkownik powinien mieć możliwość wyróżnienia w Raporcie, za pomocą koloru, rekordów, których zawartość spełnia zdefiniowane przez Użytkownika kryteria, w tym: • powinna istnieć możliwość wybrania dla wyróżnienia koloru tła oraz koloru tekstu, • powinna istnieć możliwość zdefiniowania wielu kryteriów wyróżniania i określenia kolejności ich stosowania, • powinna istnieć możliwość wyróżnienia całego rekordu lub pola odpowiadającego wybranej kolumnie.
RAP.11.	Powinna istnieć możliwość dodania do Raportu kolumny, której wartość powstaje w wyniku wykonania obliczeń w oparciu o wartości innych kolumn. Obliczenia powinny móc wykorzystywać działania arytmetyczne oraz standardowe funkcje Bazy danych.
RAP.12.	Użytkownik powinien mieć możliwość podziału treści Raportu na grupy. Podział na grupy powinien następować w oparciu o treść wybranej kolumny lub wielu wybranych kolumn.
RAP.13.	Powinna istnieć możliwość prezentacji w raporcie zagregowanych danych wyliczonych w oparciu o dane grup rekordów, na które może być podzielony raport. Agregacja powinna móc wykorzystywać operacje: sumowania, obliczania wartości średniej, określenia liczby rekordów, określenia wartości minimalnej, określenia wartości maksymalnej, obliczenie mediany.
RAP.14.	Powinna istnieć możliwość prezentacji w Raporcie wykresu wykonanego na podstawie danych wyświetlanych w nim rekordów.
RAP.15.	Powinna istnieć możliwość prezentacji wykresów liniowych, kołowych, słupkowych (pionowych i poziomych).

RAP.16.	Powinna istnieć możliwość wybrania kolumn z wartościami do wykonania wykresu.
RAP.17.	Powinna istnieć możliwość wybrania kolumn z etykietami do wyświetlenia na wykresie.
RAP.18.	Użytkownik powinien mieć możliwość zapamiętania w Systemie skonfigurowanego przez siebie Raportu. Powinna istnieć możliwość nadania mu nazwy, opisu.
RAP.19.	Powinna istnieć możliwość zapisania Raportu w postaci pliku w jednym z formatów: tekstowy z polami oddzielonymi przecinkami (*.csv), *.html, Adobe Portable Document Format (*.pdf) lub Microsoft Word Rich Text Format (*.rtf).

X. Wymagania szczegółowe dotyczące Centralnej Baza Danych CUW

Centralna Baza Danych CUW
CBD.1.	CBD powinna mieć możliwość przechowywania wszystkich niezbędnych danych przestrzennych gromadzonych w ramach zadań CUW.
CBD.2.	CBD powinna działać na profesjonalnej platformie relacyjnej bazy danych.
CBD.3.	CBD oprócz danych przestrzennych powinna także przechowywać odpowiednie katalogi meta danych.
CBD.4.	Powinna istnieć możliwość pozyskiwania danych przestrzennych z CBD poprzez jawnie zdefiniowane interfejsy sprzętowo-programowe.
CBD.5.	Powinna istnieć możliwość formułowania zapytań pozwalających na selekcję części danych z CBD do pobrania przez administratora lub uprawnionego użytkownika.
CBD.6.	W CBD powinna być przechowywana informacja o historii pobierania obiektów.
CBD.7.	CBD powinna być obsługiwana przez aplikację zarządzającą pozwalającą na: • dodawanie, edycję (geometrii oraz atrybutów) i usuwanie danych w formacie wektorowym oraz rastrowym, • tworzenie, edycję oraz usuwanie metadanych zgodnie z przyjętymi profilami, • import i eksport danych w typowych formatach wektorowych i rastrowych (GML, SHP, DGN, DXF, DXG, MDB, KML, TXT, XLS, ASCII, GeoTIFF), • kontrolę spójności geometrycznej i atrybutowej z przyjętym modelem danych.

XI. Wymagania szczegółowe dotyczące Systemu zarządzania bazą danych, SZBD (ang. Database Management System, DBMS).

Database Management System, DBMS
DBMS.1.	Wymagane jest, aby licencja na oprogramowanie bazodanowe było bezterminowe.
DBMS.2.	Wymagane jest zapewnienie współpracy z systemem operacyjnym zainstalowanym na serwerach Zamawiającego. Wymagana jest niezależność platformy systemowej dla oprogramowania klienckiego/serwera aplikacyjnego od platformy systemowej bazy danych.
DBMS.3.	Wykonawca w maksymalny sposób ma wykorzystać istniejący motor bazy danych bądź zastosować rozwiązanie alternatywne w wuzgodnieniu z Zamawiajacym.
DBMS.4.	Wymagane jest, aby oprogramowanie bazodanowe zapewniało możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego.
DBMS.5.	Wymaga się, aby oprogramowanie bazodanowe przetwarzało dane z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.
DBMS.6.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało zagnieżdżanie transakcji – musi istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. Przykładowo – ma być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana.
DBMS.7.	Wymaga się, aby oprogramowanie bazodanowe miało wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).
DBMS.8.	Wymaga się, aby była możliwość migracji zestawu znaków bazy danych do Unicode.
DBMS.9.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało redefiniowanie przez klienta ustawień narodowych – symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych.
DBMS.10.	Wymaga się, aby oprogramowanie bazodanowe posiadało funkcję skalowania rozwiązań opartych o architekturę trójwarstwową, tzn.: możliwość uruchomienia wielu

	sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych.
DBMS.11.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało otworzenie wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych.
DBMS.12.	Wymagane jest wsparcie protokołu XA.
DBMS.13.	Wymaganie jest wsparcie standardu JDBC 3.0.
DBMS.14.	Wymagana jest zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym.
DBMS.15.	Wymaga się, aby motor bazy danych umożliwiał wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz dla wybranych zapytań. Musi istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL.
DBMS.16.	Wymaga się wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania musi być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu.
DBMS.17.	Wymaga się, aby procedury i funkcje składowane miały możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje muszą mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe muszą umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury).
DBMS.18.	Wymaga się, aby była możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej).
DBMS.19.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało deklarowanie wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego

	błędu w serwerze). Ponadto mechanizm wyzwalaczy musi umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views).
DBMS.20.	Wymaga się, aby w przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek.
DBMS.21.	Wymaga się, aby istniała możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych.
DBMS.22.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało wymuszanie złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku przekroczenia limitu nieudanych logowań.
DBMS.23.	Wymaga się, aby przywileje użytkowników bazy danych były określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu/modyfikacji tabeli, wykonania procedury). Oprogramowanie bazodanowe musi umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.
DBMS.24.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało: • wykonywanie i katalogowanie kopii bezpieczeństwa bezpośrednio przez serwer bazy danych; • zautomatyzowane usuwanie zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów; • integrację z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, OmniBack, ArcServe itd); • wykonywanie kopii bezpieczeństwa zarówno w trybie offline oraz w trybie online.
DBMS.25.	Wymaga się, aby oprogramowanie bazodanowe umożliwiało wykonywanie kopii bezpieczeństwa w trybie online (hot backup).
DBMS.26.	Wymaga się, aby odtwarzanie umożliwiało odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych.

DBMS.27.	Wymaga się, aby w przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników.
DBMS.28.	Wymaga się, aby oprogramowanie bazodanowe posiadało wbudowaną obsługę wyrażeń regularnych była zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych.
DBMS.29.	Licencja na bazę danych nie może nakładać ograniczeń co do ilości zdefiniowych administratorów i użytkowników oraz jednoczesnych sesji zarówno w aspekcie technicznym w przypadku rozbudowy infrastruktury sprzętowej jak i licencyjnym.
DBMS.30.	System bazodanowy musi dawać możliwość rozbudowy zarówno w zakresie funkcjonalności jak i liczby użytkowników.
DBMS.31.	System bazodanowy musi zapewniać skalowalność poziomą i pionową w zakresie wykorzystania infrastruktury.

XII. Wymagania szczegółowe dotyczące Systemu OWI

Serwer Danych Przestrzennych
SDP.1.	System zapewni generowanie map z danych zapisanych w następujących formatach: · Microsoft SQL Server, · Oracle, · PostgreSQL (PostGIS), · Shapefile, · WMS WMSC,WMTS, REST, ECWP, WFS, REST, WCS, CSW, WCTS, WPS, WMC (połączenie do innego serwera), · GeoTiff, · mozaika, · piramida, · pliki zewnętrzne.
SDP.2.	Generowanie map musi być procesem, możliwym do uruchomienia na: · platformie Linux (32 oraz 64 bity), · platformie Windows Server (32 oraz 64 bity), · platformie 64 bitowej, w trybie 64 bitowym oraz 32 bitowym.
SDP.3.	Mapy musza być generowane zgodnie z najnowszymi standardami OGC: · WMS,WMSC,WMTS, REST, ECWP, WFS, REST, WCS, CSW, WCTS, WPS,WMC · Filter Encoding Implementation Specification

SDP.4.	Musi istnieć możliwość transformacji współrzędnych w czasie rzeczywistym, na podstawie wbudowanej bazy układów współrzędnych zwierającej, co najmniej układy: · 1965 (wszystkie strefy), · 2000 (wszystkie strefy), · 1992, · UTM, · Google Mercator (EPSG:900913), · WGS 84 (EPSG:4326).
SDP.5.	WMS musi umożliwiać generowanie w formatach: · JPEG, · GIF, · PNG, · PDF, · SVG, · KML, · GeoRSS.
SDP.6.	Musi istnieć możliwość wygenerowania WMS z wykorzystaniem funkcji czasu. Należy utworzyć dla miasta Opola taka kompozycję opartą na dostępnych mapach topograficznych (standardowych i niestandardowych).
SDP.7.	Serwer map musi serwować dane przez WFS, co najmniej w następujących najnowszych wersjach formatów: · GML, · GeoJSON, · Shapefiles.
SDP.8.	Musi istnieć możliwość stosowania w WMS anti-aliasingu.
SDP.9.	Musi istnieć możliwość oobsługi zewnętrznych usług :WMS WMSC,WMTS, REST, ECWP, WFS, REST, WCS, CSW, WCTS, WPS, w tym z geoportalu krajowego. Utworzone przez system usługi muszą być czytelne przez geoportal krajowy.
SDP.10.	Musi istnieć możliwość tworzenia kafelków dla dowolnych skal i układów odniesienia, w tym: · tworzenie kafelków dla nowego poziomu skalowego dodanego do istniejących poziomów, · aktualizacją kafelków dla zadanego obszaru.
SDP.11.	Generowanie map odbywać się w trybie on-line, w którym mapa jest dynamiczną projekcją tworzoną na podstawie danych.

SDP.12.	Ewentualne Licencje na Serwer danych przestrzennych zostaną udzielone na czas nieoznaczony i będą to licencje nieodwołalne oraz nieograniczone ilościowo z możliwością instalacji na dowolnej liczbę instancji, serwerów, procesorów .
SDP.13.	Serwer Danych przestrzennych musi być w pełni zintegrowany z serwerem aplikacji tworząc jednolitą platformę rozwiązania aplikacyjnego.
	GEOPORTAL OWI
WO.1.	Geoportal OWI musi wizualizować mapę obszaru województwa objętego e-usługami.
WO.2.	Geoportal OWI musi zachować wszystkie dotychczasowe funkcjonalności.
WO.3.	Geoportal OWI musi dodatkowo posiadać funkje automatycznego pobierania plików (działanie na zasadzie funkcji: clip zip and ship) oraz funkcję łączenia sąsiednich rastrów.
WO.4.	Geoportal OWI musi wizualizować wszystkie dotychczasowe kompozycje mapowe oraz nowe niezbędne do prawidłowego działania zintegrowanych systemów, w tym bazujące na funkcji czasu.
WO.5.	Geoportal OWI musi posiadać możliwość wyszukiwania danych po zakresie przestrzennym, warstwach tematycznych oraz innych atrybutach mapy.
WO.6.	Geoportal OWI musi prezentować dane pochodzące z bazy Modułu WZGIK.
WO.7.	Geoportal OWI musi prezentować dane bazy BDOT10K zgodnie z symboliką kartograficzna oraz zapisami Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 2 listopada 2015 r. w sprawie bazy danych obiektów topograficznych oraz mapy zasadniczej (Dz.U. 2015 poz. 2028).
WO.8.	Geoportal OWI musi umożliwiać zaznaczenie na mapie zakresu lokalizacji. W celu właściwego oznaczenia przedmiotu wniosku Geoportal OWI musi obsługiwać: a. zapytania przestrzenne [dane w układach ·1965 (wszystkie strefy),2000 (wszystkie strefy),1992,UTM,Google Mercator (EPSG:900913),WGS 84 (EPSG:4326)]: • poprzez narysowanie przez interesariusza obszaru (poligonu) na wyświetlonej mapie w celu wybrania obiektów, • po wskazaniu punktowym, • po współrzędnych (zapisanych w pliku tekstowym), • wczytywanie obszaru zapisanego w pliku graficznym (shp, dxf), • wczytywanie zakresu z pliku gml.

	b. wyszukiwanie obiektów wg atrybutów: • jednostek podziału terytorialnego, • wykazu godeł arkuszy map, • wybranych klas obiektów CBD lub zintegrowanych usług np. nr działek, nr porządkowe nieruchomości, drogi, hydranty.
WO.9.	Geoportal OWI musi umożliwiać użytkownikowi wyszukiwanie zgodnie z nadanymi uprawnieniami dostępu do danych.
WO.10.	Moduł Zarządzania Danymi musi zapewnić zarządzanie prawami dostępu (login i hasło) do danych udostępnianych usługami sieciowymi.
WO.11.	Musi być zapewniona możliwość udostępniania serwisów na zewnętrznych geoportalach, w tym zapewnienia operacji odpowiednich dla serwisu, np: GetCapabilities, GetMap, GetFeatureInfo, DescribeFeatureType, GetGMLObject, GetFeature.
WO.12.	Musi być zapewniona rozliczalność operacji.

XIII. Wymagania poza funkcjonalne

Dokumentacja wdrożeniowa
PF.1.	Dopuszcza się aby zakres dokumentacji został dostosowanych do specyfiki wdrożenia realizowanego dla Strony Umowy.
PF.2.	Wymaga się aby terminy przekazywania poszczególnych elementów dokumentacji były uzgodnione ze Stroną Umowy i dostosowane do Harmonogramu wdrożenia.
PF.3.	Wykonawca będzie przekazywał dokumentację co najmniej w formatach PDF oraz formacie umożliwiającym edycję np. .doc, .docx. najpóźniej w dniu zgłoszenia gotowości do odbioru.
PF.4.	Na żądanie Strony Umowy Wykonawca przekaże dokumentację w postaci wydruku w ilości egzemplarzy uzgodnionych ze Stroną Umowy.
PF.5.	Bezwzględnie wymaga się aby cała dokumentacja wytworzona w ramach projektu i przekazywana formalnie została oznakowana zgodnie z wymaganiami EFRR RPO WO 2014 - 2020.
PF.6.	W terminie do 60 dni kalendarzowych od podpisania umowy, Wykonawca opracuje i przekaże Stronie Umowy Plan wdrożenia, będący efektem analizy przedwdrożeniowej, wykonanej przez Wykonawcę przy współudziale Strony Umowy.
PF.7.	W terminie do 10 dni roboczych od przekazania Strona Umowy przy udziale Inżyniera Projektu dokona weryfikacji Projektu technicznego wdrożenia. Wykonawca będzie miał 5 dni roboczych na poprawę i dostarczenie poprawionego dokumentu. Poprawiony dokument zostanie zweryfikowany w terminie do 10 dni roboczych od momentu jego dostarczenia.
PF.8.	Przed odbiorem danego etapu zamówienia, Wykonawca powinien wykonać przegląd Plan wdrożenia i Harmonogramu wdrożenia i jeśli to zasadne dokonać aktualizacji obu dokumentów w porozumieniu ze Stroną Umowy.
PF.9.	W terminie do 10 dni roboczych od dnia podpisania umowy, Wykonawca opracuje i przekaże Stronie Umowy do akceptacji Harmonogram wdrożenia stanowiący podstawowe narzędzie planowania i monitorowania prac projektowych. W terminie 5dni roboczych Strona Umowy uzgodni przekazany Harmonogram wdrożenia.
PF.10.	Harmonogram realizacji prac, uwzględniający: • Etapy projektu przedstawione w niniejszym rozdziale. W ramach Etapów powinny zostać uwzględnione

	zadania oraz: o Spotkania w ramach poszczególnych zadań, o Produkty dostarczane w ramach poszczególnych zadań, o Czas dla Zamawiającego na weryfikację produktów, o Czas dla Wykonawcy na dostosowanie produktów po ich weryfikacji przez Zamawiającego, o Testy; • Kamienie milowe; • Terminy zgodne z wyznaczonymi ramami czasowymi projektu, dla wszystkich elementów harmonogramu (czas rozpoczęcia i czas zakończenia). ⮚ Strategia Zarządzania Jakością. ⮚ Strategia Zarządzania Konfiguracją. ⮚ Strategia Zarządzania Komunikacją.
PF.11.	Wymaga się aby Projekt techniczny wdrożenia uwzględniał co najmniej następujące elementy: • Opis uwarunkowań technicznych realizacji zakresu zamówienia; • Opis technologii zastosowanych do realizacji zamówienia; • Opis architektury systemu; • Opis i charakterystyka danych i baz danych; • Opis wymaganych integracji z systemami dziedzinowymi oraz projekt przepływu danych : ▪ Zestawienie i charakterystyka systemów Strony Umowy, które będą podlegać integracji z wdrażanym rozwiązaniem, ▪ Opis technologii i standardów integracji z systemami Strony Umowy, ▪ Opis procedury i zakresu integracji wdrażanego rozwiązania z systemami Strony Umowy, ▪ Opis procedur i zakresu integracji wdrażanego rozwiązania z platformą e-PUAP, ▪ Opis procedur i zakresu integracji wdrażanego rozwiązania z systemami płatności elektronicznych, ▪ Schemat przepływu danych pomiędzy systemami, ▪ Zestawienie interfejsów wymiany danych pomiędzy systemami; • Opis technicznej realizacji e-usług wdrażanych w ramach przedmiotowego przedsięwzięcia; • Opis interfejsów użytkownika i kluczowych funkcjonalności systemu.
PF.12.	Dokumentacja powdrożeniowa zawierać: • Podręczniki administratora

• Podręczniki użytkownika –oraz filmy instruktażowe (DVD)

• Ostateczna wersja Projektu technicznego wdrożenia

• Dokumentację/zrzut struktur baz danych wdrożonego rozwiązania,

• Planu testów,

• Dokumentacja szkoleń

• Inne materiały i dokumenty wynikające ze specyfiki wdrożenia

XIV. Bezpieczeństwo Systemu

a. Uwierzytelnienie

1. System musi wykorzystywać mechanizm pojedynczego logowania (Single Sign-On) umożliwiający zalogowanym (uwierzytelnionym) Użytkownikom lub administratorom uzyskanie dostępu do poszczególnych danych, procesów i interfejsów Systemu na podstawie przyznanych im uprawnień, bez konieczności ponownego logowania.

2. System musi posiadać jednolitą, scentralizowaną strukturę Bazy Użytkowników, gdzie wszyscy Użytkownicy Systemu będą posiadać pojedyncze dane uwierzytelniające, co znacznie skróci czas poświęcany na rejestrację i logowanie Użytkownika do Systemu.

3. Wszystkie procesy i usługi sieciowe Systemu muszą używać tej samej Bazy do uwierzytelniania i autoryzacji Użytkowników.

4. System musi wymuszać odrębne i unikalne loginy oraz mieć możliwość modyfikacji ograniczeń x.xx. poprzez zmiany dot. długości hasła, wymuszanie złożoności hasła Użytkownika (wielkości i rodzaju znaków z wyłączeniem polskich znaków diakrytycznych) oraz częstotliwości zmiany hasła Użytkownika (zmiana standardowo ustawiona na modyfikację co najmniej raz na miesiąc) i blokadą powtórnego ustawienia tego samego hasła.

5. System musi umożliwiać sprawdzanie historii haseł, blokowanie konta przez administratora w przypadku przekroczenia limitu nieudanych logowań.

6. System musi posiadać mechanizmy zmiany hasła i odzyskiwania hasła.

b. Kontrola dostępu

1. Kontrola dostępu musi zapewniać przyznawanie uprawnień do poszczególnych aplikacji Systemu.

2. Jeżeli Użytkownik nie posiada przyznanych stosowanych uprawnień dostępu to aplikacje, procesy, interfejsy i dane muszą być dla niego niedostępne.

3. Kontrola dostępu musi pozwalać na:

• definiowanie hierarchii poszczególnych poziomów administracji Systemem, zgodnie z odpowiedzialnością poszczególnych jednostek za utrzymywane zasoby,

• zarządzanie określonymi aplikacjami w zakresie uprawnień administracyjnych, edycyjnych lub informacyjnych.

4. Kontrola dostępu musi zapewniać następujące, minimalne poziomy administracji Systemem.

5. Kontrola dostępu musi zapewniać scentralizowaną administrację uprawnieniami dostępu do poszczególnych Systemów Dziedzinowych, przynajmniej w zakresie:

• definiowania Użytkowników,

• przypisywania ról aplikacyjnych do Użytkowników,

• definiowania grup Użytkowników i przypisanych im ról,

• definiowania parametrów zabezpieczeń logowania i reguł haseł,

• definiowana harmonogramów logowania do Systemu.

c. Poufność

1. Poufność danych w Systemie musi być zapewniona dzięki wykorzystaniu szyfrowanej transmisji danych pomiędzy warstwą prezentacji z wykorzystaniem protokołu HTTPS. Transmisja może być niezaszyfrowana tylko w przypadkach, gdy wymieniane dane są publicznie dostępne dla anonimowych Użytkowników.

2. Wykonawca musi zaprojektować komunikację z Systemami zewnętrznymi w taki sposób, aby wywołania zewnętrznych Usług Sieciowych odbywały się za pomocą protokołu HTTPS.

d. Dostępność

1. Usługi będą dostępne w trybie całodobowym, 7 dni w tygodniu, 365 dni w roku, z przewidywanym oknem serwisowym, którego czas w skali roku nie przekroczy 0,3% łącznego czasu.

2. System musi zapewniać działania zgodnie z zasadami gwarantującymi taką eksploatację infrastruktury, aby zapewniać bezpieczeństwo informacji rozumiane jako: poufność, integralność i dostępność, przy uwzględnieniu autentyczności, rozliczalności, niezaprzeczalności i niezawodności.

3. System musi zapewniać zabezpieczenie dostępu do baz danych na poziomie danych, tabel i w szczególnych przypadkach pojedynczych ról.

e. Rozliczalność

1. Rozliczalność w Systemie musi podlegać wiarygodnemu dokumentowaniu w postaci elektronicznych zapisów w dziennikach Systemu (logach) zgodnie z wymaganiami § 21. ust. 1. Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla Systemów teleinformatycznych.

2. W dziennikach Systemu muszą być odnotowywane obligatoryjnie działania Użytkowników lub obiektów Systemowych polegające na dostępie do:

• Systemu z uprawnieniami administracyjnymi, takie jak: dodanie Użytkownika Systemu, edycja Użytkownika, zawieszenie Użytkownika, usunięcie Użytkownika, przypisanie/odebranie Użytkownikowi dostępu do aplikacji oraz związanych z nią uprawnień edycyjnych, informacyjnych i administracyjnych,

• konfiguracji Systemu, w tym konfiguracji zabezpieczeń,

• przetwarzanych w Systemach danych podlegających prawnej ochronie w zakresie wymaganym przepisami prawa.

3. System musi zapewniać odnotowywane działania Użytkowników lub obiektów Systemowych, a także inne zdarzenia związane z eksploatacją Systemu w postaci:

• działań Użytkowników nieposiadających uprawnień administracyjnych, do których należą działania dokonane przez Użytkowników we wszystkich trzech warstwach architektury trójwarstwowej,

• zdarzeń Systemowych nieposiadających krytycznego znaczenia dla funkcjonowania Systemu,

• zdarzeń i parametrów środowiska, w którym eksploatowany jest System teleinformatyczny.

4. System musi pozwalać na rejestrowanie działań Użytkowników, trzech warstw architektury trójwarstwowej:

• warstwy danych, obejmującej wszystkie dane/tabele Systemu, w tym:

o działania związane z aktualizacją danych Systemu, wraz z informacją o tym, jakie dane, kiedy i przez kogo zostały dodane, zaktualizowane lub usunięte,

o działania związane z wynikami procesów przetwarzania danych (np. uruchamianych skryptów PL/SQL),

• warstwy logiki biznesowej, w tym:

o i. działania związane z logowaniem do Systemu, zawierające minimum informacji o tym, kto i kiedy się logował, z jakiego adresu IP oraz jaki był wynik logowania do Systemu (pozytywny lub negatywny),

o ii. działania związane z uruchomianiem funkcji/procesów Systemu, wraz z informacją o tym, jakie procesy logiki biznesowej, kiedy i przez kogo zostały uruchomione,

• warstwy interfejsu Użytkownika, w tym działania związane z korzystaniem z Systemu, wraz z informacją o tym, jakie strony, kiedy i przez kogo były przeglądane.

5. System musi pozwalać na wgląd w działania Użytkowników, w tym:

• administrator Systemu musi posiadać wgląd w działania wszystkich Użytkowników Systemu,

• administrator JST musi posiadać wgląd w działania Użytkowników danej jednostki,

6. System musi przechowywać informację dotyczącą daty utworzenia i modyfikacji danego rekordu oraz informację o Użytkowniku, który utworzył lub zmodyfikował dany rekord. Informacja ta musi być dostępna dla Użytkownika z poziomu interfejsu Systemu.

f. Kopie bezpieczeństwa

1. System musi zapewniać tworzenie kopii zapasowych Systemu z wykorzystaniem urządzeń archiwizujących i serwerów posiadanych przez Zamawiającego. Wykonawca jest zobowiązany opracować i wdrożyć harmonogramy tworzenia kopii zapasowych oraz procedury odtworzenia w przypadku awarii.

2. Kopie zapasowe Systemu muszą obejmować cały System, w tym jego dane, logiki biznesowe, interfejsy Użytkownika.

3. System musi umożliwiać wybór między archiwizacją pełną, a przyrostową, przy założeniu, że na podstawie kopii zapasowych powinno być możliwe automatyczne odtworzenie Systemu wraz z danymi w dowolnym momencie.

4. System musi umożliwiać wykonywanie kopii bezpieczeństwa wg określonego scenariusza, nie rzadziej niż raz dziennie. Kopie bezpieczeństwa mają zapewniać możliwość niezwłocznego odzyskania danych i przywrócenia całego Systemu do stanu normalnej pracy po ewentualnej awarii sprzętowej lub programowej.

5. Przywrócenie całego Systemu z kopii bezpieczeństwa musi być możliwe w czasie nie dłuższym niż 8 godzin.

g. Zabezpieczenie przed atakami

1. Aplikacje webowe muszą być zabezpieczone przed atakami typu "SQL Injection" poprzez niedopuszczenie do nieuprawnionej zmiany wykonywanego zapytania.

2. Aplikacje webowe zapisujące dane w bazie danych muszą unieszkodliwiać niedozwolone znaki w danych wejściowych do Bazy.

3. Parametry zapytań sql wykonywanych z poziomu aplikacji nie mogą być wklejane w zapytanie, ale muszą być przekazywane jako parametry (bind variables) procedur składowanych w bazie danych, a aplikacja nie ma bezpośredniego wpływu na ich postać, chociaż i w tym przypadku skonstruowanie ataku nie jest niemożliwe.

4. Wykonawca musi zaprojektować aplikacje webowe w taki sposób, aby były odporne na ataki Cross- site scripting (XSS) i Cross-site request forgery (XSRF), ponadto:

• nie można na stronie zamieszczać odnośników do skryptów znajdujących się na innych serwerach,

• jeśli strona jest udostępniana po protokole HTTPS, to także wszystkie jej komponenty zależne (obrazki, skrypty, arkusze stylów, itp.).

5. Wykonawca musi skonfigurować serwery aplikacji w taki sposób, aby automatycznie zamykały sesję zalogowanego Użytkownika po definiowalnym przez administratora czasie nieaktywności.

h. Ochrona danych osobowych

1. System musi być zgodny z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE.

2. Dostęp do danych osobowych Systemu musi wymagać zarejestrowania stosownego upoważnienia. Jeśli Użytkownik nie posiada upoważnienia to w interfejsie Systemu dane osobowe nie mogą być dla niego widoczne.

3. Upoważnienie musi zawierać informacje o Rejestrze, którego dotyczy oraz dacie jego obowiązywania.

4. System musi zapewniać odnotowanie przetwarzania danych osobowych w Systemie, w tym:

• daty pierwszego wprowadzenia danych osobowych do Systemu,

• identyfikatora Użytkownika wprowadzającego dane,

• źródła danych w przypadku zbierania danych, nie od osoby, której one dotyczą,

• informacji o odbiorcach danych.

5. System musi przechowywać informacje o osobach trzecich, którym dane osobowe zostały udostępnione, w tym informacje o tym jakie dane/dokumenty, w jakim celu, jakim osobom trzecim, kiedy i kto udostępnił.

6. System musi umożliwiać sporządzenie i wydrukowanie raportu dotyczącego wprowadzonych danych osobowych do Systemu, zawierającego informacje o dacie pierwszego wprowadzenia danych do Systemu, identyfikatora Użytkownika wprowadzającego, źródła danych w przypadku zbierania danych, nie od osoby, której one dotyczą, informacji o odbiorcach.

7. System musi umożliwiać sporządzenie i wydrukowanie raportu zawierającego informacje

o tym, jakie dane przechowane są o danej osobie i w jakich Rejestrach.

8. System musi umożliwiać sporządzenie i wydrukowanie raportu zawierającego informacje

o tym, jakie dane osobowe danej osoby zostały udostępnione osobom trzecim, kiedy i w jakim celu.

XV.Licencjonowanie

1. Wykonawca w ramach realizacji projektu musi dostarczyć licencje na następujące produkty:

a) Licencje na oprogramowanie Serwera Danych Przestrzennych, które muszą być nielimitowane co do ilość licencji na serwery/procesory.

b) Licencje na oprogramowanie dziedzinowe muszą być nielimitowane co do ilość licencji na serwery/procesory.

c) Licencje na oprogramowanie bazodanowe.

d) Jeśli do prawidłowego działania oprogramowania potrzebna jest większa ilość licencji Wykonawca dostarczy wymaganą liczbę i rodzaj licencji wraz ze wsparciem technicznym producenta na okres nie krótszy niż okres gwarancji na przedmiot zamówienia

2. Dostarczane przez Wykonawcę licencje muszą być udzielone na czas nieokreślony.

3. Dostarczone licencje muszą posiadać następujące cechy:

a) Wszystkie licencje na dostarczane oprogramowanie, powinny obejmować nieograniczoną liczbę stanowisk Użytkowników Systemu.

b) Wszystkie licencje na dostarczane oprogramowanie, nie mogą posiadać ograniczeń związanych z uruchamianiem w środowisku zwirtualizowanym.

XVI. Szkolenia

a. Zakres szkoleń

Wymaga się, aby po uruchomieniu Portalu CUW Wykonawca przeprowadził szkolenie z obsługi i administrowania CMS dla wybranych pracowników każdego z Partnerów projektu wraz z dostarczeniem instrukcji stanowiskowej.

b. Organizacja szkoleń

1. Szkoleniem objęci zostaną pracownicy partnerów projektu w zależności od numeru części zamówienia, zgodnie z poniższą tabelą:

Lp.	Powiat	Liczba osób	Liczba osób więcej/mniej do przeszkolenia
I.	Powiat Brzeski	2	1
II.	Powiat Kozielski	2	1
III.	Powiat Kluczborski	2	1
IV.	Powiat Krapkowicki	2	1
V.	Powiat Namysłowski	2	1
VI.	Powiat Nyski	2	1
VII.	Powiat Xxxxxx	0	0

XXXX	Xxxxxx Xxxxxxx	2	1
IX.	Powiat Prudnicki	2	1
X.	Powiat Strzelecki	2	1
XI.	Miasto Opole	2	1
XII.	Powiat Xxxxxxxxxx	0	0
XXXX	Xxxxxxxxxxx Xxxxxxxx	5	2

2. Szczegółowy harmonogram szkoleń Wykonawca uzgodni z Zamawiającym.

3. Każdy uczestnik będzie brał udział w 8 godzinach szkolenia (jeden dzień dni).

4. Szkolenia prowadzone będą w formie wykładów i zajęć praktycznych. Zajęcia praktyczne będą stanowiły około ¾ czasu szkolenia.

5. Szkolenia prowadzone będą w dni robocze w godzinach od 8 do 16. Dzienny maksymalny wymiar zajęć powinien wynosić nie mniej niż 6 i nie więcej niż 9 godzin szkoleniowych, wliczając przerwy (1 godzina szkoleniowa – 45 minut).

6. Zajęcia prowadzone będą w maksymalnie 18 osobowych grupach. Szkolenia dla Administratorów i Użytkowników odbywają się oddzielnie, według indywidualnych planów.

7. W czasie zajęć praktycznych przy jednym stanowisku komputerowym pracować będzie jedna osoba (uczestnik szkolenia).

8. Wykonawca zapewni stanowisko komputerowe, dla każdego uczestnika danego szkolenia.

9. Zajęcia praktyczne przeprowadzane będą na sprzęcie komputerowym z wykorzystaniem oprogramowania zapewnionego przez Wykonawcę.

10.Zakres i program szkolenia musi być dostosowany do rodzaju szkolenia oraz do potrzeb poszczególnych partnerów projektu (w uzgodnieniu z Zamawiającym).

11.Każde szkolenie zakończone będzie testem sprawdzającym (treść testu zostanie uzgodniona z Zamawiającym).

12.Uczestnicy otrzymają imienne certyfikaty udziału w szkoleniu.

13.Zakres szkoleń Użytkowników obejmować będzie zagadnienia z zakresu wdrażanych i rozwijanych w ramach projektu e-usług odpowiednio dla danego Partnera.

14.Zakres szkoleń dla administratorów będzie obejmował zagadnienia zarządzania systemem.

c. Rekrutacja i dokumentacja szkoleniowa

1. Szkolenia zostaną zorganizowane w sposób umożliwiający nieprzerwaną pracę wydziałów geodezji. Wykonawca przedstawi propozycję co najmniej 2 terminy szkolenia.

2. Rekrutację uczestników szkoleń przeprowadzi Wykonawca w uzgodnieniu z Zamawiającym

3. W ramach prowadzenia rekrutacji Wykonawca odpowiada za:

a. przyjmowanie zgłoszeń,

b. potwierdzanie i anulowanie udziału w szkoleniach,

c. kontakt z uczestnikami w sprawie szkoleń,

d. przestrzeganie ustawy o ochronie danych osobowych,

e. na każde wezwanie Zamawiającego informowanie go o stanie rekrutacji grup szkoleniowych oraz bieżących postępach z realizacji zamówienia.

4. Wykonawca przekaże Zamawiającemu listy uczestników szkoleń. Listy powinny zawierać: imię i nazwisko, email, telefon, dane jednostki którą reprezentuje.

5. Na zakończenie każdego szkolenia uczestnicy otrzymają do wypełnienia anonimową ankietę ewaluacyjną, mającą na celu ocenę programu, sposobu organizacji i przeprowadzenia szkolenia.

6. Wykonawca po przeprowadzeniu każdego szkolenia przekaże Zamawiającemu: podpisane listy obecności, potwierdzenia otrzymania materiałów szkoleniowych, potwierdzenia otrzymania certyfikatu udziału w szkoleniu oraz wypełnione ankiety ewaluacyjne.

7. Po każdym szkoleniu Wykonawca przygotuje raport z jego przeprowadzenia, zawierający: termin i miejsce szkolenia oraz jego szczegółowy zakres.

8. Na zakończenie Wykonawca przygotuje raport końcowy z realizacji zamówienia.

9. Wykonawca jest zobowiązany przekazać raporty, o których mowa w pkt 8 w ciągu 7 dni roboczych od daty zakończenia danego szkolenia oraz raport końcowy w terminie 14 dni roboczych od daty zakończenia zadania.

10.Treść i forma raportów zostanie zaproponowana przez Wykonawcę i uzgodniona z Zamawiającym.

11.Wykonawca zobowiązany będzie do bieżącego przekazywania Zamawiającemu informacji na temat stanu realizacji zamówienia.

d. Miejsce szkoleń

1. Zamawiający udostępni wykonawcy salę odpowiednią do przeprowadzenia szkoleń.

2. Wykonawca jest zobowiązany do ustalenia terminu planowanych szkoleń w ścisłej współpracy z zamawiającym.

3. Każdy uczestnik szkolenia powinien mieć zapewnione stanowisko komputerowe z oprogramowaniem umożliwiającym instalację i obsługę oprogramowania, na którym prowadzone będą zajęcia praktyczne, z dostępem do Internetu, niezbędnymi licencjami oraz oprogramowaniem antywirusowym

4. W miejscu szkolenia Wykonawca zapewni w każdym dniu szkolenia, wyżywienie obejmujące:

a. całodzienny serwis kawowy podczas 2 dni szkolenia, składający się z co najmniej: kawy z zaparzacza lub ekspresu, herbaty (co najmniej trzy rodzaje, w tym jedna czarna i jedna owocowa), wody mineralnej (gazowanej i niegazowanej), soków, przekąsek słonych i słodkich,

b. dwa dwudaniowe xxxxxx (w pierwszy i drugi dzień szkolenia) w formie zupy i drugiego dania.

Szczegółowe menu zostanie uzgodnione z Zamawiającym na 5 dni przed planowanym terminem szkolenia.

5. Wykonawca nie pokrywa kosztów dojazdów uczestników na szkolenia.

6. W miejscu szkolenia Wykonawca umieści informację o finansowaniu szkolenia ze środków Regionalnego Programu Operacyjnego Województwa Lubelskiego na lata 2014- 2020 oraz zapewni w czasie trwania szkolenia warunki odpowiadające przepisom z zakresu bezpieczeństwa i higieny pracy oraz p.poż.

e. Materiały szkoleniowe

1. Wykonawca przygotuje dla uczestników szkoleń materiały szkoleniowe oraz przekaże je każdemu uczestnikowi nie później niż w dniu rozpoczęcia zajęć.

2. Wykonawca zaproponuje i uzyska akceptację Zamawiającego w zakresie materiałów szkoleniowych, obejmujących minimum:

- podręcznik - obejmujący zakres projektu wraz z omówieniem zagadnień związanych z tematyką szkoleń,

- prezentacje multimedialne – obejmujące zakres projektu, wykłady, ćwiczenia szkoleniowe,

- teczka typu aktówka formatu A4,

- notatnik z długopisem,

3. Wykonawca przekaże Zamawiającemu materiały szkoleniowe w formie źródłowej w wersji edytowalnej oraz w formacie pdf.

XVII. Testy

W ramach weryfikacji wdrożonych rozwiązań, Strona Umowy wymaga przygotowania i przeprowadzenia testów realizowanych przy udziale Wykonawcy, Inżyniera Projektu oraz Strony Umowy.

W ramach realizacji etapu III wymaga się przygotowania i przeprowadzenia testów w zakresie:

Testy Akceptacyjne – obejmujące potwierdzenie, że rozbudowany i zmodernizowany System spełnia wymagania funkcjonalne oraz pozafunkcjonalne (w szczególności bezpieczeństwa, powiązania z innymi obszarami funkcjonalnymi/systemami). Testy Akceptacyjne będą prowadzone w środowisku testowym. Zakończenie Testów Akceptacyjnych będzie warunkiem rozpoczęcia wdrożenia docelowego .

Testy Zatwierdzające – obejmujące potwierdzenie, że rozbudowany i zmodernizowany system PZGiK spełnia wymagania funkcjonalne oraz pozafunkcjonalne. Testy Zatwierdzające będą prowadzone po zakończeniu wdrożenia masowego w środowisku produkcyjnym. Po testach wymagane jest przywrócenie systemu za stan z przed testów zatwierdzających

Wykonawca zaproponuje metodykę testów z uwzględnieniem uzgodnienia i uruchomienia wersji testowej i produkcyjnej całego rozwiązania i poszczególnych komponentów.

Wykonawca powinien przygotować Plan Testów opisujący zasady organizacji i realizacji testów akceptacyjnych i zatwierdzających wdrażanego rozwiązania z uwzględnieniem:

• przygotowania,

• przeprowadzenia,

• dokumentowania przebiegu testów wdrażanego rozwiązania.

Plan Testów jest dokumentem organizacyjno – technicznym służącym zaplanowaniu testów, opracowanym przez Wykonawcę. Rolą Planu Testów jest przygotowanie do przeprowadzenia testów dla dostarczonego przez Wykonawcę rozwiązania w takim zakresie, aby możliwe było zweryfikowanie i potwierdzenie jego zgodności z Zamówieniem. Plan Testów musi zawierać co najmniej scenariusze testowe:

• z poziomu klienta wewnętrznego,

• z poziomu klienta zewnętrznego obejmujące wszystkie e-usługi dostarczone w ramach niniejszego zamówienia.

Każdorazowo przed przystąpieniem do kolejnej tury testów, nie później niż na 5 dni roboczych przed rozpoczęciem testów, Wykonawca ze Stroną Umowy oraz Inspektorem Nadzoru, uzgodni techniczne warunki realizacji testów, Plan testów, konieczne dostępy do środowiska testowego/preprodukcyjnego/produkcyjnego, użytkowników testowych.

Na zakończenie procesu testowania Wykonawca dostarczy Stronie Umowy ora raport z testów wraz z załącznikami umożliwiającymi weryfikacje testów, najpóźniej do 10 dni roboczych od zakończenia testów.

Niezależnie od wyżej opisanych scenariuszy Strona Umowy zastrzega sobie prawo do przeprowadzenia testów według dodatkowych scenariuszy.

XVIII. Gwarancja

Wykonawca zobowiązany jest do świadczenia serwisu gwarancyjnego przez okres wskazany w umowie, przy czym:

1. Okres świadczenia serwisu gwarancyjnego rozpoczyna się z dniem podpisania przez Strony końcowego protokołu odbioru bez uwag.

2. W okresie gwarancji Zamawiający nie ponosi dodatkowych kosztów związanych z korzystaniem z Systemu. Koszty te Wykonawca uwzględnia w cenie za realizację przedmiotu zamówienia.

3. W okresie trwania serwisu gwarancyjnego Wykonawca jest zobowiązany do wykonywania świadczeń gwarancyjnych polegających na:

a. skutecznym rozwiązywaniu Zgłoszeń,

b. dostarczaniu, instalacji i wdrażaniu niezbędnych lub celowych poprawek (w tym tzw. łat programowych - ang. „patch") Systemu,

c. podnoszenie wersji bazy w ramach serwisu gwarancyjnego,

d. innych koniecznych działaniach zapewniających prawidłowe - tzn. nieograniczone czasowo i funkcjonalnie działanie Systemu.

4. Wszelkie świadczenia dostarczone przez Wykonawcę w ramach serwisu gwarancyjnego będą wykonywane przez wykwalifikowany i posiadający wystarczającą wiedzę na temat Systemu personel.

5. Wykonawca jest zobowiązany zrealizować wszelkie świadczenia w ramach serwisu gwarancyjnego w taki sposób, aby zapewnić pełną funkcjonalność Systemu w trakcie i po zrealizowaniu świadczenia.

6. Wszelkie działania związane ze świadczeniem serwisu gwarancyjnego muszą być wykonywane z wiedzą i akceptacją Zamawiającego.

7. W okresie trwania serwisu gwarancyjnego Wykonawca zobowiązany jest do:

a. dostarczania nowych wersji lub uaktualnienia oprogramowania wchodzącego w skład Systemu w przypadku, gdy nastąpią zmiany w obowiązującym prawodawstwie, wymagające nowszej wersji lub uaktualnienia oprogramowania,

b. instalacji nowych wersji lub uaktualnień oprogramowania w terminach uzgodnionych z Zamawiającym,

c. usprawniania obsługi Systemu poprzez wprowadzanie autorskich udoskonaleń w technologii i funkcjonalności oprogramowania.

d. Szkolenia użytkowników i administratorów z zakresu nowych funkcjonalności, o których mowa w ppkt. a-c oraz aktualizacja Dokumentacji w tym zakresie.

8. Awarie, problemy, incydenty i zdarzenia w działaniu Systemu będą usuwane przez Wykonawcę na podstawie zgłoszeń dokonywanych przez Zamawiającego na piśmie, wysłanych na adres Wykonawcy lub w formie elektronicznej poprzez system helpdesk bądź pocztę elektroniczną na wskazany przez wykonawcę adres email. W zgłoszeniu Zamawiający zobowiązany będzie do podania opisu błędu. Zgłoszenia przesłane do Wykonawcy po godzinie 16.00 danego dnia będą traktowane jako zgłoszenia wpływające następnego dnia roboczego.

9. Usuwanie zgłoszeń będzie następowało w zależności od jego typu w następujących terminach:

a. w przypadku awarii krytycznej Wykonawca przystąpi niezwłocznie do jej usunięcia i usunie ją lub zastosuje rozwiązanie zastępcze umożliwiające pracę systemu w terminie nie dłuższym niż 2 dni robocze, licząc od dnia następnego po dniu, w którym nastąpiło zgłoszenie do Wykonawcy. W przypadku zastosowania rozwiązania zastępczego Wykonawca usunie błąd w terminie nie dłuższym niż 5 dni roboczych, licząc od dnia następnego po dniu, w którym zostało zastosowane rozwiązanie zastępcze,

b. w przypadku pozostałych zgłoszeń Wykonawca przystąpi do ich usunięcia nie później niż w ciągu 5 dni roboczych i usunie je w terminie nie dłuższym niż 5 dni roboczych, licząc od dnia zgłoszenia Wykonawcy.

10. W przypadku, gdy realizacja zgłoszenia wymaga przeprowadzania przez Wykonawcę prac za pomocą bezpiecznego połączenia sieciowego z systemem (VPN lub innego ustalonego pomiędzy Stronami), zainstalowanym w infrastrukturze teleinformatycznej Zamawiającego, terminy określone w ppkt. 9 a i b, przewidziane na usunięcie błędów w działaniu wskazanych elementów przedmiotu Umowy, ulegają zawieszeniu do czasu udostępnienia przez Zamawiającego bezpiecznego połączenia.

11. Dodatkowo w okresie wdrażania oraz w ramach serwisu gwarancyjnego będzie świadczył usługi obejmujące:

a. Konsultacje dotyczące funkcjonowania Systemu:

• konsultacje telefoniczne, w każdy dzień roboczy, dotyczące rozwiązywania bieżących problemów użytkowników Systemu,

• konsultacje za pośrednictwem poczty elektronicznej na wskazany przez Wykonawcę adres (e-mail), dotyczące rozwiązywania bieżących problemów użytkowników Systemu,

• konsultacje za pomocą bezpiecznego połączenia sieciowego z Systemem (VPN lub innego ustalonego pomiędzy Stronami), zainstalowanym w infrastrukturze teleinformatycznej Zamawiającego.

b. Konsultacje oraz udzielenie porad w zakresie zainstalowania nowej wersji lub uaktualnień oprogramowania.

XIX. Podstawowe wymagania prawne

Wykonawca oprócz uwarunkowań szczegółowych zawartych w niniejszym dokumencie musi uwzględniać:

1. Przepisy ogólne służące powstaniu infrastruktury informacji przestrzennej we Wspólnocie Europejskiej, które ustanowiła:

a. Dyrektywa INSPIRE - dyrektywa 2007/2/WE Parlamentu Europejskiego i Rady UE z 14 marca 2007 r. ustanawiająca infrastrukturę informacji przestrzennej we Wspólnocie Europejskiej (INSPIRE); (Dz. U. Unii Europejskiej nr L 108/1);

Dyrektywa INSPIRE

i które zostały zaimplementowane do warunków polskich. W konsekwencji powstała:

b. Ustawa o IIP - ustawa z 4 marca 2010 r. o infrastrukturze informacji przestrzennej (Dz. U. z 2017 r. poz. 1282 z późn. zm.).

2. Przepisy branżowe, które zostały zmienione po ustanowieniu przepisów ogólnych, tj.:

x. xxxxxx PGiK - ustawa Prawo geodezyjne i kartograficzne z 17 maja 1989 r. (tekst jednolity Dz. U. z 2017 r., poz. 2101) oraz nowe akty wykonawcze:

• rozporządzenie EGiB - rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z 29 marca 2001 r. w sprawie ewidencji gruntów i budynków (tekst jednolity Dz.U. z 2016 r., poz. 1034)

• rozporządzenie zmieniające EGiB – rozporządzenie Ministra Infrastruktury i Budownictwa z 27 września 2017 r zmieniające rozporządzenie w sprawie ewidencji gruntów i budynków (Dz.U. 2017, poz. 1990)

• rozporządzenie EMUiA - rozporządzenie Ministra Administracji i Cyfryzacji z 9 stycznia 2012 r. w sprawie ewidencji miejscowości, ulic i adresów (Dz. U. z 2012 r., poz. 125)

• rozporządzenie BTOT500 - rozporządzenie Ministra Administracji i Cyfryzacji z 2 listopada 2015 r. w sprawie bazy danych obiektów topograficznych oraz mapy zasadniczej (Dz.U. z 2015 r., poz. 2028)

• rozporządzenie GESUT - rozporządzenie Ministra Administracji i Cyfryzacji z 21 października 2015 r. w sprawie powiatowej bazy GESUT i krajowej bazy GESUT (Dz.U. z 2015 r., poz. 1938)

• rozporządzenie BDSOG - rozporządzenie Ministra Administracji i Cyfryzacji z 14 lutego 2012 r. w sprawie osnów geodezyjnych, grawimetrycznych i magnetycznych (Dz.U. z 2012 r., poz. 352)

• rozporządzenie PZGiK - rozporządzenie Ministra Administracji i Cyfryzacji z 5 września 2013 w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego (Dz.U. z 2013 r., poz. 1183), które weszło w życie 7 stycznia 2014 r.

• rozporządzenie w sprawie standardów - rozporządzenie Ministra Spraw Wewnętrznych i Administracji z 9 listopada 2011 r. w sprawie standardów technicznych wykonywania geodezyjnych pomiarów sytuacyjnych i wysokoś- ciowych oraz opracowywania i przekazywania wyników tych pomiarów do państwowego zasobu geodezyjnego i kartograficznego (Dz.U. z 2011 r. nr 263, poz. 1572)

• rozporządzenie w sprawie uwierzytelniania - rozporządzenie Ministra Administracji i Cyfryzacji z 8 lipca 2014 r. w sprawie sposobu i trybu uwierzytelniania przez organy Służby Geodezyjnej i Kartograficznej dokumentów na potrzeby postępowań administracyjnych, sądowych lub czynności cywilnoprawnych (Dz. U. z 2014 r., poz. 914)

• rozporządzenie w sprawie formularzy - rozporządzenie Ministra Administracji i Cyfryzacji z 8 lipca 2014 r. w sprawie formularzy dotyczących zgłaszania prac geodezyjnych, zawiadomienia o wykonaniu tych prac oraz przekazywania ich wyników do państwowego zasobu geodezyjnego i kartograficznego (Dz. U. z 2014 r. poz. 924)

• rozporządzenie w sprawie udostępniania - rozporządzenie Ministra Administracji i Cyfryzacji z 9 lipca 2014 r. w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty (Dz. U. z 2014 r., poz. 917).

• rozporządzenie zmieniające rozporządzenie w sprawie udostępniania – rozporządzenie Ministra Infrastruktury i Budownictwa z 13 września zmieniające

rozporządzenie w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty (Dz. U. z 2017 r. poz. 1989).

3. Przepisy dotyczące ogólnych zasad informatyzacji Państwa, które nie zostały zaimplementowane w przepisach branżowych, a głównie:

a. Ustawa z 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t. j. Dz. U. z 2017 r., poz. 570) oraz przepisach wykonawczych:

• rozporządzenie Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (t. j. Dz. U. z 2017 r., poz. 2247)

• rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych z rejestru publicznego - art. 15 ust. 3 ustawy (Dz. U. Nr 2005, poz. 1692)

• rozporządzenie Rady Ministrów z 6 października 2016 r. zmieniające rozporządzenie w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U z 2016 r. poz.1634)

• rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz.U. 2016 r., poz.1633)

• rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do uwierzytelniania użytkowników (Dz.U. 2016 r., poz.1626)

• rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U. 2016 r., poz.1626)

b. Ustawa z 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (t. j. Dz. U. z 2017 r., poz. 1219)

c. Ustawa z 29 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz. U. z 2016 r., poz. 1579).

Wykonawca przy tworzeniu aplikacji powinien uwzględniać nie tylko schematy aplikacyjne, które zostały opublikowane w przepisach branżowych wymienionych w punkcie 2., ale również schematy aplikacyjne, które mogą być publikowane w repozytorium interoperacyjności, o którym mowa

w przepisach wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.

Udostępnianie danych powinno odbywać się w formacie GML z zastosowaniem schematów aplikacyjnych oraz systemów zapewniających minimalne wymagania dla systemów teleinformatycznych, zapewniając tym samym interoperacyjność semantyczną i technologiczną.