Projekt techniczny budowy systemu MSZ-KIIP

Projekt techniczny budowy systemu MSZ-KIIP rozumiany jako szczegółowa koncepcja MSZ-KIIP wraz z jego analizą funkcjonalną Strona 1 z 185

Spis treści 1 Metryka dokumentu... 8 1.1 Aspekt formalny... 9 1.2 Cel dokumentu... 9 1.3 Przeznaczenie dokumentu... 9 1.4 Zakres opracowania oraz stan prawny... 9 1.5 Metodyka prac projektowych struktura dokumentu... 11 2 Koncepcja MSZ-KIIP... 12 2.1 Ogólne założenia... 12 2.1.1 Dane georeferencyjne - dane z baz danych PZGiK... 20 2.1.2 Gromadzenie danych... 20 2.1.3 Metadane... 21 2.1.4 Integracja danych adresowych mapowanie danych... 21 2.1.5 Implementacja e-usług oraz integracja z EOD... 21 2.2 Architektura systemu... 24 2.2.1 Architektura logiczna... 24 2.2.2 Uwarunkowania prawne mające wpływ na architekturę oraz funkcjonalność systemu25 2.2.3 Uwarunkowania lokalne mające wpływ na rozwiązania techniczne systemu... 29 2.2.4 Architektura fizyczna... 29 2.2.4.1 Głownie założenia techniczne... 29 2.3 Infrastruktura sprzętowa na potrzeby MSZ-KIIP... 31 2.3.1 Koncepcja Centrum Przetwarzania Danych MSZ-KIIP (CPD)... 31 2.3.1.1 Ogólne założenia... 31 2.3.1.2 Koncepcja techniczna CPD... 32 2.3.2 Proponowana infrastruktura techniczna (sprzętowa)... 35 2.3.2.1 Koncepcja logiczna wydzielenia urządzeń (serwery)... 36 2.3.2.2 Analiza zapotrzebowania w zakresie mocy przetwarzania danych... 37 2.3.2.3 Wstępny podział zasobów dyskowych... 44 Strona 2 z 185

2.3.2.4 Założenia dot. polityki bezpieczeństwa systemu w zakresie zabezpieczenia ciągłości pracy 44 2.3.3 Dyskusja dotycząca opcji implementacyjnej SaaS oraz kolokacja... 46 2.3.3.1 Usługi SaaS / kolokacja... 46 2.3.3.2 Dyskusja nt. koncepcji infrastruktury dostępowej do sieci publicznej Internet na potrzeby przetwarzania w chmurze oraz kolokacji infrastruktury IT... 47 2.3.3.3 Wnioski... 51 2.3.4 Konfiguracji podsieci infrastruktury sprzętowej... 52 3 Opis osiągnięcia przewidywanych rezultatów wdrożenia MSZ-KIIP oraz sposób wdrożenia systemu... 54 3.1 Zamówienie nr 1: Opracowanie i wdrożenie systemu MSZ-KIIP, wraz z dostawą infrastruktury sprzętowej oraz przeprowadzeniem migracji danych... 56 3.1.1 Etap I - Przygotowanie i wdrożenie organizacji Projektu... 58 3.1.2 Etap II - Opracowanie Dokumentacji Technicznej Implementacji Systemu (DTIS)... 59 3.1.3 Etap III Dostawa, instalacja i konfiguracja infrastruktury sprzętowej i oprogramowania 59 3.1.4 Etap IV Opracowanie, implementacja Systemu... 60 3.1.5 Etap V Przeprowadzenie migracji danych... 60 3.1.6 Etap VI Wdrożenie pilotowe (rozwiązania wewnętrzne)... 61 3.1.7 Etap VII Wdrożenie Systemu w pełnej skali... 62 3.2 Zamówienie nr 2: Świadczenie usług promocji... 63 3.3 Zamówienie nr 3: Świadczenie usług Doradcy Technologicznego... 65 3.4 Rekomendacja dotyczące wyboru trybu udzielenia zamówienia... 65 3.4.1 Wybór trybu udzielenia zamówienia... 65 3.4.1.1 Zamówienie nr 1 przetarg ograniczony... 65 3.4.1.2 Zamówienie nr 2 przetarg nieograniczony... 68 3.4.1.3 Zamówienie nr 3 zapytanie ofertowe zgodnie z wymaganiami IZ RPO WSL... 68 3.4.2 Komentarz ogólny dotyczący określenia warunków udziału w postępowaniu... 69 3.5 Osiągniecie wskaźników produktów... 71 3.5.1 MSZ-KIIP Wskaźniki produktów... 72 Strona 3 z 185

3.5.2 MSZ-KIIP Wskaźniki rezultatu... 75 3.5.3 MSZ-KIIP Wskaźniki produktu dot. szkoleń (cross-financing)... 78 3.6 Ogólny harmonogram realizacji Harmonogram Prac... 79 4 Wnioski... 86 5 Dodatek nr 1 Dyskusja nt. umiejscowienia MSZ-KIIP w Infrastrukturze Informacji Przestrzennej (IIP) 87 5.1 Wprowadzenie... 87 5.1.1 Dokumenty normatywne... 87 5.2 Uwarunkowania prawne... 88 5.2.1 Dyrektywa INSPIRE... 88 5.2.2 Ustawa o Infrastrukturze Informacji Przestrzennej... 89 5.3 Interoperacyjność zbiorów danych i usług danych przestrzennych... 91 5.4 Krajowa Infrastruktura Informacji Przestrzennej... 92 5.4.1 Zarys koncepcji IIP... 92 5.4.2 Ogólny diagram architektury IIP... 93 5.5 Metadane w KIIP... 97 5.6 Dane przestrzenne... 98 5.6.1 Struktura danych przestrzennych... 98 5.6.2 Charakterystyka metadanych... 101 5.6.3 Cel tworzenia... 101 5.6.4 Standardy metadanych... 101 5.6.4.1 ISO 19115... 101 5.6.4.2 ISO/TS 19139... 102 5.6.4.3 ISO 19119... 102 5.6.5 Profil metadanych... 103 5.6.5.1 Profil INSPIRE... 103 5.6.5.2 Profil i wytyczne krajowe... 103 5.6.5.3 Portal katalogowy... 104 5.7 Usługi danych przestrzennych... 105 5.7.1 Charakterystyka usług... 105 Strona 4 z 185

5.7.2 Usługi sieciowe OGC... 106 5.7.2.1 Usługa WMS... 106 5.7.2.2 Usługa WFS... 107 5.7.3 Usługa WCS... 107 5.7.4 Usługa WPS... 107 5.7.5 Usługa CSW... 108 5.7.6 Usługi danych przestrzennych INSPIRE... 108 5.7.7 Usługa wyszukania INSPIRE Discovery Service... 109 5.7.8 Usługa przeglądania INSPIRE View Service... 109 5.7.9 Usługa pobierania INSPIRE Dowload Service... 110 5.7.10 Usługa przekształcania INSPIRE Transformation Service... 110 5.7.11 Usługa uruchamiania INSPIRE Transformation Service... 110 5.8 Wnioski i rekomendacje... 111 5.9 Minimalny zestaw elementów metadanych dla zbiorów, serii oraz usług... 111 5.10 Pojęcia i definicje, skróty, bibliografia... 121 5.10.1 Pojęcia i definicje... 121 5.10.2 Używane skróty... 123 5.10.3 Bibliografia... 124 6 Dodatek nr 2 przetwarzanie danych osobowych, informacje związane ze zgłoszeniem rejestracją baz danych MSZ-KIIP Generalnemu Inspektorowi Ochrony Danych Osobowych (GIODO)126 7 Dodatek nr 3 Istotne uwarunkowania wynikające z Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności... 129 7.1 Omówienie przedmiotu regulacji... 129 7.2 Rekomendacje dotyczące zastosowania w MSZ-KIIP... 134 8 Dodatek nr 4 Opis aktualnej infrastruktury teleinformatycznej Zamawiającego oraz infrastruktury aplikacyjnej... 136 8.1 Infrastruktura techniczna... 136 8.2 Rozwiązania aplikacyjne... 138 8.2.1 Systemy (rozwiązania) dedykowane... 138 8.2.2 Pakiety oprogramowania narzędziowego GIS... 145 Strona 5 z 185

9 Dodatek nr 5 Wymagania dotyczące kluczowych produktów i usług w zakresie zamówienia nr 1: Wykonawca MSZ-KIIP... 146 9.1 Definicje oraz pojęcia stosowane w opisie wymagań... 146 9.2 Wymagania dotyczące praw do utworów oraz oprogramowania... 148 9.2.1 Udzielenie licencji na użytkowanie Systemu... 149 9.2.2 Udzielenie licencji na dokumentację oraz sposób jej przekazania... 150 9.3 Wymagania dotyczące dokumentacji... 151 9.3.1 Dokumentacja zarządcza... 151 9.3.2 Dokumentacja techniczna... 152 9.3.3 Dokumentacja użytkownika... 153 9.4 Dostawa sprzętu komputerowego... 154 9.5 Instalacja i konfiguracja oprogramowania... 155 9.6 Szkolenia... 156 9.7 Warsztaty wymagań... 158 9.8 Migracja danych... 159 9.9 Przeprowadzenie testów Systemu... 160 9.10 Warunki gwarancji oraz warunki świadczenia asysty technicznej na etapie eksploatacji nadzorowanej... 162 9.11 Warunki świadczenia asysty technicznej na etapie eksploatacji nadzorowanej... 162 10 Dodatek nr 6 Wybrane wymagania dotyczące dostawy i konfiguracji infrastruktury sprzętowej oraz systemowej MSZ-KIIP w ramach zamówienia nr 1... 163 10.1 Oprogramowanie... 163 10.1.1 Oprogramowanie bazodanowe... 163 10.1.2 Oprogramowanie do wirtualizacji... 166 10.1.3 Oprogramowanie do publikacji i udostępniania danych przestrzennych (serwer mapowy GIS) 168 10.2 Infrastruktura sprzętowa... 170 10.2.1 Infrastruktura Blade... 170 10.2.2 Zarządzanie infrastrukturą serwerów blade... 171 10.2.3 Serwery sprzętowe blade I typ (serwer bazy danych 1 sztuka)... 171 Strona 6 z 185

10.2.4 Serwery sprzętowe blade II typ (serwery usług 3 sztuki)... 172 10.2.5 Biblioteka taśmowa... 172 10.2.6 Macierz dyskowa... 173 10.2.7 Przełącznik FC... 173 10.2.8 Konsola KVM... 173 10.2.9 Przełącznik KVM... 174 11 Dodatek nr 7 Mapowanie usług aplikacyjnych z modelu EA na logiczne komponenty MSZ-KIIP 175 Strona 7 z 185

1 Metryka dokumentu Wersja Data Zakres opracowania / zmiany 1.0 31.10.2011r Pierwsza wersja dokumentu 1.1 28.11.2011r Uwzględniono istotne uwagi Zamawiającego przekazane w protokole kontroli nr 1 z dnia 16 listopada 2011 roku. 2.0 24.05.2012r Opracowanie dokumentu o innym, nowym układzie treści. Dokument zawiera między wyniki prac projektowych prowadzonych według metod projektowania obiektowego przy użyciu specjalistycznego oprogramowania CASE Enterprise Architect wersja 8.x 3.0 16.07.2012r Wprowadzenie do dokumentu uzupełnień wynikających z uwag Zamawiającego wskazanych w Protokole Kontroli nr 4 z dnia 25 maja 2012 roku odpowiednio, co do zakresu uzgodnień zawartych w projekcie notatki przedstawionej przez Inżynier Projektu ze spotkań z dnia 14 oraz 18 czerwca 2012 roku oraz wyników spotkania z dnia 6 lipca 2012 roku. 4.0 01.08.2012r Wprowadzenie do wersji dokumentu 3.0 z dnia 16 lipca uzupełnień wynikających z uwag Zamawiającego wskazanych w Protokole Kontroli nr 5 z dnia 25 lipca 2012 roku. Zakres wprowadzonych zmian zgodnie z pismem przewodnim Inżyniera Projektu.. 5.0 15.10.2012r Wprowadzenie zmian do wersji dokumentu 4.0 z dnia 1 sierpnia 2012 roku wynikających z uzupełniających uwag Zamawiającego do dokumentu głównego z dnia 5 z dnia 25 lipca 2012 roku. Zakres wprowadzonych zmian zgodnie z pismem przewodnim Inżyniera Projektu.. Lista załączników zewnętrznych do dokumentu głównego: 1. Załącznik nr 1 Wykaz usług i geoportali 2. Załącznik nr 2 Opis procesów 3. Załącznik nr 3 Usługi aplikacyjne, aktorzy 4. Załącznik nr 4 Magazyny danych 5. Załącznik nr 5 Zewnętrzne źródła danych 6. Załącznik nr 6 Katalog wymagań funkcjonalnych 7. Załącznik nr 7 Model przypadków użycia 8. Załącznik nr 8 Specyfikacja modelu danych 9. Załącznik nr 9 Katalog generowanych dokumentów i raportów Strona 8 z 185

UWAGA W związku ze znaczącą wielkością Załączników nr 1-9, generowanych w formie raportów (wydruków) z pakietu Enterprise Architect (EA) dokumenty ten zostają przekazane włącznie w formie elektronicznej na nośniku CD-ROM. Na życzenie Zamawiającego Inżynier Projektu może przygotować wersję wydrukowaną każdego z ww. dokumentów. 1.1 Aspekt formalny Podstawą do opracowania niniejszego dokumentu jest umowa nr 31/G/2011 z dnia 20 lipca 2011 roku zawarta pomiędzy Miastem Katowice a konsorcjum Nizielski & Borys Consulting Infostrategia Krzysztof Heller i Andrzej Szczerba Sp. Jawna. Sp. z o.o. oraz 1.2 Cel dokumentu Celem Projektu technicznego budowy systemu MSZ-KIIP (skrót PTBS) jest potwierdzenie założeń wykonawczych, a także uszczegółowienie koncepcji Miejskiego Systemu Zarządzania Katowicka Infrastruktura Informacji Przestrzennej (MSZ-KIIP) określonych w Projekcie Generalnym Miejski System Zarządzania - Katowicka Infrastruktura Informacji Przestrzennej (MSZ-KIIP) oraz w Studium Wykonalności dla przedmiotowego Projektu. 1.3 Przeznaczenie dokumentu Zgodnie ze Specyfikacją Istotnych Warunków Zamówienia (SIWZ) dla przedmiotowego zamówienia, niniejszy dokument stanowi łącznik pomiędzy systemem MSZ-KIIP a użytkownikami. Wydzielona część dokumentu (po akceptacji Zamawiającego) stanowić może załącznik do specyfikacji istotnych warunków zamówienia dla planowanych zamówień publicznych - zadań projektu MSZ-KIIP. 1.4 Zakres opracowania oraz stan prawny Zakres opracowania niniejszego dokumentu odpowiada wymaganiom zawartym w SIWZ odnoszącym się do opracowania Projektu technicznego budowy systemu MSZ-KIIP, rozumianego jako szczegółowa koncepcja MSZ-KIIP wraz z jego analizą funkcjonalną i zawiera odpowiedź na postawione pytania, tezy zawarte w SIWZ, w tym w szczególności w obszarze zgodności projektowanego systemu z Strona 9 z 185

obowiązującymi przepisami prawa. I tak, odnosząc się odpowiednio do enumeratywnie wskazanych wymagań SIWZ str. 26-29, dokument zawiera w szczególności odpowiedź na wymagania dotyczące: pkt. 1 dokumentacji technicznej wymagań w zakresie procedury gromadzenia danych (przygotowanie danych, migracji, synchronizacji danych, integracji danych, udostępnianie danych), baz danych systemu, aplikacji oraz geoportali., pkt. 2 dokumentacji technicznej wymagań w zakresie architektury systemu z uwzględnieniem zapisów dyrektywy INSPIRE dla wymiany, wspólnego korzystania, dostępu i użytkowania interoperacyjnych danych przestrzennych i usług dotyczących danych przestrzennych na różnych szczeblach organów publicznych i innych (usługi rejestrów, usługi wyszukiwania, usługi przeglądania, usługi pobierania, usługi przekształcania, usługi umożliwiające uruchamianie usług danych przestrzennych). pkt. 3 dokumentacji technicznej wymagań w zakresie funkcjonalności systemu, uwzględniającej podział na: funkcjonalność centralnego węzła - funkcjonalność węzłów dziedzinowych - funkcjonalność aplikacji i geoportali. pkt. 4 dokumentacji technicznej wymagań i rozwiązań technicznych w zakresie telekomunikacji uwzględniającej integrację z siecią teleinformatyczną i innymi systemami w zakresie wzajemnej współpracy, z którymi planowana jest fizyczna wymiana danych (np. poprzez replikację danych) lub też którym zakłada się umożliwienie pobierania wybranych danych do podglądu (poprzez ich własny interfejs) lub zapisu we własnych bazach danych (np. jako dodatkowe atrybuty obiektów), np. SEKAP, e-puap, systemy desktopowe, wewnętrzny obieg dokumentów stosowany w UMK - odpowiedź zawiera niniejszy dokument główny. Należy zaznaczyć, że PTBS nie stanowi i nie może stanowić projektu technicznego sensu stricte, w którym wskazuje się i wykorzystuje do opisu określone, nazwane produkty i technologie. Ograniczenie to wynika z uwarunkowań związanych z zachowaniem zasady neutralności technologicznej będących konsekwencją faktu, iż PTBS stanowi działanie uprzedzające w czasie w stosunku do faktycznych, ostatecznych prac implementacyjnych Wykonawcy systemu, realizowanych zgodnie z jego ofertą produktową. Wystąpienie w PTBS opisów i nazw wskazujących na określony produkt lub technologię ma wyłącznie charakter pomocniczy, informacyjny i wyjaśniający w stosunku do opisu wymagań. Strona 10 z 185

1.5 Metodyka prac projektowych struktura dokumentu Prace projektowe w zakresie modelowania architektury funkcjonalnej systemu oraz modelu danych były prowadzone w oparciu o metodykę projektowania obiektowego oraz wspomagający ten proces projektowy pakiet CASE Enterprise Architect http://www.sparxsystems.com.au/. Tym samym przyjęto, iż dokument Projekt techniczny budowy systemu MSZ-KIIP składać się będzie z niniejszego dokumentu głównego oraz zewnętrznych załączników generowanych z bazy projektu MSZ-KIIP w pakiecie CASE Enterprise Architect. Załączniki te będą zawierać kluczowe elementy modelu systemu wg metodyki obiektowej: listę aktorów, magazyny danych, usługi aplikacyjne, wymagania wobec systemu, diagramy przypadków użycia oraz generowane przez system dokumenty. Lista załączników zewnętrznych została wskazana w metryce dokumentu głównego. Strona 11 z 185

2 Koncepcja MSZ-KIIP 2.1 Ogólne założenia Zaprezentowana poniżej koncepcja Miejskiego Systemu Zarządzania Katowicka Infrastruktura Informacji Przestrzennej (MSZ-KIIP) jest zgodna z koncepcją MSZ-KIIP zawartą w Projekcie Generalnym MSZ-KIIP. Koncepcja ta jest odpowiedzią na zasadnicze uwarunkowania oraz potrzeby Zamawiającego: 1. ograniczone wsparcie dla wewnętrznych procedur administracyjnych w zakresie procesów decyzyjnych i planistycznych w obszarze gospodarki przestrzennej oraz zagadnień związanych z informacją przestrzenną, 2. niezbyt szeroki wachlarz dostępnych usług publicznych w zakresie informacji przestrzennej dla mieszkańców miasta i regionu oraz Klientów administracji samorządowej miasta Katowice, 3. nierozwiązane (w całości) zagadnienie wypełnienia ustawowego obowiązku wynikającego z Ustawy o infrastrukturze informacji przestrzennej. Zgodnie z przyjętymi założeniami System MSZ-KIIP stanowić będzie: a) węzeł lokalny Infrastruktury Informacji Przestrzennej wchodzący w skład krajowej IIP, co jest zgodne z wnioskami z przeprowadzonej dyskusji nt. zakresu oraz sposobu implementacji Ustawy o infrastrukturze informacji przestrzennej dla miasta Katowice (Rozdz. 4 Dodatek nr 1 Dyskusja nt umiejscowienia MSZ-KIIP w Infrastrukturze Informacji Przestrzennej (IIP)), b) wydzieloną tematyczną część Systemu Informacyjnego Urzędu Miasta Katowice (UMK) dedykowaną do obsługi zagadnień związanych z informacją przestrzenną, Strona 12 z 185 w tym część Systemu EZD określonego przepisami Rozporządzenia Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz. U z dnia 11 stycznia 2011 roku nr 14 poz. 67). Technicznym zadaniem MSZ-KIIP będzie gromadzenie, przetwarzanie i udostępnianie informacji przestrzennej dla wszystkich uprawnionych do tego użytkowników systemu. Celem właściwej kategoryzacji dostępu do danych oraz funkcji systemu wyróżnione zostaną dwie zasadnicze grupy użytkowników, tj.:

użytkownicy wewnętrzni - pracownicy urzędu, pracownicy jednostek organizacyjnych Miasta oraz opcjonalnie inne uprawnione podmioty, jednostki organizacyjne i osoby fizyczne, którym zapewniono dostęp do pełnego zakresu funkcji oraz danych Systemu; użytkownicy zewnętrzni - użytkownicy systemu spoza pierwszej grupy użytkowników wewnętrznych, czyli osoby prawne (instytucje i podmioty gospodarcze) i osoby fizyczne, a w szczególności mieszkańcy miasta posiadający dostęp powszechny, ale ograniczony tylko do zakresu danych i funkcji uznanych jako treść publiczna. Każda z ww. grup będzie posiadała odpowiednią hierarchię uprawnień, która będzie przekładać się na perspektywę udostępnionych im danych oraz funkcji. Podstawą do budowy systemu będą dane georeferencyjne państwowego zasobu geodezyjnego i kartograficznego (PZGiK) prowadzone przez Ośrodek Dokumentacji Geodezyjnej i Kartograficznej (ODGiK) w strukturach Wydziału Geodezji Urzędu Miasta Katowice tj. dane ewidencji gruntów i budynków, numeryczne dane o treści mapy zasadniczej (docelowo po zmianie przepisów dane BDOT500, tj. dane bazy danych obiektów topograficznych klasy 500), dane sieci uzbrojenia terenu oraz dane adresowe ewidencji miejscowości ulic i adresów. Bez względu na typ i zakres udostępnionych i załadowanych do MSZ-KIIP danych PZGiK, dane te stanowić będą wyłącznie dane referencyjne, a zatem będą gromadzone w formie niezmiennych co do wartości atrybutów warstw referencyjnych, umożliwiając budowanie relacji dla obiektów pozostałych warstw informacyjnych systemu z zakresu: planowania przestrzennego, istotnych zdarzeń, np. z zakresu bezpieczeństwa publicznego i zarządzania kryzysowego, zarządzania mieniem komunalnym, ochrony środowiska i przyrody, ochrony zabytków oraz dóbr kultury, ofert inwestycyjnych, wniosków, decyzji i postanowień z procesów administracyjnych oraz innych warstw informacyjnych systemu powstających w odpowiedzi na potrzeby i wymagania użytkowników systemu. Dane z baz danych PZGiK będą udostępniane przez Służbę Geodezyjną i Kartograficzną (SGK) zgodnie z obowiązującymi w tym zakresie regulacjami prawnymi, technicznymi oraz finansowymi na podstawie stosownej umowy. Tytuł prawny do udostępniania danych PZGiK nadaje delegacja prawna wskazana przez Ustawę o informatyzacji działalności podmiotów realizujących zadania publiczne art. 15 oraz Strona 13 z 185

Rozporządzenie Rady Ministrów w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym z dnia 27 września 2005r. Dz. U. Nr 205, Poz. 1692 oraz Ustawa o infrastrukturze informacji przestrzennej. Częstotliwość udostępniania danych z baz danych PZGiK będzie zależna od warunków prawnych, organizacyjnych i technicznych zawartych w umowie na ich udostępnianie na rzecz Miasta Katowice, przy czym zakłada się, iż nie będzie to następować rzadziej niż w cyklu aktualizacji i zasilania dziennego. Oczekiwaną, z punktu widzenia celów budowy systemu, metodą zasilania MSZ-KIIP, będzie stały, ciągły dostęp do danych, jednak sprawność takiego rozwiązania musi być zweryfikowana od strony praktycznej na etapie implementacji sytemu. Dane PZGiK zawarte w bazie danych MSZ-KIIP nie będą posiadały statusu danych geodezyjnych baz danych PZGiK, a tym samym pomimo pełnego pokrycia informacyjnego z danymi z baz danych PZGiK, MSZ-KIIP nie będzie udostępniał produktów informacyjnych będących w zakresie kompetencji systemów służących do prowadzenia baz danych PZGiK, jak np. wypis i wyrys z ewidencji gruntów. W każdym przypadku, kiedy tego typu tożsamy produkt informacyjny będzie dostępny po stronie MSZ-KIIP, przypisany zostanie mu zawsze status dokumentu informacyjnego, który będzie identyfikowany przez znak wodny MSZ-KIIP wyłącznie do celów informacyjnych. Dokument taki nie będzie dokumentem urzędowym i nie będzie zawierał również stosownych dla tego rodzaju dokumentów klauzul. Dane z baz danych PZGiK nie będą podlegały bezpośredniemu udostępnianiu w postaci pierwotnej jakimkolwiek innym osobom prawnym i fizycznym, w tym również podmiotom zależnym lub współpracującym z Miastem (potencjalny zakres udostępnienia może dotyczyć wyłącznie jednostek organizacyjnych Miasta po zweryfikowaniu aktualnych w tym zakresie uwarunkowań prawnych). MSZ-KIIP będzie integrował dane z innych baz danych i rejestrów publicznych takich jak np.: ewidencja ludności (system firmy Technika Gliwice spółka z o.o.), rejestr ewidencji działalności gospodarczej (CEIDG), ewidencja mienia komunalnego oraz rejestry finansowo księgowe, w tym podatki i opłaty. Ze względu na uwarunkowania prawne oraz wymogi bezpieczeństwa dotyczące przetwarzania tego typu danych, dostęp do tych danych nie będzie oznaczać bezpośredniego, fizycznego dostępu do określonej bazy danych lub rejestru, lecz będzie to dostęp (podobnie jak w zakresie danych PZGIK) do wydzielonej Strona 14 z 185

kopii danych w formie aktualizowanego widoku danych lub dostępnej usługi sieciowej (Web service w architekturze SOA). Celem realizowania elektronicznych usług publicznych MSZ-KIIP kategorii 4-tej oraz wsparcia procedur administracyjnych MSZ-KIIP zostanie zintegrowany z systemem EOD (FINN / SEKAP) oraz w koniecznym zakresie z platformą usług publicznych SEKAP i epuap. MSZ-KIIP składać się będzie z oprogramowania: 1. systemowego, w tym oprogramowania do wirtualizacji zasobów, 2. narzędziowego, takiego jak: serwery bazodanowe, serwery mapowe, serwery proxy, serwery Web, 3. standardowego oprogramowania GIS bazującego na licencjach oprogramowania GIS klasy Desktop GIS i przeznaczonego dla zaawansowanych użytkowników oraz specjalistów ds. GIS dla zadań związanych z obsługą złożonej geometrii danych przestrzennych, realizowaniem złożonych prac kartograficzno analitycznych, czy też wspomagania zadań wymagających bardziej zaawansowanych funkcji i analiz przestrzennych, np. w zakresie zarządzania kryzysowego (generowanie stref zalewowych) oraz planowania przestrzennego (zagadnienia standaryzacji zapisu i prezentacji planu), 4. aplikacyjnego w zakresie wskazanym w architekturze logicznej MSZ-KIIP, co w szczególności obejmuje: usługi katalogowe oraz usługi OGC wynikające z rekomendowanej architektury usług INSPIRE, moduły 1 tematyczne w architekturze tzw. cienkiego klienta stanowiące dedykowane serwisy intranetowego portalu mapowego, umożliwiające prezentację oraz prostą, niezłożoną edycję danych oraz prowadzenie zestandaryzowanych analiz oraz funkcji raportowania (drukowania, publikowania zestawień, raportów), dedykowane moduły w architekturze klient - serwer dla obsługi złożonych zagadnień związanych z bardziej zaawansowanym przetwarzaniem danych, 1 Inaczej aplikacje w dalszej części opracowania wymiennie stosuje się sformułowanie moduł i aplikacja Strona 15 z 185

dedykowane komponenty do integracji wewnętrznej i zewnętrznej systemu, czyli tzw. usługi aplikacyjne integracji oraz wymiany danych z funkcjonującymi w UMK systemami informatycznymi: RATUSZ, Elektroniczny Obieg Dokumentów(EOD). Zakres informacyjny MSZ-KIIP stanowić będą dane z warstw tematycznych systemu prowadzone przez moduły dziedzinowe oraz dane referencyjne, w tym dane PZGiK oraz inne źródłowe dane udostępnione na potrzeby funkcjonowania systemu (np. ortofotomapa, dane ze skaningu laserowego opracowane na potrzeby wdrożenia projektu ISOK). Aktualizacja danych z warstw tematycznych będzie możliwa wyłącznie przez przeznaczony do tego celu komponent systemu i użytkownika o określonych uprawnieniach, co zapewni przejrzystość podziału kompetencji oraz odpowiedzialności za dane. Proste warstwy tematyczne systemu będą prowadzone przez dedykowane moduły tematyczne MSZ- KIIP zapewniające co najmniej funkcje: tworzenia, przeglądania, aktualizacji, usuwania określonych danych (czyli funkcje tzw. macierzy CRUD ang. Create, Read, Update, Delete) oraz wyszukiwania i raportowania w formie dedykowanych wydruków (raportów) oraz kompozycji mapowej. Warstwy referencyjne (inaczej georeferencyjne) będą pozyskiwane ze źródeł zewnętrznych i nie będą podlegać edycji w systemie MSZ-KIIP. Dla wszystkich kluczowych danych systemu, dla których wprowadzony zostanie atrybut cykl życia, zapewniona zostanie obsługa historii zmian, umożliwiająca co najmniej przegląd danych historycznych, a dla wyróżnionych warstw systemu, jak np. ewidencja gruntów i budynków zaprezentowanie stanu na określony dzień. Dla każdej warstwy danych MSZ-KIIP będą zakładane i prowadzone metadane. Zakres metadanych określi profil metadanych opracowany przez Wykonawcę systemu, zgodny z obowiązującymi przepisami prawa, w tym wytycznymi resortowymi oraz zaleceniami organów odpowiedzialnych za wdrożenie krajowej Infrastruktury Informacji Przestrzennej (IIP). Strona 16 z 185

MSZ-KIIP będzie posiadał architekturę wielowarstwową (trójwarstwową) bazującą w warstwie prezentacji na zastosowaniu standardowych internetowych przeglądarek danych: Internet Explorer, Firefox, Opera, Chrome. Celem zapewnienia kryteriów bezpieczeństwa i wieloplatformowości, MSZ-KIIP będzie bazował na rozwiązaniach opartych o aplety języka JAVA osadzone na stronach WWW, dynamiczny HTML oparty o JavaScript lub inne rozwiązania równoważne. Szczegółowy model funkcjonalny MSZ-KIIP przedstawiono w zewnętrznych załącznikach do niniejszego dokumentu: Załącznik nr 1 Usługi aplikacyjne, aktorzy, Załącznik nr 3 Katalog wymagań funkcjonalnych, Załącznik nr 4 Model przypadków użycia, Załącznik nr 7 Katalog generowanych dokumentów i raportów. Strona 17 z 185

Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 18 z 185

Rysunek 1 Model pojęciowy MSZ-KIIP - otoczenie systemu (czerwona linia zakres systemu) Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 19 z 185

2.1.1 Dane georeferencyjne - dane z baz danych PZGiK Zasilanie MZS KIIP danymi z baz danych PZGiK następować będzie przy wykorzystaniu jednej z poniższych metod: przez dostęp do prowadzenia ustanowionych przez dostawcę systemu baz danych PZGiK, widoków bazy danych lub dostęp do danych poprzez usługi aplikacyjne usługi sieciowe. Z uwagi na złożoność oraz mnogość danych, w tym konieczność dostępu do danych historycznych oraz do danych prezentujących zmiany wartości atrybutów danego obiektu, proponowane jest rozwiązanie bazujące na dostępie do danych poprzez wydzielony widok bazy danych Oracle. Usługi sieciowe, pomimo ich interoperacyjności, mogą okazać się niewydajne do sprawnego zasilania MSZ-KIIP. Dla danych: mapy zasadniczej - widoki powinny być ustanowione dla tematycznych grup danych w układzie klasyfikacyjnym odpowiadającym treści mapy zasadniczej, ewidencji gruntów, budynków i lokali - widok powinien odpowiadać zdefiniowanej w instrukcji G5 strukturze pliku SWDE ewidencji miejscowości ulic i adresów zgodnie z obowiązującym zakresem informacyjnym rozporządzenia w sprawie EMUiA Dane przestrzenne powinny być udostępniane w formacie danych przestrzennych OGC WKT lub opcjonalnie w formacie WKB lub Oracle Spatial. Dla każdej z grup danych widoki baz danych powinny zawierać również dedykowany widok do rejestru zmian, umożliwiający w ten sposób wprowadzenie adekwatnej zmiany w bazie danych MSZ-KIIP. Zmiany do bazy danych MSZ-KIIP będą wprowadzane w cyklu jednodniowym po godzinach pracy urzędu. Przyjmuje się, że dla danych ewidencji gruntów i budynków wydzielona zostanie usługa jednokrotnego zasilania systemu danymi historii zmian sprzed daty uruchomienia systemu. Po tej operacji nastąpi włączenie usług aktualizacji bazy danych systemu węzła centralnego danymi PZGiK. 2.1.2 Gromadzenie danych Dane MSZ-KIIP będą przechowywane w dwóch bazach danych (dwóch instancjach). Główna tzw. wewnętrzna baza danych zawierać będzie dane georeferencyjne oraz dane tematyczne. Baza ta zostanie ustanowiona w tzw. centralnym węźle KIIP. Dane z tej bazy będą replikowane do drugiej bazy danych MSZ-KIIP zewnętrznej przeznaczonej do obsługi usług publicznych. Strona 20 z 185

Wszystkie zestawy danych, dla których konieczne będzie przechowywanie historii zmian, będą posiadać w modelu danych atrybut cykl życia definiujący okres obowiązywania danego zestawu danych. 2.1.3 Metadane MSZ-KIIP zapewni obsługę metadanych przez udostępnienie aplikacji do edycji metadanych oraz ich publikowania zgodnie z obowiązującymi w tym zakresie wymaganiami wynikającymi z Ustawy o infrastrukturze informacji przestrzennej. Projektowane usługi zapewnią możliwość automatycznej aktualizacji metadanych w zakresie atrybutów, które są lub mogą być wynikiem przetwarzania danych przez aplikację MSZ-KIIP lub standardowe narzędzia GIS, np. zakres przestrzenny. Usługa katalogu metadanych wydzieli w tym celu określony interfejs do aktualizacji metadanych. 2.1.4 Integracja danych adresowych mapowanie danych Zgodnie z przyjętymi założeniami prowadzenie rejestru ewidencji miejscowości ulic adresów (EMUiA) jest poza zakresem funkcjonowania systemu MSZ-KIIP. Dane z rejestru EMUiA podlegać będą replikowaniu wg ustalonych metod zasilania. Na potrzeby utrzymania przez MSZ-KIIP spójnego systemu adresowego dla kluczowej warstwy danych, jaką są punkty adresowe, wdrożona zostanie usługa mapowania danych adresowych z innych źródłowych danych będących poza zakresem systemu. Usługa ta zawierać będzie mechanizmy aliasowania (oraz geokodowania) zapewniające przypisanie lokalizacji przestrzennej źródłowego punktu adresowego do referencyjnego obiektu reprezentującego punkt adresowy w systemie MSZ-KIIP. Uwaga: dla zapewnienia większej spójności rozwiązania oraz integracji danych zalecane jest rozważenie przeniesienia obsługi danych adresowych (EMUiA) do MSZ-KIIP. 2.1.5 Implementacja e-usług oraz integracja z EOD MSZ-KIIP wspierać będzie procesy decyzyjne oraz planistyczne, w tym w szczególności procesy związane z obsługą elektronicznych usług publicznych (e-usług) w zakresie zagadnień odnoszących się do zarządzania przestrzenią. Usługi te będą inicjowane przy wykorzystaniu platformy usług publicznych SEKAP oraz epuap. Dla każdej e-usługi w MSZ-KIIP zostanie opracowany formularz wniosku oraz dedykowane funkcje (widżety) wspomagające proces jego wypełnienia lub dołączenia do wniosku załącznika np. w formie szkicu kompozycji mapowej wygenerowanej w MSZ-KIIP. Strona 21 z 185

Opcjonalnie obsługa e-usług może być prowadzona przy wykorzystaniu platformy SEKAP lub epuap, gdzie formularz takiej usługi zostanie umieszczony, a MSZ-KIIP zajmować będzie się wyłącznie wspieraniem procesu - jego wypełnieniem poprzez dedykowane komponenty, widżety dostarczając takie dane jak np. numer działki ewidencyjnej, oznaczenie przeznaczenia terenu w MPZP, inne. W celu implementacji e-usług MSZ-KIIP zapewni integrację z Systemem Elektronicznego Obiegu Dokumentów EOD (firmy FINN / LTC) oraz z platformą usług publicznych SEKAP oraz epuap. W przypadku EOD integracja ta będzie polegać na przejmowaniu danych z wniosku dla danej usługi oraz przekazywaniu zwrotnie do EOD wygenerowanego dokumentu lub raportu stanowiącego rezultat działania MSZ-KIIP. Dla platform SEKAP / epuap integracja z MSZ-KIIP odnosić się będzie do implementacji mechanizmu autoryzacji użytkownika wypełniającego i podpisującego wniosek, w tym dla SEKAP u w zakresie podpisu niekwalifikowanego, a dla epuap - profilu zaufanego. Zaimplementowane w ten sposób rozwiązanie stanowić będzie rozszerzenie zakresu funkcjonalnego Systemu EZD zapewniając możliwość pełnej, elektronicznej obsługi wydzielonej kategorii spraw dla zdefiniowanych e- usług. Poniżej podano wstępną lista usług 4 kategorii do potwierdzenia do realizacji i uruchomienia na etapie implementacji MSZ KIIP: 1. Przeniesienie decyzji o warunkach zabudowy na innego inwestora 2. Ustalenie wysokości jednorazowej opłaty z tytułu wzrostu wartości nieruchomości w związku z uchwaleniem miejscowego planu zagospodarowania przestrzennego przed zbyciem nieruchomości 3. Przyjęcie informacji o wytwarzanych odpadach oraz o sposobach gospodarowania wytworzonymi odpadami od wytwórcy odpadów, jeżeli wytwarza odpady niebezpieczne w ilości do 0,1 Mg rocznie albo powyżej 5 Mg rocznie odpadów innych niż niebezpieczne 4. Wydawanie zezwoleń na prowadzenie odzysku lub unieszkodliwianie odpadów 5. Wydawaniem zezwoleń na usunięcie drzew i krzewów 6. Stwierdzenie wygaśnięcia pozwolenia wodno prawnego 7. Przeniesienie praw i obowiązków wynikających z pozwolenia wodnoprawnego 8. Wydawanie decyzji o zajęcie pasa drogowego 9. Wydawane decyzji o lokalizacji reklam w pasie drogowym 10. Wydanie wypis i wyrysu z mpzp 11. Wydanie wypis i wyrysu ze studium 12. Wydanie decyzji o pozwoleniu na rozbiórkę Strona 22 z 185

13. Udostępnianie informacji o środowisku i jego ochronie 14. Złożenie wniosku o sporządzenie lub zmianę miejscowego planu zagospodarowania przestrzennego lub zmianę studium uwarunkowań i kierunków zagospodarowania przestrzennego gminy (miasta) 15. Wydanie opinii o przeznaczeniu terenu w miejscowym planie zagospodarowania przestrzennego lub kierunkach zagospodarowania w studium uwarunkowań i kierunków zagospodarowania przestrzennego 16. Wydawanie decyzji o środowiskowych uwarunkowaniach (opcja). Poniżej przykładowy przebieg obsługi e-usługi dla procesu wydania wypisu lub wyrysu z miejscowego planu zagospodarowania przestrzennego (MPZP), przypadek użycia przedstawiony jest poniżej w formie tekstowego opisu procesu, dla którego spełnione są warunki brzegowe tj. zdefiniowany formularz w MSZ-KIIP o określonej strukturze dokumentu XML, dla którego zdefiniowano również dokumenty XSD oraz XSLT zapewniające walidację dokumentu oraz jego poprawną prezentację jako szablonu graficznego: 1. użytkownik wybiera w ramach MSZ-KIIP Portal Obsługi Obywatela, 2. w ramach listy dostępnych usług elektronicznych wybiera e-usługę, 3. system żąda autoryzacji użytkownika w oparciu o wybrany przez niego profil autoryzacji SEKAP lub epuap, 4. po poprawnej autoryzacji użytkownik wypełnia wniosek dla wybranej e-usługi, 5. zależnie od charakteru i treści wniosku MSZ-KIIP udostępnia funkcje kontroli składniowej i semantycznej, w tym funkcje wspomagania dostarczające dane słownikowe lub dane wygenerowane podczas pracy systemu w formacie PDF, PNG, 6. po poprawnej walidacji wniosku MSZ-KIIP wniosek zostaje podpisany w ramach procedury autoryzacji danej platformy epuap lub SEKAP, 7. treść wniosku jako wygenerowany dokument w formacie XML jest skierowana do Elektronicznej Skrzynki Podawczej (ESP) Urzędu Miasta Katowice, która wystawia Urzędowe Poświadczenie Odbioru (UPO) dla klienta usługi, 8. wniosek jako dokument XML trafia do systemu EOD, 9. po zadekretowaniu do określonej kategorii spraw wniosek trafia na stanowisko merytoryczne, 10. pracownik wybiera obsługę danej sprawy w MSZ-KIIP, Strona 23 z 185

11. następuje pobranie danych z wniosku a następnie metadane wniosku oraz opcjonalnie złączniki w formie odwzorowania cyfrowego przekazywane są do modułu dziedzinowego MSZ-KIIP (obsługa ta jest możliwa dzięki integracji pomiędzy EOD a MSZ-KIIP), 12. wykonywane są czynności związane z obsługą sprawy a w określonym module następuje wygenerowanie dokumentu lub raportu np. z treścią wypisu, wyrysu z MPZP do formatu PDF, 13. po zakończeniu obsługi moduł dziedzinowy przekazuje dane do EOD potwierdzając poprawność wykonanej obsługi, co umożliwi EOD zasygnalizowanie możliwości zmiany statusu dla sprawy, 14. w EOD opcjonalnie może nastąpić podpisanie dokumentu podpisem elektronicznym, 15. zgodnie z dyspozycją Klienta (zgodnie z KPA) wskazaną na wniosku do sprawy, może nastąpić przekazanie elektronicznego dokumentu do Klienta (o ile wyraził taką wolę) lub przekazanie informacji o gotowości dostępności dokumentu do odbioru w Biurze Obsługi Klienta lub zgodnie z życzeniem Klienta wysłanie dokumentu pocztą. W ten sposób cały proces wydania wypisu lub wyrysu z MPZP od formularza po przekazanie dokumentu do Klienta może być wspierany i automatyzowany przez MSZ-KIIP przy współpracy z SEKAP, epuap oraz EOD. Do rozstrzygnięcia pozostaje kwestia implementacji obsługi technicznej oraz organizacyjno prawnej płatności urzędowej związanej z realizacją danej sprawy. 2.2 Architektura systemu 2.2.1 Architektura logiczna Z punktu widzenia zakresu przedmiotowego dostarczanej funkcjonalności Systemu MSZ-KIIP, system ten podzielono zgodnie z przyjętym w Projekcie Generalnym modelem logicznym na: aplikacje, portale oraz geoportale (inaczej zewnętrzne portale mapowe). Zgodnie z powyższym tzw. wewnętrzną część infrastruktury aplikacyjnej systemu stanowią: 1. Aplikacje dziedzinowe: Udostępnienie i obsługa geodezyjnych referencyjnych baz danych, Zarządzanie kryzysowe i bezpieczeństwo, infrastruktura krytyczna, Monitoring i planowanie przestrzenne, rewitalizacja i inwestycje, Zarządzanie i ochrona środowiska, Zarządzanie nieruchomościami, Strona 24 z 185

Natomiast infrastrukturę zewnętrzną MSZ-KIIP tworzą: 1. Portal Obsługi Obywatela, 2. Geoportal Inwestycji, 3. Geoportal sportu, promocji i turystyki, 4. Geoportal edukacyjny, 5. Geoportal metadanych. Powyższe aplikacje, portale i geoportale w trakcie prac analitycznych zostały za mapowane przez zidentyfikowane i zaprojektowane usługi aplikacyjne. Przypisanie poszczególnych usług aplikacyjnych do logicznego podziału MSZ KIIP zawarto w Rozdziale 11 Dodatek nr 7 Mapowanie usług aplikacyjnych z modelu EA na logiczne komponenty MSZ-KIIP. Z uwagi na fakt, iż MSZ-KIIP stanowić będzie tzw. węzeł lokalny Infrastruktury Informacji Przestrzennej (IIP) zrezygnowano z logicznych pojęć węzła centralnego przypisywanych w szczególności dla zakresu funkcji systemowych oraz pojęcia węzłów lokalnych dla poszczególnych geoportali. 2.2.2 Uwarunkowania prawne mające wpływ na architekturę oraz funkcjonalność systemu Poza przepisami prawa odnoszącymi się do zakresu dziedzinowego, który wspomagać będzie projektowany system informatyczny MSZ-KIIP a odnoszącymi się do ustawowych, statutowych obowiązków Zamawiającego, w tym tzw. praktyk służbowych obowiązujących w strukturach organizacyjnych Zamawiającego, MSZ-KIIP spełniać musi wymagania niefunkcjonalne oraz funkcjonalne wynikające z przepisów prawa odnoszących się do systemów teleinformatycznych wykorzystywanych przez podmioty realizujące zadania publiczne celem świadczenia usług publicznych drogą elektroniczną oraz przepisów prawa wynikających z uwarunkowań wdrożenia Dyrektywy INSPIRE, co obejmuje w szczególności takie przepisy jak: 1. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. Nr 64, poz. 565 z późn. zm.); 2. Ustawa z dnia 12 lutego 2010 roku o zmianie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne, oraz niektórych innych ustaw (Dz. U Nr 40 Poz. 230), Strona 25 z 185

Rozporządzenie 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) Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. Nr 206, poz. 1216); Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zasad potwierdzania, przedłużania ważności, wykorzystania i unieważniania profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz. U. Nr 93, poz. 547), Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zakresu warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz. U. Nr 93, poz. 546), Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 21 kwietnia 2011 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do identyfikacji użytkowników (Dz. U. Nr 93, poz. 545), Rozporządzenie Ministra Spraw Wewnętrznych I Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. Nr 206, poz. 1518); Rozporządzenie Ministra Spraw Wewnętrznych I Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz.U. Nr 206, poz. 1519); Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U. Nr 217, poz. 1836); Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz. U. Nr 205, poz. 1692), Strona 26 z 185

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. Nr 206, poz. 1517), Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. Nr 206, poz. 1518); Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. Nr 206, poz. 1519); 3. Ustawa z dnia 4 marca 2010 r. o Infrastrukturze Informacji Przestrzennej (Dz.U. 2010 nr 76, poz. 489) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 20 października 2010 r. w sprawie ewidencji zbiorów i usług danych przestrzennych objętych infrastrukturą informacji przestrzennej (Dz.U. 2010 nr 201 poz. 1333) Obowiązujące przepisy wspólnotowe dotyczące INSPIRE oraz inne dokumenty stanowiące wynik prac nad INSPIRE i dotyczące wymienionych niżej kierunków prac objętych ramowym programem: 4. Dyrektywa 2007/2/WE Parlamentu Europejskiego i Rady z dnia 14 marca 2007 r. ustanawiająca infrastrukturę informacji przestrzennej we Wspólnocie Europejskiej (INSPIRE) (Dz.U. L 108 z 25.4.2007, str. 1 14); 5. Decyzja Komisji 2009/442/WE z dnia 5 czerwca 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie monitorowania i sprawozdawczości (notyfikowana, jako dokument nr C(2009) 4199 (Dz.U. L 148 z 11.6.2009, str. 18 26) w zakresie identyfikacji zbiorów i usług danych przestrzennych; 6. Rozporządzenie Komisji (UE) nr 268/2010 z dnia 29 marca 2010 r. wykonujące dyrektywę 2007/2/WE Parlamentu Europejskiego i Rady w odniesieniu do dostępu instytucji i organów Wspólnoty do zbiorów i usług danych przestrzennych państw członkowskich zgodnie ze zharmonizowanymi warunkami (Dz.U. L 83 z 30.3.2010, str. 8 9); Strona 27 z 185

7. Rozporządzenie Komisji (WE) NR 976/2009 z dnia 19 października 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie usług sieciowych (Dz.U.UE L z dnia 20 października 2009 r.); 8. Rozporządzenie Komisji (WE) Nr 1205/2008 z dnia 3 grudnia 2008 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie metadanych (Dz.U. L 326 z 4.12.2008, str. 12 30); 9. Wytyczne INSPIRE: INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Version 1.2) 16.06.2010; INSPIRE Data Specifications on Addresses Guidelines v 3.0.1 03.05.2010; INSPIRE Data Specification on Protected Sites Guidelines v 3.1.0 03.05.2010; INSPIRE Data Specification on Administrative Units Guidelines v3.0.1 03.05.2010; INSPIRE Data Specification on Cadastral Parcels Guidelines v 3.0.1 03.05.2010; INSPIRE Specification on Geographical Grid Systems Guidelines v 3.0.1 03.05.2010; INSPIRE Data Specification on Hydrography Guidelines v 3.0.1 03.05.2010 INSPIRE Data Specification on Transport Networks Guidelines v 3.1 03.05.2010; INSPIRE Specification on Coordinate Reference Systems Guidelines v 3.1 03.05.2010; INSPIRE Data Specification on Geographical Names Guidelines v 3.0.1 03.05.2010; Draft Technical Guidance for INSPIRE Schema Transformation Service (version 2.0) 11.06.2010; Draft Technical Guidance for INSPIRE Coordinate Transformation Services 15.03.2010; Draft Technical Guidance Download Services (version 2.0) 25.09.2009; Draft Technical Guidance for INSPIRE Coordinate Transformation Services (Version 2.0) 07.09.2009; INSPIRE View Service Technical Guidance (Version 2.0) 28.07.2009; Technical Guidance Discovery Services (2.0) 23.07.2009; INSPIRE Draft Technical Guidance Coordinate Transformation (Version 1.0) 27.02.2009; INSPIRE Draft Technical Guidance Download Services (Version 1.0); 27.02.2009; Draft Technical Guidance: Discovery Services (Version 1.0) 11.04.2008; Draft Technical Guidance: View Services (Version 1.0) 11.04.2008; Strona 28 z 185

Draft Technical Guidance for INSPIRE Schema Transformation Service (version 2.0) 11.06.2010; Draft Technical Guidance for INSPIRE Coordinate Transformation Services 15.03.2010; Draft Technical Guidance Download Services (version 2.0) 25.09.2009; Draft Technical Guidance for INSPIRE Coordinate Transformation Services (Version 2.0) 07.09.2009; INSPIRE View Service Technical Guidance (Version 2.0) 28.07.2009; Technical Guidance Discovery Services (2.0) 23.07.2009; INSPIRE Draft Technical Guidance Coordinate Transformation (Version 1.0) 27.02.2009; INSPIRE Good practice in data and service sharing 01.06.2010; Guidance on the 'Regulation on access to spatial data sets and services of the Member States by Community institutions and bodies under harmonised conditions 27.04.2010; 2.2.3 Uwarunkowania lokalne mające wpływ na rozwiązania techniczne systemu Obowiązująca u Zamawiającego Polityka bezpieczeństwa w zakresie utrzymania zdolności organizacyjnej i technicznej systemów teleinformatycznych do świadczenia usług, zakłada wdrożenie infrastruktury technicznej MSZ-KIIP zapewniającej dublowanie elementów newralgicznych infrastruktury sprzętowej i systemowych, celem zapewniania ciągłości pracy systemu przez równoczesne utrzymanie zdolności technicznej do świadczenia usług przez tzw. infrastrukturę podstawową MSZ-KIIP zlokalizowaną w serwerowni głównej Urzędu Miasta Katowice (lokalizacja: ul. 3 Maja) oraz w serwerowni zapasowej (lokalizacja: ul. Francuska). 2.2.4 Architektura fizyczna 2.2.4.1 Głownie założenia techniczne 1. System MSZ-KIIP będzie gromadził dane przestrzenne i opisowe przy wykorzystaniu oprogramowania bazodanowego, w którym zastosowany będzie otwarty format zapisu danych przestrzennych zgodnie z formatem OGC: WKB, WKT (opcjonalnie SDO_GEOMETRY). 2. Ze względu na kwestie wydajnościowe oraz problem utrzymania poszczególnych rozwiązań aplikacyjnych (prowadzenie baz danych PZGiK a System MSZ-KIIP) nie zakłada się możliwości wykorzystania aktualnie dostępnych i używanych przez Zamawiającego licencji oprogramowania bazodanowego Oracle 9i przy utworzeniu nowych instancji bazy danych. Strona 29 z 185

3. System zostanie zaimplementowany w środowisku technologicznym GIS dostawcy Wykonawcy systemu MSZ-KIIP lub przy wykorzystaniu udostępnionych przez Zamawiającego licencji oprogramowania narzędziowego GIS, co dotyczy licencji oprogramowania ESRI Inc. takich jak: licencje serwera mapowego ArcGIS serwer, licencje ArcGIS Desktop Standard dostępne na mocy zawartej przez Miasto Katowice umowy korporacyjnej (ang. Enterprise License Agreement ELA). 4. Obsługa węzła lokalnego IIP będzie zaimplementowana zgodnie z wymaganiami określonymi przez standardy OGC oraz normy ISO w zakresie danych przestrzennych, usług oraz meta danych. 5. System zostanie zaimplementowany w architekturze wielowarstwowej z wydzieleniem warstw: prezentacji, przetwarzania, obsługi danych oraz warstwy pośredniej zapewniającej co najmniej usługi monitorowania usług aplikacyjnych. 6. System będzie gromadził dane w tzw. Centralnej Bazie Danych MSZ-KIIP, a na potrzeby obsługi użytkowników zewnętrznych będzie prowadził oddzielną bazę danych, stanowiącą replikę bazy centralnej. 7. Dane osobowe będą przechowywane w dedykowanym schemacie aplikacyjnym (schemat: PESEL). 8. Celem efektywnego zarządzania mocą obliczeniową infrastruktura systemu zostanie oparta na oprogramowaniu do wirtualizacji zasobów np. VMware. 9. Do obsługi systemowej serwerów sprzętowych oraz wirtualnych powinno być wykorzystane oprogramowanie systemowe MS Server 2008 R2 dostępne w ramach licencji MS Windows Server 2008 Data Center lub nowsze, w wersji umożliwiającej pracę na architekturze 64-bitowej procesora oraz w środowisku maszyn wirtualnych lub inne równoważne spełniające wymagania kompatybilności funkcjonowania w całościowej infrastrukturze systemowej MSZ-KIIP (współpraca z oprogramowaniem do wirtualizacji zasobów, serwerem bazodanowym, aplikacyjnym serwerem mapowym). 10. Z uwagi na fakt, iż System MSZ-KIIP nie jest systemem czasu rzeczywistego ani systemem krytycznym, nie jest konieczne pełen wdrożenie dla MSZ-KIIP rozwiązań systemu wysokiej dostępności (ang. High Availability). Wysoki poziom dostępności systemu MSZ-KIIP zostanie zapewniony przede wszystkim przez zastosowanie takich rozwiązań: jak klaster serwerów bazy Strona 30 z 185

danych, opcjonalnie klaster serwerów aplikacyjnych oraz zdublowanie zasadniczej infrastruktury technicznej MSZ-KIIP (serwery, macierze). 11. Bezpieczeństwo systemu w zakresie komunikacji (i przetwarzania danych) zapewnione zostanie przez mechanizmy WS* Specification, w tym w szczególności przez protokół WS-Addressing, który specyfikuje sposób powiązania adresów punktów końcowych (endpoint reference ERP). Natomiast stanowiska pracy zostaną zabezpieczone również przez odpowiednie oprogramowanie antywirusowe w formie licencji na serwer plików. 12. System umożliwi poprawną pracę w sieci LAN, WAN przy wykorzystaniu protokołów TCP/IP, w tym IP v6. 13. Podstawowym interfejsem użytkownika zapewniającym dostęp do systemu oraz zawartych w nim danych będzie standardowa przeglądarka WWW np.: Microsoft Internet Explorer wersja 2 9.x, Mozilla Firefox wersja 13.x, Opera wersja 12.x, Google Chrom wersja 20.x 14. Opcjonalnie, warstwa pośrednia architektury systemu związana np. z usługami monitorowania decyzją Wykonawcy MSZ KIIP może zostać zaimplementowana w oparciu o szynę danych ang. Enterprise Service Bus (ESB). 2.3 Infrastruktura sprzętowa na potrzeby MSZ-KIIP 2.3.1 Koncepcja Centrum Przetwarzania Danych MSZ-KIIP (CPD) 2.3.1.1 Ogólne założenia Na potrzeby realizacji Projektu i wdrożenia Systemu MSZ-KIIP proponuje się wdrożenie infrastruktury technicznej stanowiącej tzw. Centrum Przetwarzania Danych (skrót CPD). CPD zapewni funkcjonowanie systemu wewnątrz organizacji, umożliwiając również świadczenie usług publicznych poprzez sieć Internet. CPD stanowić będzie część obecnej, rozbudowanej, infrastruktury teleinformatycznej Urzędu Miasta. 2 Podane wersje są wersjami aktualnie dostępnych produktów. Oprogramowanie narzędziowe GIS serwer mapowy powinno wspierać wymienione najbardziej popularne przeglądarki WWW Strona 31 z 185

Celem zwiększenia dostępności zasobów dyskowych oraz zapewnienia wyższego poziomu dostępności infrastruktury wdrożone zostanie rozwiązanie w tzw. architekturze sieci SAN (ang. Storage Area Networks). SAN centralizuje zasoby dyskowe, zwiększa wydajność oraz wprowadza efektywne mechanizmy archiwizacji danych i konfiguracji poszczególnych serwerów sprzętowych. Docelowo zakłada się, że w ramach projektu w CPD zostanie wdrożona technologia zapewniająca proces tworzenia kopii danych Systemu w konfiguracji D2D2T (ang. disk to disk to tape), co uniezależni i przyspieszy proces tworzenia kopii danych. Technologia ta polega na kaskadowej operacji archiwizacji na dyski macierzy, a dopiero potem na przenoszeniu obrazu kopii na taśmy do biblioteki taśmowej. Do archiwizacji danych używane będą mechanizmy bazy danych tzw. zimny backup oraz dedykowane oprogramowanie specjalistyczne (wymagania wskazane w Dodatku do niniejszego dokumentu). Rysunek 2 SAN Storage Area Network 2.3.1.2 Koncepcja techniczna CPD Poniższy opis przedstawia zakładaną koncepcję infrastruktury technicznej sprzętowo systemowej zalecanej do prawidłowego funkcjonowania Systemu w Centrum Przetwarzania Danych. Zaproponowana architektura techniczna CPD jest otwarta i przystosowana do wymagań budowanego systemu. Opcjonalnie na bazie zastosowanego rozwiązania technologicznego możliwe będzie skalowanie rozwiązania w odpowiedzi na rosnące wymagania poprzez zwiększenie mocy serwerów lub ich liczby, jak i powiększenie zasobów infrastruktury macierzy dyskowej przez zwiększenie pojemności dyskowej (dodatkowe dyski, półka dyskowa). Strona 32 z 185

Rysunek 3 Architektura logiczna Centrum Przetwarzania Danych (CPD) Kluczowym elementem Centrum Przetwarzania Danych (Rysunek 3 Architektura logiczna Centrum Przetwarzania Danych (CPD)Rysunek 3 Architektura logiczna Centrum Przetwarzania Danych (CPD)Rysunek 3 Architektura logiczna Centrum Przetwarzania Danych (CPD)) będą macierze dyskowe zapewniające bezpieczeństwo systemu z punktu widzenia ochrony dostępu do danych, jak również funkcjonowania krytycznych aplikacji. Macierze będą łączyły w sobie dwie podstawowe technologie: Storage Area Network (dostęp szybki przez sieć - przełączniki FC) i Network Attached Storage (dostęp przez sieć Ethernet). Zakłada się, że macierz będzie posiadała opcje deduplikacji danych. Zadaniem technologii SAN będzie odciążenie sieci komputerowej Ethernet dzięki zastosowaniu bardzo szybkiej i wydajnej warstwy transportowej opartej o połączenie światłowodowe i dedykowane urządzenia aktywne - szybkie przełączniki FC wykorzystujące protokół Fiber Channel (FC). Strona 33 z 185

W takiej konfiguracji zasoby dyskowe będą widziane przez system operacyjny jako własne wolumeny danych, bez względu na to gdzie będą się fizycznie znajdować. Zastosowanie macierzy dyskowych wyposażonych w interfejsy SAN i NAS umożliwi wykorzystanie ich nie tylko jako zasobów bazodanowych Systemu, lecz również innych zasobów pomocniczych np. dla serwera plików (utrzymanie zarchiwizowanej dużej liczby plików rastrowych). Spójność danych będzie zapewniona przede wszystkim na poziomie systemowym przez wykorzystanie narzędzi i oprogramowania dostarczanego wraz z macierzą oraz systemem zarządzania bazą danych. Dane w CPD będą kopiowane w technologii off-host z wykorzystaniem biblioteki taśmowej zawierającej napędy taśmowe LTO5. Moc obliczeniową CPD zapewnią serwery sprzętowe (4 sztuki) w technologii blade. Wszystkie te zasoby będą montowane na wspólnym stelażu. Dodatkowo dzięki mechanizmom wirtualizacji zasobów (rozszerzenie licencji już posiadanego oprogramowania VMware lub zakup nowej licencji oprogramowania równoważnego) będzie można wdrożyć tzw. separację domen zarządzania, czyli doprowadzać do stanu, w którym dokonywane zmiany nie wymagają rekonfiguracji otoczenia sieciowego. Natomiast dzięki współpracy narzędzi programowych ze zintegrowanym systemem zarządzania, możliwa będzie zmiana środowiska operacyjnego w krótkim czasie - przy minimalnym zaangażowaniu administratora. Ponadto, celem zwiększenia bezpieczeństwa pracy Systemu dla newralgicznych obszarów może być zastosowana technologia klastra serwerów wirtualnych (HA). W macierzach dyskowych, oprócz danych dla aplikacji, będą zlokalizowane obszary zawierające tzw. binarna, czyli obrazy systemów operacyjnych rozpoznawane jako dyski logiczne, nie fizyczne. Większe bezpieczeństwo całości systemu będzie zapewnione przez (opcjonalną) redundancję sprzętową oraz zastosowanie mechanizmów niwelujących skutki ewentualnych awarii. Przed negatywnymi skutkami przerwy w dostawie energii elektrycznej CPD chronić będzie infrastruktura centralnego systemu UPS obecnie już funkcjonująca w infrastrukturze Urzędu Miasta. Zarządzanie infrastrukturą CPD będzie realizowane na poziomie oprogramowania do wirtualizacji zasobów. Do tego celu może zostać wydzielony dedykowany serwer zarządzający oraz oprogramowanie, które w zależności od dostępnych i zakupionych opcji będzie umożliwiać: zdalne instalowanie systemów Strona 34 z 185

operacyjnych i aplikacji, analizę i prognozowanie powstawania wąskich gardeł w środowisku serwerowym, aktywne ostrzeganie administratorów, automatyzację działań korygujących, zarządzanie wirtualnymi i fizycznymi systemami z jednej konsoli oraz inne czynności. Istotną zaletą takiego opcjonalnego systemu zarządzania, może być również możliwość zdalnego zarządzania przy wykorzystaniu połączenia VPN, co umożliwi w przyszłości świadczenie usług serwisowych przez Wykonawcę Systemu MSZ-KIIP. Na bazie obecnych doświadczeń Inżyniera Projektu (IP) przyjmuje się, że obsługa baz danych zostanie wyłączona ze środowiska wirtualnych serwerów CPD, co również pozwoli uniknąć potencjalnych problemów w zakresie kwestii licencyjnych np. w przypadku bazy danych Oracle. 2.3.2 Proponowana infrastruktura techniczna (sprzętowa) Budując koncepcję infrastruktury technicznej (sprzętowej) w zakresie infrastruktury przetwarzania danych przyjęto następujące kluczowe założenia: 1. MSZ-KIIP posiadać będzie dla każdej strefy - wewnętrznej i zewnętrznej (sieć Internet) dedykowaną bazę danych (tj. instancję bazy danych), przy czym pierwotną bazą danych będzie zawsze baza danych w sieci lokalnej, natomiast zewnętrzna baz będzie w zdecydowanej większości repliką bazy wewnętrznej, 2. CMS obsługiwać będzie serwisy zewnętrzne poszczególnych geoportali opcjonalnie może znaleźć swoje zastosowanie również do obsługi serwisów wewnętrznych, 3. usługi systemowe oraz aplikacyjne z wyłączeniem serwera bazodanowego będą udostępniane i zarządzane przez serwery wirtualne, 4. fizyczna baza danych zostanie zainstalowana na odrębnym serwerze sprzętowym lub dwóch serwerach sprzętowych (opcja zalecana) w układzie klastra bezpieczeństwa passive active np. w przypadku zastosowania bazy danych Oracle z wykorzystaniem mechanizmu Real Applications Cluster (RAC), 5. jeżeli, konfiguracja podstawowa nie spełni stawianych wymagań wydajnościowych w obszarze obsługi odwołań do bazy danych, zakłada się, że układ klastra bezpieczeństwa zostanie przekształcony w klaster wydajnościowy ( active-active ) z opcją zarządzania obciążeniem ruchu zapytań do obu serwerów (ang. load -balancing). Strona 35 z 185

2.3.2.1 Koncepcja logiczna wydzielenia urządzeń (serwery) INTERNET CZĘŚĆ ZEW PROXY CMS APPMAP APPSEC APPSER INST-ZEW Środowisko wirtualne DB-SERWER CZĘŚĆ WEW INT-PROXY INT-APPMAP INT-APPSEC INT-APPSER INST-WEW Środowisko wirtualne STORAGE Rysunek 4 Wydzielenie serwerów logicznych przetwarzania danych MSZ-KIIP Przydzielone zadania zakres świadczonej usługi systemowej: PROXY serwer Proxy CMS serwer z aplikacją CMS APPMAP przykładowo serwer z aplikacją mapową APPSEC serwer z aplikacją do zabezpieczania serwisów mapowych APPSER serwer udostępniający serwisy mapowe DB-SERWER fizyczny serwer bazodanowy INST-ZEW instancja bazy danych dostępnych z zewnątrz INST-WEW instancja bazy danych dostępnych wyłącznie z wewnątrz + użytkownicy np. poprzez VPN INT-PROXY serwer Proxy dla dostępu wewnętrznego INT-APPMAP przykładowo serwer z aplikacją mapową dostępną tylko wewnętrznie Strona 36 z 185

INT-APPSEC serwer z aplikacją do zabezpieczania serwisów mapowych dostępnych wewnętrznie APPSER serwer udostępniający serwisy mapowe dostępne wewnętrznie 2.3.2.2 Analiza zapotrzebowania w zakresie mocy przetwarzania danych Ze względu na brak publikowanej dokumentacji w ofercie dostawców oprogramowania GIS takich jak np. Bentley Inc., AutoDesk Inc, Intergraph Inc., dotyczącej metod i technik doboru infrastruktury technicznej zależnej od architektury systemu, na potrzeby budowy systemu MSZ-KIIP przyjęto, iż: przykładowa analiza dotycząca doboru parametrów infrastruktury sprzętowej zostanie przeprowadzona w oparciu o publikowane materiały informacyjno-techniczne ESRI Inc. http://wiki.gis.com/wiki/index.php/system_design_strategies, w tym dostępne narzędzia dedykowany kalkulator opracowany przez ESRI Inc. (arkusz MS Excel), wyniki skalowania oraz doboru infrastruktury sprzętowej będą równie poprawne dla każdej innej równoważnej technologii GIS, co wyniki z wykorzystaniem technologii ESRI Inc., zapewniającej podobny stopnień złożoności technologicznej oraz będą spełniać wymagania funkcjonalne i niefunkcjonalne wobec systemu MSZ-KIIP. W związku z powyższym założono, iż usługi obsługi danych przestrzennych w sieci Internet / intranet muszą zapewniać: wielodostępną edycję map, wielodostępny przegląd map, gromadzenie i wyszukiwanie danych atrybutowych jaki i przestrzennych (obsługa bazy danych), obsługę serwisu Web (serwer WWW), obsługę renderowania przygotowania obrazu mapy do publikacji, obsługę portalu CMS. W przypadku MSZ-KIIP ze względu na założenie pośredniej separacji obsługi środowiska wewnętrznego (Intranet) od środowiska zewnętrznego (Internet) oraz przyjętą architekturę fizyczną serwera bazodanowego (jeden fizyczny serwer, dwie instancje bazy danych), skalowanie parametrów wydajnościowych przeprowadzono dla obu środowisk łącznie. Dobór konfiguracji podstawowych parametrów serwerów sprzętowych, w tym określenia wstępnych parametrów technicznych, dokonano na podstawie: przyjętych kryteriów, tj. liczby użytkowników oraz liczby wyświetleń map na minutę, jak również określonej architektury rozwiązania, w tym jego złożoności. Założenia szacunkowe: 1. Użytkownicy wewnętrzni sieć LAN Strona 37 z 185

Zakładamy, że każdy użytkownik może pobrać mapy dynamiczne (ciężkie, składane z wielu warstw), korzystać z pobrania gotowych kafelków oraz korzystać z map dynamicznych lekkich, tj. składających się z niewielu warstw). Dla sieci LAN zostało założone korzystanie w taki sposób w jednym czasie 20 użytkowników, co oznacza że w tym samym czasie każdy z nich może wykonać zakładane wyżej pobieranie map różnego typu. 2. Użytkownicy zewnętrzni sieć WAN (tunelowany dostęp poprzez VPN) Zakładamy, że każdy użytkownik może pobrać mapy dynamiczne (ciężkie, składane z wielu warstw), korzystać z pobrania gotowych kafelków oraz korzystać z map dynamicznych lekkich tj. składających się z niewielu warstw). Dla sieci WAN zostało założone korzystanie w taki sposób w jednym czasie 10 użytkowników, co oznacza że w tym samym czasie każdy z nich może wykonać zakładane wyżej pobieranie map różnego typu. 3. Użytkownicy Internet Zakładamy, że każdy użytkownik może pobrać mapy dynamiczne (ciężkie, składane z wielu warstw), korzystać z pobrania gotowych kafelków oraz korzystać z map dynamicznych lekkich, tj. składających się z niewielu warstw). Dla sieci WAN zostało założone korzystanie w taki sposób w jednym czasie 70 użytkowników, co oznacza że w tym samym czasie każdy z nich może wykonać zakładane wyżej pobieranie map różnego typu. Zapotrzebowanie na sprzęt zostało oszacowane z użyciem wyżej wymienionych danych kalkulatora http://wiki.gis.com/wiki/index.php/system_design_strategies, w tym dostępnych narzędzi - dedykowany kalkulator opracowany przez ESRI Inc. (arkusz MS Excel). 2.3.2.2.1 Opcja I (pierwsza) wyłącznie jeden serwer bazodanowy Wyniki przeprowadzonej kalkulacji wg metody dla rozwiązań i konfiguracji środowiska serwerowego w technologii ESRI Inc. dla opcji I (pierwsza) załączono na poniższym rysunku (Rysunek 5 Wyniki skalowania infrastruktury sprzętowej MSZ-KIIP copja I (wg metody oraz techniki dla technologii ESRI Inc.)). Na tej podstawie, w oparciu o Strona 38 z 185

wyniki testów SPECrate_int2006 3 http://www.spec.org/cpu2006/results/rint2006.html przyjęto, iż architektura fizyczna serwerów fizycznych na potrzeby MSZ-KIIP powinna składać się 4 serwerów fizycznych typu Blade: 1 Serwer bazodanowy serwer ten powinien charakteryzować się wynikami nie niższymi niż Base: 132 oraz Peak: 142 zgodnie z testem: http://www.spec.org/cpu2006/results/rint2006.html 3 Serwery na środowisko wirtualne - serwery te powinny charakteryzować się wynikami nie niższymi niż Base: 269 i Peak: 285 zgodnie z testem: http://www.spec.org/cpu2006/results/rint2006.html Ww. wyniki otrzymano na podstawie wyników składowych mocy obliczeniowej konfiguracji sprzętowej przyjętej do skalowania. 3 Dane publikowane są na stronie SPEC Standard Performance Evaluation Corporation http://www.spec.org Strona 39 z 185

Rysunek 5 Wyniki skalowania infrastruktury sprzętowej MSZ-KIIP copja I (wg metody oraz techniki dla technologii ESRI Inc.) Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 40 z 185

2.3.2.2.2 Opcja II (druga) klaster serwerów bazodanowych Wyniki kalkulacji dla opcji II (drugiej) według tej samej metody i techniki obliczeń co dla opcji I zawarto na poniższym rysunku (Rysunek 5 Wyniki skalowania infrastruktury sprzętowej MSZ-KIIP copja I (wg metody oraz techniki dla technologii ESRI Inc.). W opcji tej też mamy 4 serwery fizyczne, przy czym 2 z nich stanowią klaster bazy danych a dwa pozostałe środowisko uruchomieniowe do zarządzania mocą w środowisku wirtualnym np. oprogramowania VMWare. Według tych wyliczeń mamy: 2 serwery bazodanowe każdy serwer powinien charakteryzować się wynikami nie niższymi niż Base: 40 i Peak 43 w konfiguracji dwuprocesowej lub Base: 145, Peak: 153 w konfiguracji jednoprocesorowej zgodnie z testem: http://www.spec.org/cpu2006/results/rint2006.html 2 serwery na środowisko wirtualne serwery te powinny charakteryzować się wynikami nie niższymi niż Base 4 : 38,8 i Peak 41,9 w konfiguracji dwuprocesowej lub Base: 353, Peak: 378 w konfiguracji jednoprocesorowejhttp://www.spec.org/cpu2006/results/rint2006.html Ww. wyniki otrzymano na podstawie wyników składowych mocy obliczeniowej konfiguracji sprzętowej przyjętej do skalowania. 4 Opcjonalnie jeden z nich może osiągać wartości Base 35,4 Peak 38,2 w konfiguracji 2 procesorowej i Base 308 Peak 330 dla konfiguracji jednoprocesorowej Strona 41 z 185

Rysunek 6 Wydzielenie serwerów logicznych przetwarzania danych MSZ-KIIP opcja II (klaster serwerów bazy danych) Strona 42 z 185

Rysunek 7 Wyniki skalowania infrastruktury sprzętowej MSZ-KIIP opcja II (wg metody oraz techniki dla technologii ESRI Inc.) Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 43 z 185

2.3.2.3 Wstępny podział zasobów dyskowych Na podstawie przeprowadzonej analizy obecnych zasobów w zakresie danych przestrzennych oraz szacunków dla planowanego rozszerzenia tego zasobu (w tym tworzonych nowych odwzorowań cyfrowych dla dokumentów i danych) oszacowano, iż zasoby pamięci dyskowej muszą zapewnić w pierwszym okresie wdrożenie Systemu MSZ-KIIP obszar na dane o lokacji minimum 4 TB pamięci do bezpośredniego wykorzystania na danych, co przy wdrożeniu odpowiednio konfiguracji RAID 5 5, 6 lub 10 (http://www.synology.com/support/raid_calculator.php?lang=plk) daje wielkość przynajmniej 14 TB pamięci dyskowej dla projektowanego środowiska macierzy dyskowej. Planowane 4 TB natywnych zasobów dyskowych rozdysponowano odpowiednio na zasoby techniczne: bazy danych oraz kafle 6 odpowiednio po 1 TB na potrzeby: 1. instancji wewnętrznej bazy danych (INST-WEW) 2. instancji zewnętrznej bazy danych (INST-ZEW) 3. na usługi kafelkowania serwera aplikacyjnego APPSER 4. na usługi kafelkowania serwera aplikacyjnego APPSER 2.3.2.4 Założenia dot. polityki bezpieczeństwa systemu w zakresie zabezpieczenia ciągłości pracy Bazując już na wcześniej przyjętych założeniach dotyczących: wdrożenia klastra bezpieczeństwa dla systemu zarządzania bazą danych, zastosowania środowiska wirtualizacji (VMWare lub inne rozwiązania równoważnego), zastosowania techniki tworzenia kopii zapasowej D2D2T, wdrożenie zdublowanej infrastruktury technicznej MSZ-KIIP w serwerowni zapasowej, integracji z istniejącą infrastrukturą systemową środowiska kopii zapasowej, w tym środowiska do wirtualizacji (VMware), wykonywanie backupu środowiska fizycznego, środowiska wirtualnego oraz kopii bazy danych, można wskazać, iż obowiązującą dla systemu MSZ-KIIP strategię zabezpieczenia ciągłości pracy będzie strategia oparta o następujące rozwiązania i techniki: 5 Wybór określonego poziomu zabezpieczenia należy do decyzji bezpośredniego wykonawcy MSZ-KIIP i jest dość często warunkowany względami wydajnościowymi oprogramowania bazodanowego 6 dane na potrzeby usług kafelkowania ang. title cache Strona 44 z 185

1. zastosowanie techniki CDP (ang. Continuous Data Protection), czyli ciągłego zapisywania i zabezpieczanie zmian, jakie zachodzą w danych, w czasie rzeczywistym - praktycznie na bieżąco bez jakichkolwiek opóźnień czasowych na poziomie: a. zasobów dyskowych systemu: i. dla systemu bazy danych przez rozwiązanie data mirroring, ii. dla macierzy dyskowej przez zastosowanie: różnych dostępnych technik jak: snaping mirroring w połączeniu z thin provision oraz VTL (rozszerzenie techniki D2D2T), co zapewni tworzenie kopii migawkowej w obrębie macierzy dyskowej lub jej kopii funkcjonującej np. w zapasowym centrum przetwarzania danych w serwerowni zapasowej, b. środowiska maszyn wirtualnych przez: i. opcjonalne wdrożenie klastrów dla maszyn wirtualnych dla wrażliwych usług systemowych MSZ-KIIP przez wykorzystanie opcji wysokiego poziomu dostępności (HA), ii. utrzymywanie kopii maszyny wirtualnej w innym systemie, aby w sytuacji awaryjnej można było kontynuować prace po otworzeniu obrazu uszkodzonego systemu np. zastosowanie rozwiązań VMWare vcenter Site Recovery Manager z funkcjonalnością vsphere Replication lub rozwiązania równoważnego, 2. tworzenie kopii przyrostowej w ustalonych cyklach np. dziennych (lub kilkudniowych) przez zastosowanie technik i funkcji systemu zarządzania bazą danych tj. funkcji kopiowania na bieżąco on- linie z uwzględnieniem czynności optymalizujących proces przez wydzielenie części danych wolnozmiennych (np. rastry, zdjęcia lotnicze, ortofotomapa), dla których funkcje backup wykonywane będą wyłącznie zidentyfikowanej zmiany lub wprowadzenia do pliku bazy danych lub plików skojarzonych nowych danych, 3. tworzenie tradycyjnej, pełnej kopii binarów systemu oraz bazy danych w trybie pracy na zimno, czyli przy wyłączonej pracy systemu MSZ-KIIP w ustalonych cyklach zgodnie z obowiązującą polityką systemu zarządzania bezpieczeństwem informacji w Urzędzie Miasta Katowice np. co tydzień w każdy piątek po zakończeniu dnia pracy przez urząd, przez zastosowanie własnych rozwiązań bazy danych np. dla Oracle Recovery Manager (RMAN) lub opcji dedykowanego systemu do tworzenia kopii zapasowych, Strona 45 z 185

Przyjęte dla strategii zabezpieczenia ciągłości pracy systemu MSZ-KIIP parametry i rozwiązania powiny zostać określone na etapie implementacji systemu uwzględniając dostępne produktowe rozwiązania. Podstawą do ich określenia powinna być analiza ryzyka określająca parametry odtworzeniowe dla procesów biznesowych wspieranych przez MSZ-KIIP. Dotyczy to takich parametrów jak: RTO (Recovery Time Objective) - parametr określający czas, w ciągu którego aplikacja lub cała sieć organizacji musi zostać odtworzona. Definiując RTO, akceptujemy ryzyko związane z przerwą dotyczącą działania danej aplikacji w tym czasie. System pracujący okresowo, jak np. comiesięczne sporządzanie listy płac, może mieć dopuszczalny czas wyłączenia wyrażany w tygodniach. Systemy sterowania procesami przemysłowymi mogą mieć RTO ustalane w minutach lub nawet sekundach. RPO [Recovery Point Objective) - określa moment w działalności organizacji sprzed awarii, do którego dzięki backupowi będzie można wrócić. Wyrażony przez czas parametr określa więc ilość danych, jaka może być utracona, lub które organizacja gotowa jest poświęcić jako skutek awarii. RPO o wartości 1 godziny oznacza, że po ponownym uruchomieniu procesu użytkownicy nie stracą więcej aniżeli godzinę pracy. TTO (Test Time Objecthe) - parametr testowania samego procesu odtwarzania po katastrofie. Określa okno czasowe, w którym test musi zostać wykonany, aby proces uznać za pomyślny. Celem testu jest sprawdzenie, czy po odtworzeniu pliki danych i cały odbudowany serwer są kompletne i będą oprawnie pracować. Zakłada się, że infrastrukturę zabezpieczającą system MSZ-KIIP stanowić będą: 1. środowisko wirtualne infrastruktury Urzędu Miasta Katowice np. VMWare lub równoważne, 2. oprogramowanie do wykonywania kopii systemu oraz baz danych z opcją tworzenia kopii na bieżąco (on-nie) dedykowane oprogramowanie typu np. Symantec Backup Exec lub ine równoważne oraz rozwiązania własne zastosowanego systemu zarządzania bazą danych, 3. zdublowana infrastruktura techniczna: serwery, macierz dyskową oraz biblioteka taśmowa. 2.3.3 Dyskusja dotycząca opcji implementacyjnej SaaS oraz kolokacja 2.3.3.1 Usługi SaaS / kolokacja Z uwagi na fakt, iż rezultaty oraz produkty przedmiotowego projektu stanowić będą wyłączną własność Beneficjenta przedmiotowego projektu tj. Miasta Katowice, który musi zapewnić jego trwałość w okresie Strona 46 z 185

referencyjnym co najmniej 5 lat od daty zakończenia projektu, tym samym nieuzasadnione i merytorycznie niepoprawne jest widzenie funkcjonowania systemu MSZ-KIIP (jako całości) w architekturze SaaS z uwagi na istotne sprzeczności założeń projektu z założeniami - definicją modelu przetwarzania SaaS. W modelu tym wyróżnia się Dostawcę / Operatora Usługi - rozumianej jako pełna, kompletna w ddanym przedmiotowym obszarze. W przypadku projektu MSZ-KIIP musiałoby to oznaczać prawne przekazanie produktów nabytych w ramach projektu osobie trzeciej, co dalej skutkowałoby pojawieniem się aspektu udzielania pomocy publicznej na rzecz tego podmiotu. Potwierdzeniem słuszności tak postawionych tez są wyniki opracowania SaaS jako metoda świadczenia e-usług Michał Szyszko http://www.web.gov.pl/e-booki/272_416.html opracowanie na zlecenie PARP. Rozwiązanie w, którym następuje wyłącznie wykorzystanie maszyn wirtualnych dzierżawionych w modelu PaaS / SaaS (ang Platform / System as a Service, platforma/system jako usługa) jest wysoce złożone i kosztowne z uwagi na występujący wówczas problem zapewnienia bezpieczeństwa oraz możliwości zarządzania infrastrukturą. Przyjęcie takiego rozwiązania powinno wiązać się z nałożeniem znacznych wymagań technicznych na łącze (minimum podwójne łącza zapasowe) oraz z kwestią pojawiających się zagrożeń z sieci Internet oraz koniecznością podwyższonego bezpieczeństwa wewnętrznej infrastruktury teleinformatycznej i trudnościami w jej zarządzaniu. Podobne wymagania występować będą w przypadku kolokacji części lub całości zakupionej infrastruktury teleinformatycznej (serwery, macierz), gdzie oprócz spełnienia wymagań normy ANSI TIA-942 należy przeanalizować i uwzględnić konkretne uwarunkowania dostawcy takiej usługi (Data Center) mające wpływ na koszt oraz parametry jakościowe tego typu usług w trybie umowy SLA. 2.3.3.2 Dyskusja nt. koncepcji infrastruktury dostępowej do sieci publicznej Internet na potrzeby przetwarzania w chmurze oraz kolokacji infrastruktury IT Koncepcja infrastruktury dostępowej do sieci publicznej Internet musi zakładać wykorzystanie zaawansowanych, niezawodnych i wydajnych rozwiązań z zakresu bezpieczeństwa IT zarówno na styku z Internetem jak i po stronie wewnętrznej sieci LAN. W takim przypadku funkcję bramy brzegowej odpowiadającą za komunikację z zewnętrznymi systemami powinny pełnić routery z protokołem BGP (ang. Border Gateway Protocol), który jest konieczny do zapewnienia ciągłej komunikacji przez dwa niezależne łącza internetowe od dwóch różnych dostawców usług internetowych. Strona 47 z 185

Podstawowe bezpieczeństwo systemu dostępowego powinien zapewnić system - firewall, który dostarczy funkcje zabezpieczenia sieci lokalnej i pracujących systemów przed szkodliwym działaniem intruzów. Rozwiązanie takie zazwyczaj stanowi połączenie ochrony sprzętowej z programową, tak aby umożliwić ochronę przed nieautoryzowanym dostępem z zewnątrz zarówno dla sieci wewnętrznej LAN jak również ochronę przed nieuprawnionym wypływem danych z sieci lokalnej na zewnątrz. Do zasadniczych funkcji takiego systemu zabezpieczeń należy filtrowanie połączeń wchodzących i wychodzących oraz odmawianie żądań dostępu uznanych za niebezpieczne. Z uwagi na przetwarzanie całości ruchu na styku sieci lokalnej z Internetem oraz pomiędzy poszczególnymi podsieciami lokalnej sieci komputerowej wskazane będzie zapewnienie dość dużej przepustowości zastosowanych urządzeń. Kolejnym elementem zabezpieczeń będą urządzenia typu IDS (ang. Intrusion Detection System), IPS (ang. Intrusion Prevention System), które gwarantować będą monitorowanie oraz wykrywanie i zapobieganie włamaniom. Są to urządzenia sieciowe zwiększające bezpieczeństwo sieci poprzez wykrywanie (IDS) lub wykrywanie i blokowanie ataków (IPS) w czasie rzeczywistym. Tego typu urządzenie pracuje w trybie czasu rzeczywistego i analizuje oraz bezpośrednio uczestniczy w przekazywaniu wszystkich pakietów przesyłanych w sieci oraz ma możliwość blokowania w 100% pakietów rozpoznanych jako niebezpieczne. Działanie w tym trybie nakłada na oprogramowanie zainstalowane na urządzeniu analizującym ruch (sondzie) znacznie wyższe wymagania co do wydajności i stabilności. Ponadto, urządzenie IPS może równocześnie chronić użytkowników lokalnej sieci wewnętrznej jak i całą infrastrukturę portalu usług publicznych. Jednym z ostatnich elementów zapewniających bezpieczeństwo będzie zastosowanie urządzeń (modułów) anty-wirus i anty-malware, których celem jest wykrywanie, zwalczanie, usuwanie i zabezpieczanie systemów oraz sieci przez wirusami komputerowymi, robakami, trojanami, programami szpiegującymi, rootkitami, keyloggerami, itp. Całość ww. rozwiązań powinna zostać rozszerzona dodatkowo o możliwość skanowania również ruchu zaszyfrowanego SSL w celu wykrycia zagrożeń, powinna dać stosunkowo wysoki poziom bezpieczeństwa (planowanej) infrastrukturze dostępowej sieci Internet. Zaproponowane powyżej rozwiązania techniczne zapewniające wskazane funkcje bezpieczeństwa mogą być budowane w różnych konfiguracjach i opcjach. Strona 48 z 185

Jedną z nich, a zarazem może najprostszą jest konfiguracja składająca się z tzw. router a brzegowego (dostępowego) oraz rozwiązania klasy UTM (ang. Unified Threat Management), czyli scentralizowanego systemu zabezpieczeń, który łączy w jednym urządzeniu szeroki zakres różnych technologii bezpieczeństwa sieciowego, dzięki czemu zapewnia infrastrukturze dostępowej całościową ochronę przed takimi zagrożeniami jak: wirusy, robaki internetowe, trojany, spam, Backdoor, ataki typu Dos, czy też próby włamań ze strony hackerów. Najczęściej rozwiązania UTM łączą w jednym urządzeniu funkcje typu: firewall, system zapobiegania włamaniom (IPS), brama warstwy aplikacji, brama sieci VPN, skaner antywirusowy oraz filtr antyspamowy. W przypadku Urzędu Miasta Katowice część tego typu infrastruktury już istnieje. Na pewno, zgodnie z poniższym ideogramem systemu dostępowego możliwe jest zabezpieczenie transmisji danych przez tunelowane zestawianie połączeń VPN lub ich szyfrowanie SSL oraz IPsec, gdzie pakiet takiego zabezpieczenia może zapewnić urządzenie klasy UTM. Strona 49 z 185

Rysunek 8 Koncepcja systemu dostępowego różne techniki zapewnienia bezpieczeństwa danych (połączenie tunelowane VPN, połączenia SSL, IPSec) Jednak kluczowe jest zapewnienie ciągłego dostępu do wydzielonych na zewnątrz usług, co wymaga zapewnienia wysokiego poziomu bezawaryjnej pracy infrastruktury dostępowej do sieci Internet, wraz z dostępem do wielu operatorów sieci Internet. W takim przypadku należałoby rozważyć opcję i konfigurację rozwiązania w oparciu o architekturę klastrową (ang. HA - High Availiability) infrastruktury dostępowej zapewniającą jeden z najwyższych poziomów bezawaryjnej pracy konfiguracji sprzętowo programowej. W takim celu konieczne byłoby zapewnienie wyższej niezawodności przez zastosowanie urządzeń pracujących równolegle w konfiguracji (active-backup). Przyjęcie takiego rozwiązania umożliwia zapewnienie ciągłości połączenia w przypadku awarii jednego z urządzeń, bowiem w stanie normalnej pracy urządzenie podstawowe pracuje aktywnie, natomiast drugie pozostaje w trybie oczekiwania tzw. stan standby lub passive. W przypadku awarii urządzenia podstawowego, drugie urządzenie automatycznie przejmuje jego funkcję bez zauważalnych zmian w zachowaniu dla użytkowników systemów. Ponadto, takie rozwiązanie może zapewnić również korzystanie z połączeń internetowych od (co najmniej) dwóch niezależnych dostawców usług internetowych tak, aby wyeliminować możliwość pojedynczego punktu awarii. Wówczas, w przypadku awarii jednego łącza, drugie przejmuje jego funkcję i cały ruch sieciowy. Powyższe rozwiązanie zapewnia protokół GBP. Niestety urządzeń z protokołem GBP Urząd Miasta Katowice na dzień dzisiejszy nie posiada. Używany obecnie Juniper Gatway 204SRX jako typowe urządzenie klasy UTM spełnia wiele ww. funkcji lecz nie posiada protokołu GBP. Strona 50 z 185

Rysunek 9 Rozbudowana, najbardziej niezawodna ale kosztowana architektura infrastruktury dostępowej do sieci Internet (HA) 2.3.3.3 Wnioski Rozwiązanie dzierżawy serwerów na potrzeby MSZ-KIIP w opcji SaaS np. jako rozwiązanie problemu potrzeb i skalowania infrastruktury IT ma swoje zalety ale również można również dość istotne wady. Do zalet należy przede wszystkim: profesjonalne utrzymanie infrastruktury IT spełniające wysokie normy TIA-942, zapewnienie ustalonego poziomu usług umowy SLA, w tym określonych warunków ochrony danych osobowych zgodnie z ustawą o ochronie danych osobowych (jeżeli przedmiotem jest przetwarzanie danych osobowych), możliwość pewnej powszechności dostępu do infrastruktury Data Center za pośrednictwem łączy większości dostawców ISP, co istotnie może ograniczać negatywne skutki awarii łącza dla odbiorcy posiadającego co najmniej dwa łącza dostępowe, możliwość dostępu do infrastruktury dostawcy Data Center nawet w połączeniu do 10 GBit/s, bez pojedynczego punktu awarii. Przeciwwskazaniem dla takiego rozwiązania są jednak istotne koszty usługi utrzymania oraz koszty połączenia lokalizacji usługodawcy usługi Saas lub kolokacji z infrastrukturą Urzędu Miasta Katowice, co wiązać się będzie z koniecznością zestawienia łącza dzierżawionego lub VPN lub jego odpowiednika. W takim przypadku dodatkowo użytkownicy wewnętrzni systemu MSZ-KIIP mogliby również natrafić na ograniczenie łącza po stronie urzędu, które obecnie wynosi 50/50 MBit/s, czego nie ma w przypadku podstawowego rozwiązania związanego z umieszczeniem infrastruktury IT MSZ-KIIP w serwerowni UM Katowice gdzie będzie zapewniony dostęp do sieci szkieletowej 10 GBit/s. Strona 51 z 185

Dodatkowym aspektem, który należy poruszyć są kwestie bezpieczeństwa. Przy kolokacji w Data Center brakuje nadzoru fizycznego nad danymi serwerami, co oznacza, że dostęp fizyczny do serwera mogą mieć potencjalnie osoby trzecie (warunki umowy SLA nie mogą zapewnić, iż w skutek jakiś zdarzeń nie nastąpi tego typu incydent). Aby zapobiec takim zdarzeniom należy np. dodatkowo wykupić opcję fizycznego zabezpieczenia infrastruktury w formie klatki na szafę montażową, bądź opcję monitoringu oraz ewidencji dostępu, co łącznie skutkowałoby znaczącym podniesieniem kosztów utrzymania infrastruktury IT. Reasumując powyższe, zalecanym rozwiązaniem jest umieszczenie infrastruktury IT projektowanego systemu MSZ KIP w infrastrukturze technicznej UM Katowice, z uwagi na: 1. zapewnienie wymaganego wewnętrznymi przepisami Polityki Bezpieczeństwa Informacji poziomu bezpieczeństwa fizycznego (brak dostępu fizycznego osób trzecich), 2. zmniejszenie kosztów utrzymania infrastruktury (brak dodatkowych kosztów łącza dzierżawionego, utrzymania sprzętu, brak kosztów sprzętu dodatkowego potrzebnego do zapewnienia redundancji łącza), 3. zwiększenie dostępności dla użytkowników wewnętrznych (którzy głównie będą korzystać z systemu, poprzez przesyłanie dużych ilości danych, edycje itp., takie rozwiązanie daje możliwość pracy użytkownikom wewnętrznym z udziałem łącza 10 GBit/s), 4. trudne do rozstrzygnięcia aspekty prawne umów SLA na przetwarzanie danych osobowych w chmurze związane z kwestią faktycznego opisu i wskazania miejsca przetwarzania w przypadku dostawcy zewnętrznego niekiedy niekrajowego, co wówczas może wiązać się również z problem klasyfikacji prawnej rozsądzania potencjalnego zdarzenia i naruszenia umowy (w tym umowy SLA i warunków przetwarzania danych osobowych). Powyższe negatywne spojrzenie na teraz na model przetwarzania SaaS nie kwestionuje możliwości zastosowania takiego rozwiązania w przyszłości. 2.3.4 Konfiguracji podsieci infrastruktury sprzętowej Podział sieci na podsieci oraz ich adresacja, włącznie z wydzieleniem adresów na usługi systemowe zostanie ustalony i zrealizowany przez Wykonawcę MSZ-KIIP na etapie implementacji systemu. Obecnie z uwagi na charakter dokumentu i pewne niedookreślenie koniecznej liczby adresów IP oraz ich typu Strona 52 z 185

(rozdzielenie na podsieci) nie jest możliwe dokładne przypisanie adresów do poszczególnych urządzeń (obecnej i docelowej) infrastruktury technicznej MSZ-KIIP. Można przyjąć, iż serwery w zależności od potrzeb będą posiadały pewną ilość/pule adresów wewnętrznych, na które będą przetrasowane odpowiednie numery portów w związku z dostępem do systemu przez użytkowników zewnętrznych. Strona 53 z 185

3 Opis osiągnięcia przewidywanych rezultatów wdrożenia MSZ- KIIP oraz sposób wdrożenia systemu Zgodnie z wymaganiami określonymi w SIWZ dla Inżyniera Projektu 7 (IP), niniejsza dokumentacja zawiera opis osiągnięcia przewidywanych rezultatów wdrożenia MSZ-KIIP, w tym opis strategii budowy, rozwoju oraz udostępniania systemu użytkownikom. Pomijając zakres prac już zrealizowanych (lub będących w trakcie realizacji na dzień opracowania niniejszego dokumentu) pozostałe do wykonania w ramach projektu prace 8 podzielono na 3 zamówienia publiczne: 1. Opracowanie i wdrożenie systemu MSZ-KIIP, wraz z dostawą infrastruktury sprzętowej oraz przeprowadzeniem migracji danych 9, 2. Świadczenie usług promocji, 3. Świadczenie usług Doradcy Technologicznego. W każdym z ww. zamówień wydzielono spójne, łączące się ze sobą działania tworząc odpowiednio zadania (podzadania) oraz etapy, wskazując również na wstępujące pomiędzy nimi zależności. Na tej podstawie opracowano jeden wspólny, uogólniony Harmonogram Prac w ramach Projektu obejmujący prace planowane, przyjmując następujące założenia: 1. Przy opracowaniu harmonogramu uwzględniono istotne zobowiązania Wykonawców wiążące się z dostarczeniem przez nich głównych produktów (i usług) oraz czynności organizacyjne Zamawiającego związane z ich akceptacją lub odbiorem. 2. Dla czytelności opisu oraz celem pewnego uproszczenia w Harmonogramie Prac: 7 Wykonawcza niniejszej dokumentacji technicznej wymagań 8 wyłoniono Inżyniera Projektu (odpowiedzialnego między innymi za dokumentację techniczną projektu) oraz udzielono zamówień w zakresie pozyskania danych 9 Przyjmuje się, że Wykonawca MSZ KIIP uzgodni i zleci zakres usługi związane z opracowaniem usług sieciowych i / lub formatów wymiany danych z poszczególnymi dostawcami systemów zewnętrznych (kategoria wydatków nr 9 Rozwój oprogramowań i serwisów i baz danych MSZ-KIIP) wykorzystując delegację prawną wydaną przez Rozporządzenie 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 Strona 54 z 185

Nie zawarto wszystkich czynności zarządczych, jak również tych działań, które bezpośrednio nie wiążą się z procesem wytwórczym MSZ KIIP jak np. zewnętrzny audyt projektu (zadanie to wskazano wyłącznie sygnalnie w grupie wybranych czynności zarządczych Zamawiającego oraz Inżyniera Projektu (IP) podając prawdopodobny termin kiedy może ono nastąpić, aczkolwiek uruchomienie audytu powinno nastąpić po przekroczeniu wydatkowania 50% wartości wydatków projektu). Nie wskazano w nim czynności dot. komunikacji pomiędzy stronami tj. takich zdarzeń projektowych jak np. zgłoszenie gotowości odbioru, Strona 55 z 185 przyjęcie zgłoszenia i wyznaczenie terminu odbioru / testów akceptacyjnych, wniosek o udostępnienie danych, pomieszczeń do prowadzenia prac instalacyjnych itp. Tego typu działania są tylko po części możliwe do zaplanowania i zazwyczaj wynikają z bieżących uwarunkowań otoczenia projektu i pojawiających się zdarzeń projektowych. Niektóre czynności leżące po stronie zobowiązań IP wskazano jako działania łączne Wykonawcy oraz IP np. opracowanie dokumentacji powykonawczej. 3. Celem umożliwienia monitorowania przebiegu projektu oraz późniejszej jego kontroli wyróżniono techniczne punkty kontrolne, które na harmonogramie Gantta oznaczono wyróżnikiem równym zero 0 dla liczby dni trwania danej czynności. 4. Dla zadań związanych z udzieleniem zamówienia publicznego określono szacowane, realne terminy doprowadzenia do wyboru Wykonawcy, przyjmując odpowiednie odrębnie terminy na opracowanie dokumentacji przetargowej, jej sprawdzenie oraz na przeprowadzenie przedmiotowej procedury, 5. Przyjęte terminy wykonania poszczególnych podzadań, zadań, etapów są uśrednieniem terminów dla tego typu czynności oraz bazują na doświadczeniu IP oraz wynikach podobnych realizowanych projektów, w tym uwzględniają terminy bezpieczne tj. zawierające się pomiędzy terminem przeciętnym a maksymalnym bez potrzeby prowadzenia dyskusji nt. opcji czasowej termin minimalny, przeciętny, maksymalny. 6. Harmonogram Prac może stanowić załącznik do Opisu Przedmiotu Zamówienia SIWZ (OPZ SIWZ). Po wyborze Wykonawcy (z wyłączeniem Doradcy Technologicznego) Harmonogram Prac powinien podlegać aktualizacji przez danego Wykonawcę, tak, aby potwierdzić podane wstępnie terminy lub dostosować je w określonym, dostępnym prawnie (wymagania SWIZ) zakresie do

identyfikowanych przez Wykonawcę uwarunkowań (ograniczony zakres zmian nie dotyczy terminów wskazanych jako krytyczne z punktu widzenia poprawności wykonania zamówienia lub prawidłowego wykonania umowy zgodnie z Ustawą prawo zamówień publicznych). Poniższe podrozdziały zawierają wyszczególnienie zakresu prac, jak również wskazanie zobowiązań Stron w ramach poszczególnych głównych zadań wykonawczych Projektu poszczególnych zamówień. 3.1 Zamówienie nr 1: Opracowanie i wdrożenie systemu MSZ-KIIP, wraz z dostawą infrastruktury sprzętowej oraz przeprowadzeniem migracji danych Celem zamówienia jest dostarczenie i opracowanie rozwiązań systemowych, aplikacyjnych koniecznych do wdrożenia MSZ-KIIP, w tym dostarczenie infrastruktury sprzętowej oraz inicjalne załadowanie danymi bazy danych systemu, w tym opracowanie metadanych i załadowanie ich do katalogu metadanych. Zamówienie będzie realizowane w podziale na etapy, zadania i podzadania, w których istotny proces wdrożenia Systemu podzielono zgodnie z rekomendacją zawartą w Projekcie Generalnym na dwie części, przyjmując zasadniczy podział funkcjonalny Systemu na część wewnętrzną wiążącą się z obsługą użytkowników wewnętrznych 10 oraz związaną zewnętrzną związaną z obsługą Klientów Urzędu, identyfikowaną poprzez obszar funkcjonalny Portalu Obsługi Obywatela oraz cztery Geoportale. Poniżej podstawowy podział zamówienia na etapy wykonawcze: 1. Etap I - Przygotowanie i wdrożenie organizacji Projektu 11 a. Aktualizacja Dokumentacji Zarządczej przez Inżyniera Projektu b. Opracowanie Planu Jakości, Harmonogramu Prac oraz Opis Procesu Wytwórczego c. Aktualizacja Harmonogramu Rzeczowo Finansowego przez Inżyniera Projektu 2. Etap II - Opracowanie Dokumentacji Technicznej Implementacji Systemu (DTIS) 10 co umożliwi szerokie zweryfikowanie poprawności implementacji Systemu przed jego udostępnieniem na zewnątrz w sieci Internet 11 W każdym przypadku kiedy nie wskazano na wprost wykonawcy odpowiedzialnego za realizację danego zadania przyjmuje się, że jest to Wykonawca systemu, a nie Inżynier Projektu Strona 56 z 185

a. Określenie (potwierdzenie) zakresu implementacji usług 4-kategorii b. Opracowanie Modelu Danych c. Opracowanie szablonów raportów, wydruków, zestawień oraz kompozycji mapowych dla poszczególnych modułów, serwisów mapowych oraz portali i geoportali d. Opracowanie reguł migracji - zasilania danymi bazy danych systemu e. Przeprowadzenie warsztatów potwierdzających funkcje i model danych systemu f. Opracowanie Planu i Projektu Testów g. Opracowanie Profilu Metadanych 3. Etap III - Dostawa, instalacja i konfiguracja infrastruktury sprzętowej i oprogramowania a. Dostawa Infrastruktury teleinformatycznej b. Instalacja i konfiguracja infrastruktury sprzętowej i oprogramowania (serwery aplikacji, bazy danych, inne) c. Wydzielenie oraz przygotowanie środowiska testowego 4. Etap IV Opracowanie, implementacja Systemu a. Opracowanie usług aplikacyjnych w zakresie integracji i zasilania Systemu b. Opracowanie procedur, skryptów migracji i zasilania danymi c. Opracowanie rozwiązań aplikacyjnych Systemu dla zakresu wewnętrznego d. Opracowanie rozwiązań aplikacyjnych Systemu dla pełnej skali wdrożenia 5. Etap V - Migracja danych a. Przeprowadzenie migracji danych (zasilenie baz danych systemu) 6. Etap VI - Wdrożenie pilotowe Systemu a. Przeszkolenie zespołu wdrożeniowego b. Przeprowadzenie testów akceptacyjnych c. Przeprowadzenie testów wydajnościowych d. Rewizja wyników testów rekomendacje zmian e. Opracowanie dokumentacji użytkownika oraz systemu pomocy dla użytkownika f. Opracowanie zmian do procedur wewnętrznych Zamawiającego (IP) g. Dokonanie zgłoszenia systemu do GIODO (IP) h. Nadzór autorski - świadczenie asysty technicznej Wykonawcy i. Bieżące skalowanie i rekonfiguracja systemu Strona 57 z 185

7. Etap VII - Wdrożenie Systemu w pełnej skali a. Przeszkolenie zespołu wdrożeniowego b. Przeprowadzenie testów akceptacyjnych c. Przeprowadzenie testów wydajnościowych d. Rewizja wyników testów rekomendacje zmian e. Opracowanie systemu pomocy dla użytkownika f. Opracowanie zmian do procedur wewnętrznych Zamawiającego (IP) g. Dokonanie zgłoszenia systemu do GIODO (IP) h. Opracowanie elementów Polityki Bezpieczeństwa Informacji (zakres systemu) j. Nadzór autorski - świadczenie asysty technicznej Wykonawcy i. Bieżące skalowanie i rekonfiguracja systemu j. Opracowanie dokumentacji powykonawczej Systemu (razem z IP) k. Przeprowadzenie procedury Odbioru Końcowego Ogólny opis poszczególnych etapów wykonawczych zawarto poniżej, natomiast szczegółowy zakres zobowiązań Wykonawcy odnoszący się do danego zakresu prac i etapu zawarto w odrębnym Dodatku. 3.1.1 Etap I - Przygotowanie i wdrożenie organizacji Projektu W ramach Etapu I nastąpi przygotowanie i wdrożenie organizacji Projektu uwzględniającej uwarunkowania wynikające z faktu wyłonienia i podpisania umowy z Wykonawcą. IP zaktualizuje / opracuje dokumentację zarządczą biorąc pod uwagę zakres zobowiązań Wykonawcy i nowe zadania oraz zobowiązania Zamawiającego określone w SIWZ. Powyższe oznacza, w szczególności opracowanie / aktualizację procedur monitorowania, raportowania, kontroli, zarządzania ryzykiem jak również procedur zapewniania jakości uwzględniających w całości lub w części (decyzją Zamawiającego oraz IP) propozycje opracowane przez Wykonawcę w przekazanym przez niego Planie Jakości, który zawierać będzie kryteria jakościowe dla każdego produktu, w tym również dla usług. Poza aktualizacją procedur IP przeprowadzi aktualizację Harmonogramu Prac (HP) oraz Harmonogramu Rzeczowo Finansowego (HRF), przy czym aktualizacja Harmonogramu Prac nastąpi na podstawie harmonogramu opracowanego przez Wykonawcę. Zakres zmian do Harmonogramu Prac będzie obejmował wyłącznie zmiany wynikające z identyfikowanych przez Wykonawcę uwarunkowań wykonawczych oraz proponowanego przez niego sposobu realizacji zamówienia jak również z Opisu Procesu Wytwórczego. Zmiany te mogą Strona 58 z 185

dotyczyć terminów i / lub kolejności zadań (podzadań) oraz etapów, dla których w SIWZ nie zastrzeżono określonej kolejności wobec innych lub, w których nie wyróżniono punktów krytycznych realizacji projektów, czyli terminów określonych w SIWZ. Tak zaktualizowany Harmonogram Prac stanowić będzie dla IP oraz Zamawiającego podstawę do zmiany Harmonogramu Rzeczowo Finansowego a tym samym wprowadzenia aneksu do Umowy o Dofinansowanie. Opis Procesu Wytwórczego razem z uszczegółówmy Harmonogram Prac stanowić będzie narzędzie do monitorowania postępu prac dla IP oraz Zamawiającego. 3.1.2 Etap II - Opracowanie Dokumentacji Technicznej Implementacji Systemu (DTIS) W ramach Etapu II Wykonawca opracuje dokumentację techniczną pn. Dokumentacja Techniczna Implementacji Systemu, w której będzie zobowiązany: 1. Potwierdzić zakres implementacji usług 4-kategorii, przez potwierdzenie wskazanych, nazwanych e-usług podanych w SIWZ lub uzgodnienie z Zamawiającym implementacji e-usług o podobnym poziomie złożoności zależnie od stanu i zakresu wdrożenia e-usług w systemie SEKAP, 2. Opracować reguły migracji i zasilania danymi baz danych MSZ-KIIP, uwzględniając aktualny stan ilościowy i jakościowy baz danych (co obejmuje również zorganizowane pliki XLS) 3. Uzgodnić reguły integracji i bieżącego zasilania danymi z systemów zewnętrznych bazy danych MSZ-KIIP (mapa zasadnicza, ewidencja gruntów, inne), 4. Opracować ostateczny model danych (w formie schematów aplikacyjnych oraz modelu danych w schemacie pojęciowym UML), 5. Opracować wstępny, inicjalny ogólny profil metadanych dla zbiorów i serii zbiorów danych objętych zakresem wdrożenia w MSZ-KIIP, 6. Opracować Plan i Projekt Testów zgodnie z przyjętą przez Wykonawcę metodyką i opcjonalnie narzędziami do testowania ale w zakresie wskazanym w niniejszym dokumencie. 3.1.3 Etap III Dostawa, instalacja i konfiguracja infrastruktury sprzętowej i oprogramowania Etap III obejmuje działania wiążące się z przygotowaniem i uruchomieniem infrastruktury technicznej MSZ-KIIP. W ramach tego etapu Wykonawca dostarczy Zamawiającemu wymagany sprzęt komputerowy Strona 59 z 185

(serwery, macierz, bibliotekę taśmową oraz stacje robocze w ilości wskazanej w specyfikacji) oraz przeprowadzi ich instalację i konfigurację w dwóch lokalizacjach odpowiednio: w serwerowni głównej (ul. 3 Maja) oraz w serwerowni zapasowej (ul. Francuska). Wszystkie związane z tym prace Wykonawca będzie zobowiązany prowadzić tak, aby nie zakłócić normalnej pracy funkcjonujących systemów aplikacyjnych Zamawiającego. W tym celu Zamawiający będzie zobowiązany do udostępnienia pomieszczeń oraz zapewnienia nadzoru w dniach i / lub godzinach poza okresem normalnego czasu pracy urzędu. Szczegółowe uzgodnienia dot. terminów i sposobu pracy w zakresie instalacji sprzętu i konfiguracji Systemu Wykonawca przedstawi w Harmonogramie Prac. Poza tym, zawsze przed zbliżającym się terminem określonych prac Wykonawca będzie uprzedzająco informował Zamawiającego o mających nastąpić działaniach co najmniej na 5 dni przed planowanym terminem. 3.1.4 Etap IV Opracowanie, implementacja Systemu W ramach Etapu IV Wykonawca zaimplementuje poszczególne rozwiązania aplikacyjne i systemowe składające się na System MSZ-KIIP. Z uwagi na podzielenie procesu wdrożenia na dwie części, prace te będą prowadzone przez Wykonawcę adekwatnie do przyjętego podziału funkcjonalnego tak, aby zapewnić możliwość wdrożenia Systemu najpierw w tzw. zakresie wewnętrznym dla wewnętrznych użytkowników Systemu (wdrożenie pilotowe) a następnie dla uzyskania pełnej funkcjonalności Systemu, czyli dla pozostałych rozwiązań aplikacyjnych tj.: Portalu Obsługi Obywatela, Geoportalu Inwestycji, Geoportalu sportu, promocji i turystyki, Geoportalu edukacyjnego oraz Geoportalu metadanych 12. Widocznym dla Zamawiającego wynikiem poszczególnych prac w ramach tego etapu będą wymagane specyfikacją: produkty kontrolne (wskazane w Opisie Procesu Wytwórczego przez Wykonawcę) raporty IP z monitorowania postępu prac raporty Wykonawcy z przeprowadzonych testów wewnętrznych. 3.1.5 Etap V Przeprowadzenie migracji danych W ramach Etapu V Wykonawca będzie zobowiązany do skutecznego (bezstratnego zgodnie z warunkami określonymi w DTIS) zasilenia Systemu danymi ze zbiorów źródłowych oraz systemów zewnętrznych. 12 opcja do decyzji Wykonawcy, czy nie włączyć tego geoportalu do pierwszego podetapu Strona 60 z 185

Wynikiem prac Wykonawcy dla tego etapu będą poprawnie wykonane procedury migracji danych potwierdzone raportami z migracji danych wskazującymi uzyskanie określonego stanu ilościowego oraz jakościowego danych w bazie danych MSZ-KIIP. Przyjmuje się, że dane z migracji zasilą bazę produkcyjną oraz utworzoną przez Wykonawcę bazę szkoleniowo - testową przygotowaną na potrzeby przeprowadzenia szkoleń i testów akceptacyjnych. 3.1.6 Etap VI Wdrożenie pilotowe (rozwiązania wewnętrzne) W ramach Etapu VI przeprowadzone będzie tzw. wdrożenie pilotowe Systemu w zakresie rozwiązań aplikacyjnych wspierających wewnętrzne procedury administracyjne urzędu. Podstawą do uruchomienia prac wdrożeniowych będzie zgłoszenie Wykonawcy o zakończeniu procesu implementacji tej grupy rozwiązań aplikacyjnych oraz zakończeniu etapu migracji danych oraz przygotowaniu bazy testowo szkoleniowej. Przyjęcie zgłoszenia zainicjuje przygotowanie i przeprowadzenie szkolenia dla Zespołu Wdrożeniowego ze strony Zamawiającego. Zakres takiego szkolenia obejmować będzie opracowane i wskazane do wdrożenia funkcjonalności Systemu. Zadaniem Zespołu Wdrożeniowego oraz IP będzie przeprowadzenie testów akceptacyjnych oraz testów wydajnościowych. Zakłada się, iż z uwagi na istotną złożoność opracowanych przez Wykonawcę rozwiązań aplikacyjnych proces ich weryfikacji odbioru przebiegać będzie iteracyjnie 13. I tak, po przeprowadzeniu testów w przypadku uzyskania przez Wykonawcę: negatywnej oceny wyników z testów akceptacyjnych (tj. poziom aspiracji wyników z testów okaże się niższy niż wskazany w Planie Testów), Wykonawca będzie zobowiązany zastosować się do rekomendacji Zamawiającego i przygotować nowa wersję Systemu pozbawioną zidentyfikowanych błędów, uwzględniając przy tym zalecenia / uwagi Zamawiającego, pozytywnej oceny wyników z testów akceptacyjnych (tj. poziom aspiracji wyników z testów będzie równy lub wyższy niż założony w Planie Testów) Strony przystąpią do następnego zadania tj. przygotowania i uruchomiania tzw. eksploatacji nadzorowanej 14, przy czym warunkiem uruchomienia eksploatacji nadzorowanej będzie dostarczenie przez Wykonawcę dokumentacji 13 liczba dopuszczalnych cykli odbioru zostanie określona w specyfikacji 14 Jest to tzw. świadczenie asysty technicznej przez Wykonawcę mające na celu usuwanie na bieżąco identyfikowanych usterek Systemu włącznie z zapewnieniem ze strony Wykonawcy konsultacji i pomocy dla użytkowników Systemu na miejscu w siedzibie Zamawiającego w okresie wdrożenia i w określonym zakresie ilościowym liczby roboczogodzin Strona 61 z 185

użytkownika lub uruchomienie systemu pomocy i / lub wcześniejsze niż zaplanowano w Harmonogramie Prac uruchomienie geoportalu edukacyjnego zapewniającego możliwości przeszkolenia użytkowników z zakresu aktualnie wdrażanych funkcji Systemu. Przyjmuje się, iż w trakcie eksploatacji nadzorowanej Wykonawca na bieżąco będzie usuwał pojawiające się usterki Systemu oraz zależnie od potrzeb będzie wprowadzał ewentualne zmiany w konfiguracji Systemu, zapewniając jego skalowalność adekwatnie do pojawiających się potrzeb. Poza powyższym, w ramach tego etapu prac, na podstawie dostarczonej przez Wykonawcę dokumentacji użytkownika oraz obowiązujących zarządzeń i procedur stanowiskowych objętych wdrożeniem, IP opracuje projekt zmian do procedur wewnętrznych Zamawiającego dostosowując je do uwarunkowań wynikających z zakresu i sposobu ich wsparcia dostarczonego przez funkcje Systemu. Ponadto, IP przy współudziale Wykonawcy będzie zobowiązany do przygotowania dokumentacji technicznej oraz wniosku zgłoszenia baz danych MSZ-KIIP do GIODO. 3.1.7 Etap VII Wdrożenie Systemu w pełnej skali Etap VII obejmuje wdrożenie Systemu w pełnej skali, co oznacza wdrożenie Systemu w zakresie rozwiązań aplikacyjnych dedykowanych dla użytkowników zewnętrznych, w tym w szczególności mieszkańców miasta i regionu Silesia. Proces wdrożenia tej części Systemu obejmować będzie taki sam pakiet działań jak dla wdrożenia pilotowego Systemu. Tym samym po zgłoszeniu gotowości Wykonawcy o dostępności rozwiązań aplikacyjnych, Wykonawca przeprowadzi szkolenia Zespołu Wdrożeniowego Zamawiającego. Następnie, razem z IP oraz Zamawiającym prowadzi testy akceptacyjne i wydajnościowe. I tak, po przeprowadzeniu testów w przypadku uzyskania przez Wykonawcę: negatywnej oceny wyników z testów akceptacyjnych (tj. poziom aspiracji wyników z testów okaże się niższy niż wskazany w Planie Testów), Wykonawca będzie zobowiązany zastosować się do rekomendacji Zamawiającego i przygotować nowa wersję Systemu pozbawioną zidentyfikowanych błędów, uwzględniając przy tym zalecenia / uwagi Zamawiającego, pozytywnej oceny wyników z p testów akceptacyjnych (tj. poziom aspiracji wyników z testów będzie równy lub wyższy niż założony w Planie Testów) Strony przystąpią do następnego zadania Strona 62 z 185

tj. przygotowania i uruchomiania tzw. eksploatacji nadzorowanej 15, przy czym bezwzględnym warunkiem uruchomienia eksploatacji nadzorowanej będzie dostępność systemu pomocy lub poprawne funkcjonowanie geoportalu edukacyjnego. Tak jak dla Etapu VI i w tym etapie w trakcie eksploatacji nadzorowanej Wykonawca na bieżąco będzie usuwał pojawiające się usterki Systemu oraz zależnie od potrzeb będzie wprowadzał ewentualne zmiany w konfiguracji Systemu, zapewniając jego skalowalność adekwatnie do pojawiających się potrzeb. Natomiast IP, jeżeli będzie to konieczne przygotuje: projekt zmian do procedur wewnętrznych Zamawiającego dostosowując je do uwarunkowań wynikających z zakresu i sposobu ich wsparcia dostarczonego przez funkcje Systemu dla obszaru zewnętrznego. dokumentację techniczną oraz wniosek zgłoszenia baz danych MSZ-KIIP do GIODO dla nowego obszaru przetwarzania danych osobowych. Ostatnimi zadaniami w ramach tego etapu będą: opracowanie dokumentacji powykonawczej, opracowanie elementów Polityki Bezpieczeństwa Informacji (dla zakresu systemu), dokonanie zgłoszenia do GIODO oraz przeprowadzenie Odbioru Końcowego. 3.2 Zamówienie nr 2: Świadczenie usług promocji W ramach tego zamówienia publicznego Wykonawca zapewni pakiet usług w zakresie kompleksowego realizowania zadania związanego z promocją projektu. Działania te będą prowadzone zgodnie z Rozporządzeniem Komisji (WE) nr 1828/2006 z dnia 8 grudnia 2006 r. ustanawiającym szczegółowe zasady wykonania rozporządzenia Rady (WE) nr 1083/2006 oraz Rozporządzenia (WE) nr 1080/2006 Parlamentu Europejskiego i Rady w sprawie Europejskiego Funduszu Rozwoju Regionalnego, a także Wytycznymi Ministra Rozwoju Regionalnego w zakresie informacji i promocji oraz wytycznymi IZ RPO WSL. Podstawą do realizowania poszczególnych świadczeń przez Wykonawcę będzie opracowany przez niego Plan Projektu uwzględniający między innymi kluczowe dwa obszary: 15 Jest to tzw. świadczenie asysty technicznej przez Wykonawcę mające na celu usuwanie na bieżąco identyfikowanych usterek Systemu włącznie z zapewnieniem ze strony Wykonawcy konsultacji i pomocy dla użytkowników Systemu na miejscu w siedzibie Zamawiającego w okresie wdrożenia i w określonym zakresie ilościowym liczby roboczogodzin Strona 63 z 185

1. zapewnienia informowania społeczeństwa o współfinansowaniu realizacji projektu przez Unię Europejską oraz o osiągniętych produktach i rezultatach projektu, zgodnie z wymogami Rozporządzenia Rady (WE) nr 1083/2006, Rozporządzenia Komisji (WE) nr 1828/2006 oraz wytycznymi krajowymi i IZ RPO WSL; 2. wypełniania obowiązków informacji i promocji w zakresie określonym we wniosku o dofinansowanie, co w szczególności dotyczy: tablic pamiątkowych; materiałów na potrzeby konferencji prasowych oraz materiałów prasowych, materiałów multimedialnych, broszur i ulotek; strony internetowej zawierającej informację o projekcie, konferencji prasowych, notatek prasowych oraz przygotowania materiałów do oznakowania różnego rodzaju urządzeń i sprzętów zakupionych w ramach projektu. Plan Promocji będzie obejmował również identyfikację i wybór określonych działań, które będą związane z wspieraniem procesu uświadamiania, a następnie utrwalania przekonania o korzyściach, jakie niesie ze sobą wdrożenie projektu. W tym zakresie z punktu widzenia realizacji celów projektu bardzo istotne będzie zorganizowanie konferencji podsumowującej wyniki przedmiotowego projektu, na którą zostaną zaproszone instytucje zainteresowane w przyszłości realizowaniem podobnych projektów lub zaangażowane już w tożsame przedsięwzięcia. Zaproszonym gościom z tych instytucji (np. jednostki organizacyjne administracji publicznej) zostaną przedstawione doświadczenia Zamawiającego oraz Inżyniera Projektu i głównego Wykonawcy MSZ-KIIP z realizacji przedmiotowego projektu. W tym celu przeprowadzone zostaną warsztaty tzw. dobrych praktyk, które poza prezentacją wyników zawierać będą również elementy dyskusji i doradztwa z zakresu problematyki przedmiotowego projektu a przede wszystkim ogólnych tez związanych z wdrożeniem rozwiązań typu egovernment. Działanie to zapewni wypełnienie zobowiązania Zamawiającego jako Beneficjenta projektu w zakresie związanym z osiągnięciem wskaźnika produktu pn. Liczba instytucji, które skorzystały z doradztwa w zakresie wdrażania systemu egovernment 16. Wszystkie działania związane ze świadczeniem usług promocji podzielono na trzy zadania: 16 Aby to skutecznie osiągnąć wskaźnik na konferencję należy zaprosić co najmniej 20 przedstawicieli różnych instytucji Strona 64 z 185

1. Usługi promocji w zakresie podstawowym związane z opracowaniem Planu Promocji, przeprowadzeniem konferencji prasowej dostawą materiałów promocyjnych (banery, flagi, etc), 2. Świadczenie działań promocyjnych zgodnie z Planem Promocji (przez okres realizacji projektu), 3. Przeprowadzenie konferencji / seminarium podsumowującego rezultaty projektu, w tym usługi doradztwa z zakresu e-govermment (zakres świadczenia wykonawcy usług promocji w tym zakresie dotyczy wyłącznie spraw organizacyjnych). 3.3 Zamówienie nr 3: Świadczenie usług Doradcy Technologicznego Świadczenie usług Doradcy Technologicznego to działania osoby prawnej lub fizycznej zapewniające Zamawiającemu usługi eksperckie na etapie implementacji i wdrożenia Systemu MSZ-KIIP. Zakres zadań Doradcy Technologicznego może być bardzo szeroki ale w szczególności powinien obejmować: 1. opiniowanie techniczne zastosowanych i opracowanych przez Wykonawcę rozwiązań, co obejmować może (jest wysoce wskazane) weryfikację oferty Wykonawcy, 2. opiniowanie dokumentacji projektowej, w tym: Dokumentacji Technicznej Implementacji Systemu, Opisu Procesu Wytwórczego, Planu Jakości, Planu i Projektu Testów oraz innych dokumentów, 3. opiniowanie pośrednich wyników prac Wykonawcy, 4. współudział w testach akceptacyjnych, w tym testach wydajnościowych, 5. udzielanie konsultacji, 6. udział w spotkaniach w roli doradcy Zamawiającego eksperta i / lub biegłego. Usługi Doradcy Technologicznego mogą być świadczone w trybie na żądanie lub w rozliczeniu ryczałtowym, jednak to drugie podejście może rodzić potencjalne ryzyko obniżenia jakości świadczonych usług. 3.4 Rekomendacja dotyczące wyboru trybu udzielenia zamówienia 3.4.1 Wybór trybu udzielenia zamówienia 3.4.1.1 Zamówienie nr 1 przetarg ograniczony Na gruncie Ustawy Prawo zamówień publicznych zasadą jest udzielanie zamówień w jednym z dwóch trybów podstawowych, nieograniczających konkurencji, czyli w trybie przetargu nieograniczonego i Strona 65 z 185

przetargu ograniczonego. Obydwa te tryby zakładają publiczne ogłoszenie o zamówieniu i w pełni równy dostęp dla każdego podmiotu, który spełnia warunki udziału w postępowaniu. Kluczowe dla realizacji projektu zamówienie nr 1 obejmuje dostawę infrastruktury technicznej oraz wdrożenie dedykowanego systemu informatycznego MSZ-KIIP i jest przedsięwzięciem złożonym wymagającym ze strony Wykonawcy: specjalistycznej wiedzy oraz doświadczenia we wdrażaniu systemów informatycznych określonej klasy (GIS) dla administracji publicznej, włącznie ze stosowaniem nowych technologii ICT np. integracji rozwiązań z elektronicznym obiegiem dokumentów, stosowaniem podpisu elektronicznego, integracją z platformą SEKAP i epuap, doświadczenia w prowadzeniu prac analityczno projektowych w zakresie projektowania oraz implementacji systemów informatycznych, znaczącej, mobilizacji zasobów osobowych i technicznych, doświadczenia w zarządzaniu projektami, w tym wykonanych tego typu zamówień dla administracji publicznej, posiadania zdolności organizacyjno technicznych i logistycznych do przeprowadzenia zamówienia w określonym czasie. Przy takim widzeniu zakresu ogólnych wymagań wobec wykonawcy zalecanym rozwiązaniem mającym na celu zminimalizowanie potencjalnych ryzyk w realizacji projektu 17 jest zastosowanie trybu: przetargu ograniczonego z wstępną selekcją Wykonawców na podstawie warunków dopuszczenia Wykonawców do postępowania przetargowego. Oczywiście powyższa rekomendacja nie wyklucza zastosowania trybu przetargu nieograniczonego. Jednak w pierwszym przypadku najpierw następuje wybór Wykonawców, przez ograniczenie grona potencjalnych Wykonawców do grupy spełniającej warunki dopuszczenia do przedmiotowego postępowania przetargowego z zachowaniem zasad uczciwej konkurencji i równego traktowania Wykonawców, a następnie wszyscy dopuszczeni do udziału w postępowaniu przetargowym Wykonawcy zostają zaproszeni do złożenia oferty. W przetargu nieograniczonym oba te kroki są połączone. 17 z punktu widzenia wyboru niewłaściwego Wykonawcy nie posiadającego oczekiwanych predyspozycji do jego wykonania Strona 66 z 185

W każdym z trybów podstawowych możemy stosować te same zasady selekcji definiując te same warunki dopuszczenia do przedmiotowego postępowania przetargowego oraz kryteria wyboru najkorzystniejszej oferty. Istotna różnica pojawia się w fazie składania oferty, gdzie dla trybu ograniczonego mamy wyłącznie grono wykonawców dopuszczonych do składania oferty, a dla przetargu nieograniczonego to grono jest nieokreślone, bowiem prawie każdy podmiot prawa handlowego może wykazać swój interes prawny i może być stroną w postępowaniu przetargowym. Drugą istotną różnicą jest czas realizacji postępowania przetargowego, który z uwagi na dwustopniowość trybu przetargu ograniczonego i możliwości ewentualnych odwołań jest tutaj zdecydowanie dłuższy niż dla trybu przetargu nieograniczonego. Jednak korzystnym aspektem użycia trybu przetargu ograniczonego jest zdecydowane ograniczenie liczby pytań i odwołań składanych przez wykonawców posiadających mniejsze doświadczenie w realizacji tego typu zamówień, co w przypadku tak złożonego przedsięwzięcia jak również opisu przedmiotu zamówienia (PTBS lub znacząca jego część 18 stanowić będzie załącznik do OPZ SIWZ) może mieć miejsce na dość szeroką skalę. Istotną wartością dla Zamawiającego w przypadku wyboru trybu przetargu ograniczonego jest jeszcze możliwość doprecyzowania Opisu Przedmiotu Zamówienia i wprowadzenia do niego pewnych korekt podczas toczącego się postępowania, bowiem SIWZ nie musi zostać przekazana Wykonawcom na etapie składania wniosków o dopuszczenie do postępowania przetargowego o udzielenie zamówienia publicznego lecz później, na etapie zaproszenia do złożenia oferty. Wówczas źródłem wiedzy dla Zamawiającego mogą być złożone przez Wykonawców wnioski i zawarte w nich dokumenty np. potwierdzające doświadczenie w realizacji tego typu lub podobnych przedsięwzięć. Na tej podstawie Zamawiający może wysunąć wnioski, iż np. pewne jego wymagania wobec przedmiotu zamówienia: są na tyle specyficzne, iż mogą nie znaleźć potwierdzenia w produktach i / lub usługach wykonawców, 18 Wyłączeniu mogą podlegać zapisy i rozdziały nie wnoszące żadnych treści do istoty i przedmiotu zamówienia tak jak niniejszy rozdział Strona 67 z 185

nie są konieczne dla osiągnięcia zakładanych celów a ich pominięcie lub korekta nie zmienia istoty przedmiotu zamówienia lecz wpłynie zdecydowanie na zmniejszenie ryzyka planowanego przedsięwzięcia. Reasumując należy zauważyć, iż zasadnicza, formalna różnica między przetargiem nieograniczonym a ograniczonym polega na tym, że w przetargu ograniczonym oferty mogą składać tylko ci wykonawcy, którzy zostali zaproszeni przez zamawiającego do składania ofert. Ograniczenie liczby potencjalnych wykonawców nie stanowi ograniczenia konkurencji lecz wiąże się ze specjalistycznym charakterem zamówienia, jednostkowym skomplikowanym charakterem procesu produkcji wyrobu lub wykonywanej usługi, niewielkim zapotrzebowaniem na te wyroby czy usługi. Wybór wykonawcy w trybie przetargu ograniczonego daje większą gwarancję, że Wykonawca, który będzie wykonywał dane zamówienie daje rękojmię świadczenia usług w tej specjalności, która ma dla Zamawiającego immanentne znaczenie. Tryb przetargu nieograniczonego takiej gwarancji nie daje. 3.4.1.2 Zamówienie nr 2 przetarg nieograniczony Zamówienie nr 2 na usługi promocji jest zamówieniem typowym i niespecjalistycznym. Usługi tego typu są dość powszechnie dostępne. Zatem, w tym przypadku rekomendowanym trybem udzielenia zamówienia publicznego jest przetarg nieograniczony. 3.4.1.3 Zamówienie nr 3 zapytanie ofertowe zgodnie z wymaganiami IZ RPO WSL Zamówienie nr 3 dotyczy wysoce specjalistycznych usług tzw. Doradcy Technologicznego. Zakres świadczenia usługi określony w opisie zamówienia wskazuje, iż nie są to usługi typowe i powszechnie dostępne. Z drugiej strony uwarunkowania realizacji projektu, w tym jego złożoność wymuszają na Zamawiającym prowadzenie wszelkich działań nie tylko z należytą starannością ale również w oparciu o rzetelną, praktyczną i weryfikowalną wiedzę techniczną, co odnosi się nie tylko do etapu wykonawczego ale przede wszystkim jest bardzo istotne na etapie wyboru najkorzystniejszej oferty Wykonawcy MSZ- KIIP, gdzie wszelkie działania Zamawiającego nie powinny budzić jakichkolwiek wątpliwości o dokonaniu nieprawidłowego, niezgodnego ze stanem faktycznym i kryteriami wyboru oferty. Przyjmując, iż cena nie będzie jednym kryterium wyboru najkorzystniejszej oferty wykonawcy MSZ-KIIP lecz pojawią się inne jeszcze kryteria odnoszące się np. do cech funkcjonalno technicznych oferowanego przez Wykonawcę Strona 68 z 185

rozwiązania wówczas na pewno pomocne będzie wsparcie Doradcy Technologicznego w rozstrzygnięciu zgodności oferty z wymaganiami Zamawiającego. Zatem, aby zapewnić prawidłowość procedury wyboru najkorzystniejszej oferty, jak również, aby zapewnić wysoką jakość prowadzonych w okresie późniejszym działań kontrolnych wskazane jest, aby Zamawiający dokonał wyboru Doradcy Technologicznego jeszcze przed uruchomieniem procedury przetargowej na zamówienie nr 1 lub w jej trakcie tak, aby etap oceny oferty Wykonawcy MSZ KIP prowadzić już razem z Doradcą Technologicznym w roli eksperta lub biegłego. Wybór Doradcy Technologicznego powinien być przeprowadzony z grupy wykonawców posiadających wysokie kompetencje i wiedzę z zakresu technologii GIS, posiadających doświadczenie z realizacji tego typu lub podobnych zamówień. Zalecane jest również, aby Zamawiający skierował zapytanie do wykonawców już sprawdzonych na rynku IT GIS posiadających stosowne referencje. W tej sytuacji tryb zapytania ofertowego (poza Ustawą PZP) jest tym bardziej rekomendowany z uwagi na możliwość dokonania selektywnego zaproszenia i skutecznego wyboru Wykonawców spełniających warunki podmiotowe dopuszczenia do postępowania. Powyższa rekomendacja jest zgodna z zapisami zawartymi we wniosku o dofinansowanie. Jednak w całej tej procedurze należy zwrócić uwagę, aby Zamawiający przestrzegał wytyczne i zalecenia IZ RPO WSL dotyczące udzielania zamówień, tym tych udzielanych poza Ustawą Prawo zamówień publicznych http://rpo.slaskie.pl/?grupa=1&art=1213871382&id_m=177 3.4.2 Komentarz ogólny dotyczący określenia warunków udziału w postępowaniu Poniższy komentarz ma charakter pomocniczy i jest uzupełnieniem przedstawionych wcześniej rekomendacji dot. trybu udzielenia danego zamówienia publicznego i ma służyć pomocą Zamawiającemu we właściwym określeniu i doborze warunków udziału dla wykonawców. Podstawowymi zasadami prawa zamówień publicznych jest zasada prowadzenia postępowania w sposób zapewniający zachowanie uczciwej konkurencji i równe traktowanie wykonawców, zakaz określania warunków udziału w postępowaniu oraz opisywania przedmiotu zamówienia w sposób, który mógłby utrudnić uczciwą konkurencję. Nieprzestrzeganie tych zasad przez zamawiających bardzo często Strona 69 z 185

jest przedmiotem protestów i odwołań wykonawców w tym zakresie ukształtowała się zatem pewna linia orzecznicza. Zgodnie z orzecznictwem Zespołu Arbitrów zamawiający mają możliwość w pewnym stopniu ograniczenia konkurencji przez sformułowanie warunków udziału w postępowaniu, jeśli jest to uzasadnione specyfiką zamawiającego lub też jego określonymi potrzebami. W konkretnym przypadku zamawiający może zgodnie z prawem zamówień publicznych ograniczyć konkurencję wykonawców poprzez następujące działania: 1. w warunkach udziału w postępowaniu określić, że wymaga od wykonawców doświadczenia we wdrożeniu określonego rodzaju systemu informatycznego, ponieważ wdrożenie takiego właśnie rodzaju systemu jest przedmiotem zamówienia, a wdrożenie innego rodzaju systemu nie gwarantuje należytego doświadczenia wykonawcy; istotne jest natomiast, by uzasadnienie wymogu posiadani doświadczenia we wdrożeniu oferowanych systemów było racjonalne. Zasadniczo nie będzie podstaw do takiego żądania, jeżeli zamawiający oczekiwałby rozwiązania nietypowego, dedykowanego wyłącznie dla siebie. Co do zasady, możliwe jest żądanie wykazania się wdrożeniem oferowanego rozwiązania zamawiający może, bowiem racjonalnie wykazywać, że chce zakupić produkt działający, sprawdzony i np. już serwisowany dla innych podmiotów, co daje mu pewną gwarancję, że nagle nie zostanie bez serwisu, gdy firma wycofa się z danego segmentu rynku. 2. w zakresie oceny spełniania warunków udziału w postępowaniu określić rodzaj dokumentów, które mają być przedłożone na potwierdzenie spełniania warunków udziału w postępowaniu (w odniesieniu do postępowań, w których na pierwszym etapie dokonuje się selekcji wykonawców, którzy zostaną dopuszczeni do składania ofert, np. w przetargu ograniczonym czy negocjacjach z ogłoszeniem). Dopuszczalne jest na przykład wymaganie zamawiającego, aby wykonawca posiadał doświadczenie we wdrożeniu określonego rodzaju oprogramowania, przy użyciu określonego rodzaju narzędzi, czy też w jednostkach o specyfice zbliżonej do danego zamawiającego (np. w jednostce, która przetwarza określoną ilość danych, czy też w jednostce, w której z wdrożonego systemu korzysta określona liczba użytkowników). Zgodnie z orzecznictwem nakaz zachowania uczciwej konkurencji i równego traktowania wykonawców nie może być utożsamiany z nakazem dopuszczania do udziału w postępowaniu wszystkich podmiotów, w tym takich, które w opinii zamawiającego nie dają gwarancji wykonania zamówienia w sposób należyty. Za wykonawców niezdolnych do należytego wykonania zamówienia zamawiający ma Strona 70 z 185

prawo uznać wykonawców, którzy nie wykażą się doświadczeniem we wdrożeniu kilku rozwiązań zbliżonych do rozwiązania, które jest przedmiotem prowadzonego postępowania. W orzecznictwie przyjmuje się, że żądanie wykazania się doświadczeniem przez wymaganie przedstawienia w ofercie nie jednej, lecz kilku referencji dotyczących wdrożenia rozwiązania o specyfice zbliżonej do przedmiotu zamówienia, nie musi oznaczać ograniczenia uczciwej konkurencji. Jak wynika z ugruntowanego poglądu doktryny, orzecznictwa oraz opinii zamieszczonych na stronach UZP, warunek udziału trudny do spełnienia nie jest sprzeczny z zasadą uczciwej konkurencji i równego traktowania wykonawców tylko z tego powodu, że jest trudny do spełnienia przez niektórych z nich. Aby stwierdzić, że dany warunek udziału narusza te zasady, wykonawca musiałby udowodnić, że spełnienie określonego warunku jest możliwe wyłącznie przez jednego wykonawcę. To zaś z reguły jest trudne do udowodnienia, ponieważ zamawiający zazwyczaj będzie w stanie wskazać podmioty, które funkcjonują na rynku europejskim i dysponują wymaganym przez niego doświadczeniem. Jak wskazywano w orzecznictwie, jeśli przedmiotem zamówienia są usługi lub dostawy przekraczające tzw. progi unijne, to zamówienie takie jest przedmiotem zainteresowania wykonawców z otwartego rynku europejskiego, a ponadto z krajów objętych porozumieniem w sprawie zamówień rządowych. W takiej sytuacji zasadę uczciwego traktowania wykonawców w zakresie wymaganego doświadczenia należy rozpatrywać z uwzględnieniem podmiotów funkcjonujących na tych rynkach, a nie wyłącznie w skali rynku polskiego. 3.5 Osiągniecie wskaźników produktów Wskaźniki produktów oraz rezultatu zostaną osiągnięte w ramach realizacji zamówienia nr 1 oraz powiązanych z tym działań w ramach zamówienia nr 2 na Usługi Promocji (dotyczący to organizacji konferencji zamykającej projekt). Dla każdego wskaźnika produktu podano w poniższej tabeli sposób jego spełnienia oraz źródło weryfikacji, w tym konieczne działania ze strony i / lub Wykonawcy, Inżyniera Projektu oraz Zamawiającego wiążące się z jego osiągnięciem. Lista wskaźników jest zgodna co do ilości oraz kolejności z listą zawartą we wniosku aplikacyjnym będącym załącznikiem do Aneksem nr 2 do umowy o dofinansowanie z dnia 19 września 2012 roku. Strona 71 z 185

3.5.1 MSZ-KIIP Wskaźniki produktów Lp. Nazwa wskaźnika Źródło weryfikacji 1. Liczba uruchomionych serwerów Projekt techniczny, protokół zdawczo - odbiorczy Wartość / jednostka 2 / szt. Sposób spełnienia / Uwagi Planowana wstępnie w Projekcie Generalnym infrastruktura sprzętowa na potrzeby MSZ-KIIP jest niewystarczająca. Przyjmując założenia obecnej polityki bezpieczeństwa określonej przez Wydział Informatyki infrastruktura ta powinna zostać zdublowana i zlokalizowana odpowiednio w serwerowni podstawowej oraz zapasowej. Przeprowadzone szacunki obciążenia poszczególnych serwerów usług MSZ- KIIP oraz założenie dotyczące funkcjonowania bazy danych w klastrze bezpieczeństwa wymagają zastosowania do budowy Systemu co najmniej 4 serwerów sprzętowych a w przypadku ich zdublowania 8 serwerów. W takim przypadku konieczne jest uzyskanie zgody IZ RPO WSL na wprowadzenie stosowanych zmian do kategorii wydatku nr 7 zakup sprzętu. Obecny opis infrastruktury sprzętowej MSZ-KIIP potwierdza osiągnięcie jak również przekroczenie poziomu aspiracji dla przedmiotowego wskaźnika wymagana korekta wskaźnika za zgodą IZ RPO WSL. Wskaźnik zostanie osiągnięty poprzez zapewnienie dostawy określonej liczby serwerów (2 sztuki lub więcej zależnie od zakresu zaakceptowanej zamiany przez IŻ RPO WSL) w zamówieniu nr 1, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy wymagań w zakresie dostawy takiej ilości sprzętu (serwerów) a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Liczba aplikacji MSZ-KIIP została zdefiniowana w Projekcie Generalnym i w takim zakresie obowiązuje również w Projekcie Technicznym Budowy Systemu (PTBS) i obejmuje następujące aplikacje: 2. Liczba uruchomionych aplikacji Projekt techniczny, protokół zdawczo - odbiorczy 5 / szt. 1. Udostępnianie i obsługa geodezyjnych referencyjnych baz danych 2. Zarządzanie kryzysowe i bezpieczeństwo, infrastruktura krytyczna 3. Monitoring i planowanie przestrzenne, rewitalizacja i inwestycje 4. Zarządzanie nieruchomościami 5. Zarządzanie i ochrona środowiska Wskaźnik zostanie osiągnięty poprzez zapewnienie dostawy / implementacji określonej powyżej liczby, nazwanych aplikacji (5 sztuk) w zamówieniu nr 1, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy, wymagania w zakresie dostawy / implementacji takich aplikacji a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w Strona 72 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka SIWZ. Sposób spełnienia / Uwagi Infrastruktura techniczna MS KIIP zawierać będzie dwa wydzielone systemy archiwizacji odpowiedzialne za tworzenie i odtwarzanie kopii MSZ-KIIP. Infrastrukturę tę stanowić będzie: - biblioteka taśmowa, - macierz dyskowa (2 szt.) - serwery przeznaczone do zarządzania oraz realizowania usługi systemowej backup (serwery wirtualne) 3. Liczba uruchomionych systemów archiwizacji danych Projekt techniczny, protokół zdawczo - odbiorczy 2 / szt. - oprogramowania bazodanowe z funkcjami tworzenia kopii zapasowej (tryb pracy na zimno ) oraz z funkcją kopii toczoną podczas pracy on-line - dedykowane specjalistyczne oprogramowanie narzędziowe do tworzenia kopii (obrazu) bazy danych. Implementacja MSZ KIIP w zakresie określonego powyżej zapewnia osiągniecie wskaźnika produktu. Wskaźnik zostanie osiągnięty poprzez zapewnienie dostawy oraz uruchomienie systemów archiwizacji bazujących na wskazanej powyżej infrastrukturze sprzętowej i programowej w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne wymagania realizacji dostawy oraz uruchomienia systemów archiwizacji a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Rejestry publiczne udostępniane są przez usługi publiczne, tym samym (odpowiednio zgodnie z powyższym) lista rejestrów publicznych objętych przedmiotowym wskaźnikiem zostanie określona podczas prac implementacyjnych Wykonawcy MSZ-KIIP. Rejestry publiczne zostały wskazane jako produkty w Załączniku nr 3 do PTBS Usługi aplikacyjne, aktorzy. 4. Liczba rejestrów publicznych udostępnionych online Projekt techniczny, protokół zdawczo - odbiorczy 31 / szt. Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług kategorii 1 w ramach, których udostępniane będą on line treści z rejestrów publicznych wyspecyfikowanych w Załączniku nr 3 do PTBS, co powinno być zapewnione jako wymaganie wykonania usługi w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi oraz uruchomienia serwisów on-line dla 31 rejestrów publicznych a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Strona 73 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji 5. Liczba uruchomionych usług online na poziomie 1 - Informacja Projekt techniczny 19, protokół zdawczo - odbiorczy Wartość / jednostka 16 /szt. Sposób spełnienia / Uwagi Usługi poziomu 1 informacja będą dostępne w poszczególnych geoportalach jako dedykowane pogrupowane serwisy tematyczne. Rozplanowanie poszczególnych serwisów grupujących określone usługi aplikacyjne w geoportalach, w tym zdefiniowanie kompozycji mapowych wraz z wydzieleniem poszczególnych funkcji (widżetów) nastąpi podczas prac implementacyjnych Wykonawcy MSZ-KIIP. Łącznie MSZ-KIIP nie będzie zawierał więcej niż 16 tak wydzielonych serwisów tematycznych, czyli usług poziomu 1. Przykładowo w zakresie planowania można wyodrębnić jeden serwis Rejestr planów lub wydzielić kilka mniejszych osobna mpzp i studiu wykonalności oraz związane z tym opracowania fizjograficzne. Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług kategorii 1 w poszczególnych geoportalach, co powinno być zapewnione jako wymaganie wykonania usługi w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi oraz uruchomienia 16 usług kategorii 1 a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Usługi poziomu 4 transakcja zostaną zaimplementowane w ramach usługi AS.18 Usługa świadczenia usług publicznych Załącznik nr 3 Usługi aplikacyjne, aktorzy. 6. Liczba uruchomionych usług online na poziomie 4 Transakcja Projekt techniczny, protokół zdawczo - odbiorczy 15 / szt. Ostateczna lista usług 4 kategorii niesprzeczna z listą uruchomionych usług w systemie SEKAP zostanie określona i zaimplementowana przez Wykonawcę MSZ-KIIP. Wstępna lista został określona w Rozdz. 2.1.5. Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług kategorii 4 w usłudze AS. 18, co powinno być zapewnione jako wymaganie wykonania usługi w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi oraz uruchomienia 15 takich usług kategorii 4 a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego 19 Należy zauważyć, iż pojecie projektu technicznego jest szerokie i nie obejmuje wyłącznie obecnego dokutemu tj. Projektu Technicznego Budowy Systemu, który jest uszczegółowieniem koncepcji MSZ-KIIP ale w kontekście propozycji IP, co do sposobu realizacji projektu oraz prowadzenia prac w zakresie budowy i wdrożenia MSZ-KIIP obejmować będzie również Dokumentację Techniczną Implementacji Systemu opracowaną przez Wykonawcę MSZ-KIIP Strona 74 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi zobowiązania zawartego w SIWZ. Liczba portali MSZ-KIIP została zdefiniowana w Projekcie Generalnym i w takim zakresie obowiązuje również w Projekcie Technicznym Budowy Systemu (PTBS) oraz obejmuje następujące portale: 1.portal obsługi obywatela 2. geoportal inwestycji 7. Liczba uruchomionych portali Projekt techniczny, protokół zdawczo - odbiorczy 5 / szt. 3. geoportal sportu, promocji i turystyki 4. geoportal edukacyjny 5 geoportal metadanych Wskaźnik zostanie osiągnięty poprzez zapewnienie dostawy / implementacji określonej powyżej liczby, nazwanych portali (5 sztuk) w zamówieniu nr 1, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy, wymagania w zakresie dostawy / implementacji takich portali a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. W ramach dostawy infrastruktury technicznej MSZ-KIIP dostarczone zostaną dwie licencje serwerowe programu antywirusowego. 8. Liczba wdrożonych programów antywirusowych Projekt techniczny, protokół zdawczo - odbiorczy 2 / szt. Wskaźnik zostanie osiągnięty poprzez zapewnienie dostawy oraz uruchomienia dwóch programów antywirusowych w zamówieniu nr 1, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy, wymagania w zakresie dostawy oraz uruchomienia takich programów a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. 3.5.2 MSZ-KIIP Wskaźniki rezultatu Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi 1. Ilość jednostek Projekt techniczny, naukowych protokół zdawczo - korzystających z odbiorczy utworzonych aplikacji 5 / szt. W projekcie technicznym (PTBS): 1. wyróżniono grupę usług systemowych monitorowania ruchu sieciowego węzła oraz wizualizacji statystyk węzła: AS.85 oraz AS.86, 2. w Złączniku nr 3 do PTBS - Usługi aplikacyjne, aktorzy wyróżniono użytkowników systemów będących pracownikami jednostek naukowych, 3. zapewniono usługi zarządzania tożsamością AS 87, powyższe w połączeniu z planowymi przez Miasto Katowice działaniami organizacyjnymi związanymi z nawiązaniem współpracy Miasta z jednostkami naukowymi takim jak np. Uniwersytet Śląski, czy też Politechnika Śląska, daje Strona 75 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi podstawę do zdefiniowania nazwanej grupy użytkowników w MSZ-KIIP o określonych, szerszych uprawnieniach niż dostępne dla użytkownika publicznego, co w konsekwencji pozwoli na monitorowanie działań takiej grupy użytkowników na poziomie usług AS.85 As.86 podczas funkcjonowania Systemu. Zaprojektowane, opisane w ramach niniejszego projektu technicznego rozwiązanie zapewniające minimalny poziom gotowości do świadczenia tego typu usługi dla co najmniej 5 grup tego typu użytkowników, potwierdza przygotowanie MSZ-KIIP do świadczenia usługi na rzecz jednostek naukowych. Rozwiązanie zapewnia technicznie możliwość osiągnięcia wyższego poziomu aspiracji wskaźnika. Zakłada się, że nie nastąpi wysycenie zasobów technicznych na poziomie wartości technicznej równiej 5 jednostek naukowych. Powyższe potwierdza osiągniecie wskaźnika na etapie obecnych prac projektowych. Sposób spełnienia jak powyżej poprzez wyróżnienie określonej grupy użytkowników MSZ-KIIP jak również poprzez wskazanie jednostek organizacyjnych Miasta Katowice, które uzyskają dostęp do MSZ-KIIP na prawach użytkownika wewnętrznego. 2. Ilość jednostek Projekt techniczny, sektora publicznego protokół zdawczo - korzystających z odbiorczy utworzonych aplikacji 20 / szt. Zaprojektowane, opisane w ramach niniejszego projektu technicznego rozwiązanie zapewniające minimalny poziom gotowości do świadczenia tego typu usługi dla co najmniej 20 grup tego typu użytkowników, potwierdza przygotowanie MSZ-KIIP do świadczenia usługi na rzecz jednostek sektora publicznego. Rozwiązanie zapewnia technicznie możliwość osiągnięcia wyższego poziomu aspiracji wskaźnika. Zakłada się, że nie nastąpi wysycenie zasobów technicznych na poziomie wartości technicznej równiej 20 jednostek sektora publicznego. Powyższe potwierdza osiągniecie wskaźnika rezultatu Tematycznie geoportal inwestycje jest portalem najbardziej interesującym grupę użytkowników jakim są przedsiębiorcy. 3. Liczba przedsiębiorstw korzystających z Dane z logowań udostępnionych rejestrów publicznych 1 200 / szt. Na etapie dostępu do danych ww. geoportalu MSZ KIIP zawierać będzie pytanie uwierzytelniające osobę korzystającą z MSZ-KIIP czy jest przedstawicielem / pracownikiem przedsiębiorstwa (firmy). Uzyskana odpowiedź w połączeniu z danymi usług systemowych monitorowania ruchu sieciowego węzła oraz wizualizacji statystyk węzła: AS.85 oraz AS.86 umożliwi wygenerowanie raportu z logowań dla takiej grupy użytkowników Systemu. Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług monitorowania jako wymagania w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi a na etapie Strona 76 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Powyższe potwierdza możliwość techniczną osiągnięcia wskaźnika rezultatu na etapie realizacji zamówienia nr 1. Usługi systemowe monitorowania ruchu sieciowego węzła oraz wizualizacji statystyk węzła: AS.85 oraz AS.86, umożliwią wygenerowanie raportu z logowań dotyczące liczby osób korzystających z uruchomionych usług online 4 geoportali. 4. Liczna użytkowników korzystających miesięcznie z Dane z logowań uruchomionych usług online 210 / osoby Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług monitorowania jako wymagania w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Powyższe potwierdza możliwość osiągnięcia wskaźnika rezultatu na etapie realizacji zamówienia nr 1. 5. Liczba obywateli korzystających z Dane z logowań udostępnionych rejestrów publicznych 15 000 / osoby Lista rejestrów publicznych została określona w Załączniku nr 1 Wykaz usług i geoportali oraz w Załączniku nr 3 Usługi aplikacyjne, aktorzy. Na podstawie reguł monitorowania usług systemowych ruchu sieciowego węzła oraz wizualizacji statystyk węzła: AS.85 oraz AS.86 odnoszących się do usług publicznych udostępniających dane z rejestrów publicznych możliwe będzie wygenerowanie raportu z logowań obejmującego liczbę osób korzystających z danych z rejestrów publicznych. Obecnie, zaprojektowane, opisane w ramach projektu technicznego rozwiązanie potwierdza przygotowanie MSZ- KIIP do świadczenia tego typu usług oraz możliwości osiągnięcia zakładanego wskaźnika. Wskaźnik zostanie osiągnięty poprzez zapewnienie implementacji usług monitorowania jako wymagania w zakresie implementacji systemu MSZ KIIP w zamówieniu nr 1, co oznacza, iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy realizacji takiej usługi a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Powyższe potwierdza możliwość osiągnięcia wskaźnika rezultatu na etapie realizacji zamówienia nr 1. 6. Ilość procedur wewnętrznych realizowanych w oparciu o system GIS Projekt techniczny, protokół zdawczo - odbiorczy 37 / szt. (wartość bazowa 10) Załącznik nr 2 Opis procesów wskazuje procedury wewnętrzne realizowane w oparciu o system GIS, w tym 27 procedur wspieranych przez MSZ KIIP. Zaprojektowane, opisane w ramach niniejszego projektu technicznego rozwiązanie zapewniające implementację Strona 77 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi wsparcia technicznego po stronie MSZ KIIP dla 27 procedur administracyjnych poprzez budowę rozwiązań w zakresie e- usług, integrację z innymi systemami informatycznymi Zamawiającego (UMK) oraz wsparcie tychże procedur rozwiązaniami technicznymi dla wybranych kroków / części procedur, potwierdza przygotowanie MSZ-KIIP do wsparcia ww. liczby procedur na tym etapie realizacji projektu. Powyższe potwierdza osiągniecie wskaźnika rezultatu na tym etapie realizacji projektu. 3.5.3 MSZ-KIIP Wskaźniki produktu dot. szkoleń (cross-financing) Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi Planowany zakres prac dla Wykonawcy MSZ-KIIP zawiera zobowiązanie przeszkolenia 320 pracowników Zamawiającego z zakresu systemu MSZ-KIIP, który jest systemem klasy egovernment. 1. Liczba pracowników przeszkolonych w zakresie obsługi systemu egovernment Protokół ze szkolenia lista obecności 320 / osoby Wykonanie usługi w zakresie przedstawionym powyżej potwierdzi osiągniecie wskaźnika produktu. Wskaźnik zostanie osiągnięty poprzez zapewnienie realizacji usługi szkolenia 320 pracowników w zamówieniu nr 1, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy, wymagania dotyczące przeszklenia takiej liczby pracowników Zamawiającego a na etapie wykonania zamówienia IP razem z Zamawiającym musi wyegzekwować od Wykonawcy spełnienie przedmiotowego zobowiązania zawartego w SIWZ. Szkolenia powinny być zakończone podpisaniem protokołu odbioru z imienną listą przeszkolonych osób. 2. Liczba instytucji, które skorzystały z Protokół ze szkolenia doradztwa w zakresie lista obecności wdrażania systemu egovernment 20 / szt. Planowany zakres prac dla Wykonawcy MSZ-KIIP oraz wykonawcy usług promocji obejmuje zorganizowanie i przeprowadzenie konferencji zamykającej projekt, na której przeprowadzone zostaną warsztaty w formie prezentacji / szkolenia oraz dyskusji problemowej, w ramach której Wykonawca podzieli się swoimi doświadczeniami z realizacji projektu MSZ-KIIP (formuła dobrych praktyk ). Usługi doradztwa obejmą 20 instytucji, w tym w szczególności podmioty administracji publicznej. zainteresowane realizacją projektów typu egovernmet. Wskaźnik zostanie osiągnięty poprzez: a) zapewnienie realizacji wykonania usługi warsztatów dla nie mniej niż 40-50 osób z co najmniej 20 zaproszonych instytucji ( nie jest wymagana umowa ani list intencyjny lecz wymagane jest potwierdzenie obecności, tak aby Strona 78 z 185

Lp. Nazwa wskaźnika Źródło weryfikacji Wartość / jednostka Sposób spełnienia / Uwagi zapewnić w 100% osiągnięcie zakładanej wartości wskaźnika), b) grono podmiotów / instytucji mogą stanowić instytucje zainteresowane dostępem do danych w zakresie szerszym niż publiczny oferowany przez UMK w MSZ KIIP lub planowanych do wdrożenia w ramach przyszłej oferty MSZ KIIP związanej np. z budowaniem nowych usług i produktów w ramach rozwoju MSZ KIIP w obszarze infrastruktury branżowej oraz GESUT dla jednostek branżowych prowadzących branżową ewidencję sieci uzbrojenia terenu c) zakres zobowiązań związanych z przeprowadzeniem warsztatów powinien zostać zawarty w zobowiązaniach wykonawcy zamówienia nr 1 oraz nr 2, co oznacza iż Opis Przedmiotu Zamówienia do SIWZ musi zawierać stosowne zapisy, wymagania dotyczące realizacji takiego świadczenia tj. odpowiednio dal zamówienia nr 1 przeprowadzenia warsztatów a dla zamówienia nr 2 organizacji konferencji a na etapie wykonania każdego z ww. zamówień IP razem z Zamawiającym musi wyegzekwować od Wykonawców spełnienie przedmiotowych zobowiązań zawartych w SIWZ. Warsztaty powinny być zakończone podpisaniem imiennej listy osób w nich uczestniczących. 3.6 Ogólny harmonogram realizacji Harmonogram Prac Poniżej przedstawiono projekt Harmonogramu Prac na lata 2012-2014. Wprowadzenia jeszcze większego uszczegółowienia w zakresie interakcji pomiędzy Stronami jest mało zasadne metodycznie jak również niemożliwie, gdyż na obecnym etapie prac nie został zatwierdzony przez Zamawiającego (UMK) model zarządzania i monitorowania projektu, będący przedmiotem propozycji ze strony IP. Strona 79 z 185

Rysunek 10 Szczegółowy harmonogram Gantta cz. 1 Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 80 z 185

Rysunek 11 Szczegółowy harmonogram Gantta cz. 2 Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 81 z 185

Rysunek 12 Szczegółowy harmonogram Gantta cz. 3 Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 82 z 185

Rysunek 13 Szczegółowy harmonogram Gantta cz. 4 Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 83 z 185

Rysunek 14 Szczegółowy harmonogram Gantta cz. 5 Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 84 z 185

Rysunek 15 Szczegółowy harmonogram Gantta cz. 6 Rysunek 16 Oznaczenia symbole schematu Gantta Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007 2013 Strona 85 z 185

4 Wnioski Przeprowadzone prace analityczno projektowe wskazują na następujące wnioski: 1. Konieczne jest zapewnienie zgody IZ RPO WSL na przedłużenie terminu realizacji projektu do końca grudnia 2014 roku (opcja styczeń 2015 rok), w tym zgody na zmianę wartości wskaźnika Liczba uruchomionych serwerów z 2 serwerów sprzętowych na 8; 2. Przeprowadzone szacunki zakupu infrastruktury sprzętowej i systemowej przy założeniu 3 letniej gwarancji potwierdzają zakładany w projekcie poziom budżetu w kategorii wydatku nr 7 zakup sprzętu, dotyczy to: 2 macierzy dyskowych po 20 TB, 8 serwerów sprzętowych (blade) w układzie 2x 4 serwery, jednej biblioteki taśmowej (2xLOT5) oraz 2 stacji graficznych jak również koniecznego oprogramowanie systemowego, narzędziowego i bazodanowego (układ klastra pasive active ). a. Powyższe w warunkach dość silnej konkurencji na rynku IT nie wyklucza możliwości zapewnienia dłuższego (zaplanowanego w studium wykonalności) 5 letniej okresu gwarancyjnego na System, w tym na infrastrukturę sprzętową i systemową. 3. Wskazanie przez Zamawiającego możliwości wykorzystania w realizacji projektu licencji oprogramowania ESRI Inc. dostępnej w formule umowy korporacyjnej wymaga opracowania i wydania odrębnej opinii prawnej, czy taka decyzja, uzasadniona jak najbardziej ekonomicznie, nie spowoduje nieporównywalności ofert wykonawców. To, czy będzie to miało miejsce istotnie zależeć będzie od tego w jaki sposób dokona się opisu przedmiotu zamówienia. W opinii IP, jeżeli zamówienie zostanie zdefiniowane jako usługa implementacji i wdrożenia systemu MSZ KIIP w środowisku technologicznym produktowym ESRI Inc., wówczas nie powinno wystąpić tego typu zagrożenie. W przeciwnym razie, wykonawcy stosujący inną technologię mogą wskazać istotne preferencje i korzyści płynące z tej umowy na rzecz ich konkurentów stosujących technologię ESRI Inc. Strona 86 z 185

5 Dodatek nr 1 Dyskusja nt. umiejscowienia MSZ-KIIP w Infrastrukturze Informacji Przestrzennej (IIP) 5.1 Wprowadzenie Celem niniejszego, wydzielonego opracowania jest przekrojowe, wstępne zaprezentowanie istotnych zagadnień oraz wymagań, jakie powinna spełniać Infrastruktura Informacji Przestrzennej Miasta Katowice tak, aby zapewniała wypełnienie ustawowych obowiązków nałożonych na Prezydenta Miasta Katowice przez Ustawę o infrastrukturze informacji przestrzennej w ramach Krajowej Infrastruktury Informacji Przestrzennej (KIIP); zgodnie z wymaganiami określonymi przez szczegółowe przepisy ustawodawstwa krajowego oraz Dyrektywę INSPIRE. 5.1.1 Dokumenty normatywne W trakcie przeprowadzonej dyskusji wykorzystano następujące międzynarodowe normy, standardy i wytyczne techniczne: - ISO 19115 : 2003, Geographic information Metadata; - ISO 19115/Cor.1:2006, Geographic information Metadata, Technical Corrigendum 1; - ISO 19119:2005, Geographic information Services; - ISO 19119:2005 PDAM 1, Geographic information Services; - ISO/TS 19139:2006, Geographic information - Metadata - Implementation specification; - OGC 07-006, OGC CSW, OGC Catalogue Services Specification, version 2.0.2 (Corrigendum Release 2); - OGC 07-045, CSW ISO AP, OGC Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile for CSW 2.0, version 1.0.0 (2007); - INSPIRE, INS NS, ROZPORZĄDZENIE KOMISJI (WE) NR 976/2009 z dnia 19 października 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady Europejskiej w zakresie usług sieciowych; - INSPIRE, INS NS DS, Technical Guidance for INSPIRE Discovery Services v3.0 (2011-03-18); - INSPIRE, INS NS VS, Technical Guidance for INSPIRE View Services v3.0 (2011-03-21); Strona 87 z 185

- INSPIRE, INS MD, ROZPORZĄDZENIE KOMISJI (WE) NR 1205/2008 z dnia 3 grudnia 2008 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady Europejskiej w zakresie metadanych; - INSPIRE, INS MD IMPL, INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, v1.2 (2010-06-16); - Wytyczne GUGiK, Wytyczne do przygotowania metadanych w zakresie działek ewidencyjnych, Warszawa, wrzesień 2010 r; - INSPIRE, INS DS, ROZPORZĄDZENIE KOMISJI (UE) NR 1089/2010 z dnia 23 listopada 2010 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady Europejskiej Europejskiej w zakresie interoperacyjności zbiorów i usług danych przestrzennych; - INSPIRE, INS DAT, Definition of Annex Themes and Scope, v3.0 (2008-03-18). 5.2 Uwarunkowania prawne 5.2.1 Dyrektywa INSPIRE Podstawę prawną dla procesu tworzenia Infrastruktury Informacji Przestrzennej w Europie stanowi dyrektywa INSPIRE, która weszła w życie 15 maja 2007 roku. Dyrektywa ta określa działania, które powinny docelowo zapewnić powszechną dostępność informacji przestrzennej w Unii Europejskiej, uwzględniając przy tym, w niezbędnym zakresie, prawa własności intelektualnej oraz określając przypadki dopuszczalnego ograniczania dostępu do informacji (Janssen, Dumortier 2007). Zasadniczym celem dyrektywy INSPIRE jest rozwiązanie problemów dotyczących dostępności, elektronicznej wymiany oraz wykorzystania rozproszonych zasobów cyfrowych danych przestrzennych na różnych poziomach administracji publicznej. Ułatwienie wymiany danych o przestrzeni pomiędzy różnymi szczeblami władz w państwach członkowskich, w tym także pomiędzy państwami oraz służbami Wspólnoty Europejskiej, jest kluczową kwestią, aby osiągnąć optymalizację formułowania i wdrażania przez Wspólnotę działań, głównie w zakresie monitorowania, oceny i poprawy środowiska naturalnego. W tym kontekście należy zwrócić uwagę, iż dyrektywa INSPIRE uzupełnia i precyzuje cele ustalone we wcześniejszej dyrektywie Parlamentu Europejskiego i Rady Europejskiej ustanawiającej przepisy ogólne w sprawie ponownego wykorzystywania informacji sektora publicznego (dyrektywa re-use ). Osiągnięcie powyższych celów jest uzależnione od budowy europejskiej infrastruktury informacji przestrzennej, o której mowa w dyrektywie INSPIRE. Infrastruktura ta nie stanowi jednak odrębnej Strona 88 z 185

inwestycji. Tekst dyrektywy uwzględnia różnorodność istniejących już w państwach członkowskich systemów informacyjnych, baz danych oraz struktur organizacyjnych i stwarza ogólne ramy, umożliwiające współdziałanie obecnych technologii, tworząc infrastrukturę dla informacji przestrzennej we Wspólnocie Europejskiej. Wspólna europejska infrastruktura ma w rezultacie zaistnieć poprzez integrację obecnie już powstających, a w przyszłości dalej rozwijanych, krajowych infrastruktur wszystkich państw członkowskich Unii Europejskiej. Elementem zapewniającym kompatybilność niezależnie powstających krajowych infrastruktur jest ich interoperacyjność, czyli możliwość wspólnego łączenia zbiorów i usług danych przestrzennych zgodnie z ustalonymi organizacyjno-technicznymi aspektami współdziałania systemów informatycznych. 5.2.2 Ustawa o Infrastrukturze Informacji Przestrzennej W dniu 4 marca 2010 została przyjęta przez Sejm Rzeczypospolitej Polskiej (RP) ustawa o infrastrukturze informacji przestrzennej będąca transpozycją dyrektywy INSPIRE na grunt prawa polskiego. Zgodnie z wymogami tej dyrektywy nakłada ona na ograny administracji, które prowadzą rejestry publiczne, zawierające zbiory danych przestrzennych, obowiązek podjęcia działań o charakterze technicznym i organizacyjnym w celu doprowadzenia do wzajemnej spójności tych zbiorów (harmonizacja) oraz ich przystosowania do wspólnego łączenia i wykorzystania (interoperacyjność). Zgodnie z zapisami ustawy przez harmonizację zbiorów danych przestrzennych rozumie się działania o charakterze prawnym, technicznym i organizacyjnym, mające na celu doprowadzenie do wzajemnej spójności zbiorów danych przestrzennych oraz ich przystosowanie do wspólnego i łącznego wykorzystywania. Natomiast, interoperacyjność zbiorów i usług danych przestrzennych jest rozumiana jako możliwość łączenia zbiorów danych przestrzennych oraz zapewnienie współdziałania usług danych przestrzennych bez powtarzalnej interwencji manualnej, w taki sposób, aby wynik był spójny, a wartość dodana zbiorów i usług danych przestrzennych została zwiększona. Zgodnie z przedmiotową ustawą, krajowa infrastruktura informacji przestrzennej obejmuje opisane metadanymi zbiory danych przestrzennych lub dane z nim powiązane, odnoszące się do terytorium Rzeczypospolitej Polskiej, występujące w postaci elektronicznej, utrzymywane przez: organ administracji lub w jego imieniu, które zgodnie z zakresem kompetencji tego organu są tworzone, aktualizowane i udostępniane oraz odnoszą się do jednego z tematów wymienionych w załączniku do ustawy. Strona 89 z 185

Dodatkowo powyższa ustawa, zgodnie z zapisami dyrektywy INSPIRE, pozwala na włączenie do infrastruktury zbiorów danych przestrzennych prowadzonych przez osobę fizyczną, osobę prawną lub jednostkę organizacyjną nieposiadającą osobowości prawnej, niebędącą organem administracji. Uczestnictwo w krajowej infrastrukturze informacji przestrzennej dla organu administracji nie jest dobrowolne. Zgodnie z ustawą, jeżeli w zakresie zadań ustawowych danego organu administracji publicznej leży prowadzenie rejestru publicznego zawierającego zbiory danych przestrzennych związane z wymienionymi w załączniku do ustawy tematami danych przestrzennych, to jest on zobowiązany do opisania zbiorów metadanymi oraz udostępnienia informacji w nich zawartych za pośrednictwem sieci usług danych przestrzennych, do których zalicza się usługi: 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. Należy zaznaczyć, iż tematyka zbiorów danych przestrzennych w ramach infrastruktury informacji przestrzennej obejmująca tematy danych przestrzennych wymienione w załączniku do ustawy jest na tyle szeroka, że ustawodawca dopuścił wydzielenie szeregu mniejszych infrastruktur dziedzinowych (potocznie zwanych dziedzinowymi, branżowymi lub resortowymi) ustanawiając dla nich odpowiednie organy wiodące odpowiedzialne za organizację, koordynację i monitoring działań związanych z tworzeniem, utrzymywaniem i rozwijaniem infrastruktury, w zakresie przyporządkowanych im tematów danych przestrzennych, mając w szczególności na względzie zapewnienie zgodności tych działań (w tym wprowadzanych rozwiązań technicznych), z przepisami dotyczącymi infrastruktury informacji przestrzennej. Tworzone w ramach krajowej IIP infrastruktury dziedzinowe mogą mieć charakter krajowy, regionalny lub lokalny, jednak warunkiem koniecznym do ich funkcjonowania jest zapewnienie ich interoperacyjności i zgodności z przepisami wykonawczymi do dyrektywy INSPIRE oraz Strona 90 z 185

ustawy o infrastrukturze informacji przestrzennej. Docelowo, infrastruktura informacji przestrzennej w Polsce będzie miała charakter interdyscyplinarny, międzyresortowy oraz wielopodmiotowy i wielotematyczny. 5.3 Interoperacyjność zbiorów danych i usług danych przestrzennych Interoperacyjność jest istotą infrastruktury informacji przestrzennej. Możliwość łączenia zbiorów danych przestrzennych, gromadzonych przez różne podmioty oraz interakcji usług sieciowych związanych z tymi zbiorami, a także wspólne korzystanie przez organy administracji ze zbiorów i usług danych przestrzennych w znacznej mierze zaspokoi rosnące potrzeby w zakresie dostępu do informacji przestrzennej i ich wykorzystania w procesach decyzyjnych. Osiągnięcie tych celów jednak wymaga ścisłego współdziałania organów administracji, skierowanego na rozwiązywanie aspektów organizacyjnych, technicznych i semantycznych. Współdziałanie organizacyjne partnerów współtworzących infrastrukturę, a zatem urzędów, instytucji, organizacji i firm, zainteresowanych korzystaniem z danych przestrzennych i związanych z nimi usług, dotyczy w głównej mierze budowy wspólnych elementów tej infrastruktury. Techniczne aspekty dotyczą wdrażania nowoczesnych technologii, urządzeń i standardów technicznych w sposób zapewniający współdziałanie różnych systemów teleinformatycznych. Rozwiązywanie aspektów semantycznych prowadzi do ujednolicenia terminów i pojęć stosowanych w zakresie informacji przestrzennej w różnych dziedzinach wiedzy, gospodarki, w różnych środowiskach oraz zastosowaniach i ma na celu poprawne rozumienie danych przestrzennych oraz ich efektywne wykorzystanie. Zgodnie z ustawą o infrastrukturze informacji przestrzennej koordynacja działań związanych z tworzeniem infrastruktury informacji przestrzennej w Polsce jest zadaniem ministra właściwego do spraw administracji publicznej wykonywanym przy pomocy Głównego Geodety Kraju. Zadanie to wymaga współdziałania poszczególnych organów wiodących w procesie wdrażania infrastruktury informacji przestrzennej, w tym w szczególności w obszarze określającym zakres wdrożenia oraz konieczne rozwiązania organizacyjno techniczne (techniki, metodyki). Strona 91 z 185

5.4 Krajowa Infrastruktura Informacji Przestrzennej Prace nad określeniem, projektowaniem i budową infrastruktury informacji przestrzennej w Polsce osiągnęły w ostatnim okresie szczególnie dużą skalę i prowadzone są na trzech płaszczyznach: legislacyjnej, organizacyjnej i technologicznej. Płaszczyzna legislacyjna to w głównej mierze projekty rozporządzeń wykonawczych do Ustawy o Infrastrukturze Informacji Przestrzennej, ale również, ze względu na zależność krajowej infrastruktury od infrastruktury europejskiej, szereg nowych dokumentów związanych z Dyrektywą INSPIRE z zakresu przepisów wykonawczych i specyfikacji technicznych dotyczących danych i usług przestrzennych. Aspekt organizacyjny to kilka nowych dużych projektów, już realizowanych i przygotowywanych do realizacji przez organy administracji publicznej, a w szczególności organy wiodące, takie jak Główny Urząd Geodezji i Kartografii, Główny Urząd Statystyczny oraz Państwowy Instytut Geologiczny. Aspekt technologiczny podejmowanych działań stanowi w tym przypadku realne tło, od którego zależy praktyczna możliwość zrealizowania zainicjowanych przedsięwzięć wyznacza realne ramy, w których te projekty muszą się zmieścić, aby mogły zakończyć się pełnym sukcesem. Analiza opublikowanych na dzień opracowania niniejszego raportu dokumentów, zarówno o charakterze legislacyjnym, organizacyjnym, jak i technologicznym nie pozwala na zidentyfikowanie szczegółowej i jednoznacznej koncepcji architektury Infrastruktury Informacji Przestrzennej w Polsce. Na obecnym etapie możliwe jest tylko zarysowanie jej ogólnej koncepcji, nie w pełni jeszcze precyzyjnej, kompletnej i spójnej, ponieważ wiele prac z tego zakresu jest w toku lub prace nad nowymi projektami nie zostały jeszcze rozpoczęte. Jednak zebranie wszystkich elementów wyłaniającej się koncepcji w pewną całość, pomimo braku pełnej kompletności i spójności, jest koniecznością. Wynika ona z podstawowej zasady, że skuteczna realizacja zadań cząstkowych wymaga wiedzy o całości tego, co ma powstać w wyniku realizacji zadań cząstkowych o ogólnej koncepcji całej Infrastruktury Informacji Przestrzennej. 5.4.1 Zarys koncepcji IIP Podstawowymi elementami infrastruktury informacji przestrzennej w Polsce są tzw. węzły IIP, którym przypisywane są różne role organizacyjno techniczne a w konsekwencji tego również różna architektura. Strona 92 z 185

Współpracujące ze sobą węzły IIP tworzą federacyjną sieć i mogą wzajemnie korzystać ze swoich zasobów, komunikując się ze sobą przy pomocy zestandaryzowanych interfejsów. Jednocześnie, każdy z węzłów sieci funkcjonuje autonomicznie, w taki sposób, iż wyłączenie jednego z nich nie uniemożliwia działania całej sieci. Pojedynczy węzeł jest zespołem systemów gromadzenia, zarządzania i udostępniana danych przestrzennych, współpracującym z innymi węzłami IIP oraz wspomagającym realizację procesów biznesowych danej organizacji odpowiedzialnej za utrzymanie określonych, nazwanych zasobów danych przestrzennych, odpowiednio odnoszących się do zakresu kompetencji danego organu. Z punktu widzenia funkcjonowania infrastruktury najistotniejszymi elementami węzła są interfejsy dostarczające usługi udostępniane przez ten węzeł oraz zapewniające komunikację wzajemną pomiędzy węzłami. Każda usługa może być realizowana bezpośrednio, czyli wyłącznie w oparciu o protokół obsługiwany przez dany interfejs lub pośrednio, poprzez witrynę WWW (nazywaną często geoportalem - czasami dla odróżnienia od projektu GEOPORTAL - portalem). Interfejsy usług bezpośrednich węzłów infrastruktury informacji przestrzennej są określone w specyfikacjach OGC oraz normach ISO z serii 19100 i obejmują w szczególności: - interfejs serwera katalogowego (CSW), bezpośrednia usługa wyszukiwania; - interfejs serwera map (WMS), bezpośrednia usługa przeglądania; - interfejs serwera map (WMTS), bezpośrednia usługa przeglądania wykorzystująca technikę segmentacji (tiling) i przechowywania segmentów (cache); - interfejs serwera typów obiektów (WFS) bezpośrednia usługa pobierania; - interfejsy innych serwerów realizujące usługi bezpośrednie - serwera pokryć (WCS), serwera przetwarzania (WPS) i innych pod wspólną nazwą OWS Open Web Services; - interfejsy usług wymienionych powyżej rozszerzone o wymagania dotyczące usług INSPIRE (dotyczy to tylko węzłów, które jednocześnie pełnią rolę krajowych węzłów europejskiej infrastruktury informacji przestrzennej). 5.4.2 Ogólny diagram architektury IIP Ogólny diagram architektury będący implementacją koncepcji IIP został przedstawiony na Rysunku 1. Składa on się z trzech głównych nakładających się na siebie obszarów: Europejska IIP INSPIRE, Krajowa Strona 93 z 185

IIP oraz Infrastruktury nie-iip. W poszczególnych strefach diagramu umieszczono w formie symbolicznej oraz uproszczonej poszczególne komponenty infrastruktury. Podstawowymi elementami diagramu są węzły infrastruktury. Zgodnie z założeniami koncepcji IIP, pojęcie węzła nie należy do kategorii pojęć z zakresu technologii, lecz jest to pojęcie należące raczej do problematyki organizacyjnej. Węzeł jest budowany najczęściej w trybie projektu o charakterze inwestycyjnym, a dalej jest utrzymywany i nadzorowany przez określoną organizację. Przedstawione na diagramie węzły należy interpretować, jako role, jakie mogą pełnić poszczególne organizacje. Role te wynikają z odpowiednich przepisów prawnych, w tym w szczególności dyrektywy INSPIRE oraz ustawy o IIP. To, w jaki sposób węzeł/rola zostanie organizacyjnie i technologicznie zrealizowany/a pozostaje w gestii danej organizacji oraz organu wiodącego odpowiedzialnego za określony temat danych przestrzennych. W szczególnych przypadkach niektóre węzły będą mogły pełnić kilka ról np. węzły tworzone przez samorządy województwa lub gminy. Połączenia pomiędzy poszczególnymi węzłami przedstawiono w sposób uproszczony, wskazując jedynie konieczność ich wzajemnej współpracy, bez określenia ich wzajemnych ról, reguł komunikacji i rodzaju przesyłanych danych. Strona 94 z 185

Rysunek 17 Ogólny diagram architektury IIP Obszar wyróżniony kolorem niebieskim to europejska infrastruktura informacji przestrzennej budowana w ramach INSPIRE. Składa się ona z dwóch części: - Infrastruktury INSPIRE nienależącej do IIP w Polsce, w której skład wchodzi Europejski węzeł INSPIRE (geoportal europejski) i infrastruktury pozostałych krajów członkowskich; - Krajowej części infrastruktury INSPIRE, reprezentowanej na diagramie przez część wspólną obszaru wyróżnionego kolorem niebieskim i obszaru wyróżnionego kolorem pomarańczowym, określającego zakres Infrastruktury Informacji Przestrzennej w Polsce. W tym obszarze wszystkie węzły powinny funkcjonować zgodnie ze specyfikacjami INSPIRE zarówno w zakresie usług jak i struktur oraz zawartości danych, przy czym ich funkcjonalność może być również Strona 95 z 185

realizowana przez odpowiadające im węzły poziomu krajowego np. węzeł krajowy może realizować funkcjonalność krajowego węzła INSPIRE. Obszar wyróżniony kolorem pomarańczowym to krajowa infrastruktura informacji przestrzennej w Polsce, zdefiniowana w ustawie z dnia 4 marca 2010 r. o Infrastrukturze Informacji Przestrzennej. W jej ramach można wyróżnić trzy poziomy agregacji węzłów: - Krajowa IIP - Krajowa część infrastruktury INSPIRE, - Lokalna IIP - Lokalna infrastruktura IIP, obszar wyróżniony kolorem żółtym (w części wspólnej z obszarem wyróżnionym na pomarańczowo), która reprezentuje dwa rodzaje infrastruktur: o Pojedyncze infrastruktury dziedzinowe/resortowe, których działanie jest o nadzorowane przez organy wiodące wymienione w artykule 2 ustęp 7 ustawy o IIP. W tym obszarze nie jest wymagane, aby poszczególne organy wiodące tworzyły hierarchiczną infrastrukturę w ramach danej dziedziny tematycznej, jednak warunkiem koniecznym jest istnienie jednego węzła, który będzie pełnił rolę brokera w dostępie do zbiorów i usług danych przestrzennych w danej dziedzinie tematycznej. Poszczególne węzły nie muszą spełniać wymagań specyfikacji INSPIRE, zarówno w zakresie usług, jak i struktur oraz zawartości danych, jednak muszą być one zgodne z odpowiednimi przepisami i wytycznymi krajowymi dla danej dziedziny tematycznej. Przykładami takich infrastruktur mogą być infrastruktury: Państwowej Służby Geologicznej, Państwowej Służby Hydrogeologicznej, Państwowej Służby Meteorologicznej, Państwowej Służby Hydrologicznej i służb ochrony środowiska oraz Głównego Urzędu Statystycznego. Pojedyncze infrastruktury tworzone i zarządzane przez osoby trzecie w rozumieniu art. 4 pkt.3 ustawy o IIP. W tym obszarze węzły nie muszą spełniać wymagań specyfikacji INSPIRE, zarówno w zakresie usług, jak i struktur oraz zawartości danych. Jednak, aby dana infrastruktura lokalna mogła zostać włączona do krajowej IIP, musi ona spełniać wymagania odpowiednich przepisów i wytycznych krajowych, które zapewniają interoperacyjność zbiorów i usług danych przestrzennych. Dodatkowo, w ramach krajowej infrastruktury informacji przestrzennej mogą funkcjonować pojedyncze węzły lokalne, które są tworzone i zarządzane przez osoby trzecie w rozumieniu art. 4 pkt.3 ustawy o IIP. Węzły te udostępniają swoje zasoby danych przestrzennych w postaci zgodnej z przepisami i wytycznymi krajowymi, które zapewniają interoperacyjność zbiorów i usług danych przestrzennych. Strona 96 z 185

Z punktu widzenia technologicznego, na poziomie implementacyjnym węzeł lokalny może realizować również funkcjonalność lokalnego węzła INSPIRE, jeżeli udostępniane przez niego zasoby danych przestrzennych zostały zakwalifikowane do krajowych zasobów INSPIRE. W zakresie usług katalogowych węzeł musi komunikować się bezpośrednio z węzłem krajowym. Węzły te mogą mieć geoportal, lecz nie jest to obowiązkowe. Obszar wyróżniony kolorem fioletowym, rozdzielny z obszarem, który obejmuje krajową IIP (kolor pomarańczowy), to inne polskie infrastruktury lub węzły nie określone w ustawie o infrastrukturze informacji przestrzennej i w związku z tym nienależące również do Infrastruktury INSPIRE. Obszar ten może mieć część wspólną z obszarami reprezentującymi dziedzinowe IIP (kolor żółty) i lokalne IIP (kolor zielony); wynika to z tego, że pojedyncze węzły lokalne wchodzące w skład tych infrastruktur mogą nie obejmować tematyki określonej w ustawie o infrastrukturze informacji przestrzennej. 5.5 Metadane w KIIP Zgodnie z definicją Infrastruktury Informacji Przestrzennej metadane KIIP to opisane metadanymi zbiory danych przestrzennych oraz dotyczące ich usługi, środki techniczne, procesy i procedury, które są stosowane i udostępniane przez współtworzące infrastrukturę informacji przestrzennej organy wiodące, inne organy administracji oraz osoby trzecie. Tak utworzone, opisane metadane zawierają skondensowane informacje na temat zasobów danych tworzących IIP stanowiąc jednocześnie ich integralną część składową. Za udostępnienie zbiorów metadanych, zgodnie z art. 5 ustawy o IIP odpowiadają organy administracji i osoby trzecie odpowiedzialne, w zakresie swoich kompetencji za prowadzenie zasobów danych przestrzennych, które są tymi metadanymi opisywane. Dostęp do infrastruktury informacji przestrzennej, w tym do metadanych KIIP powinny zapewnić poszczególne węzły tworzące federacyjną sieć, mogące wzajemnie korzystać ze swoich zasobów, przy czym istotne jest, aby dostęp ten był możliwy również z jednego miejsca z geoportalu węzła krajowego do wszystkich zasobów danych przestrzennych całej krajowej infrastruktury. Dostęp taki można zrealizować wykorzystując do tego celu metadane udostępniane przez usługi wyszukania. W tym celu niezbędne jest stworzenie odpowiedniej architektury usług katalogowych w ramach krajowej infrastruktury informacji przestrzennej. Architektura ta powinna zagwarantować dostęp do metadanych opisujących wszystkie zasoby danych przestrzennych wchodzących w skład tej infrastruktury. Strona 97 z 185

Koncepcja takiej architektury jest w chwili obecnej opracowywana w Głównym Urzędzie Geodezji i Kartografii w ramach realizacji projektu Implementacja i utrzymanie usług INSPIRE i ich brokera krajowego, brokera branżowego oraz szkolenia, na potrzeby projektu GEOPORTAL 2. 5.6 Dane przestrzenne Głównym elementem każdej infrastruktury informacji przestrzennej są dane, a w szczególności zbiory danych przestrzennych. Zgodnie z ustawą o infrastrukturze informacji przestrzennej oraz Dyrektywą INSPIRE, europejska i krajowa IIP obejmuje zbiory danych przestrzennych: 1. odnoszące się do terytorium Rzeczypospolitej Polskiej lub z nim powiązane; 2. występujące w postaci elektronicznej; 3. utrzymywane przez: - organ administracji lub w jego imieniu, które zgodnie z jego zadaniami publicznymi są tworzone, aktualizowane i udostępniane, - osobę trzecią, której umożliwiono włączenie się do infrastruktury; 4. należące, co najmniej, do jednego z tematów danych przestrzennych określonych w załączniku do ustawy. Jednym z najważniejszych wymagań IIP jest to, że w ramach krajowej, jak i europejskiej IIP nie mogą funkcjonować dwa identyczne zbiory danych. W przypadku, gdy większa liczba identycznych zbiorów danych przestrzennych jest w posiadaniu lub jest przechowywana w imieniu różnych organów administracji, to tylko wersje referencyjne, z których uzyskano pozostałe kopie są włączane do infrastruktury informacji przestrzennej. 5.6.1 Struktura danych przestrzennych Dyrektywa INSPIRE, a w ślad za nią ustawa o Infrastrukturze Informacji, posługuje się wieloma nowymi pojęciami, w tym w szczególności zbiorem danych oraz tematem danych. W ramach europejskiej i krajowej IIP, przyjęto dla tego zagadnienia podejście pragmatyczne, polegające na budowaniu systematyki danych w hierarchicznej strukturze tzw. kategoryzacji danych w następujący sposób: - Tematy danych przestrzennych (Spatial data theme): Kategorie tematyczne wysokiego poziomu ogólności; Strona 98 z 185

- Komponenty danych przestrzennych (Spatial data component): podkategorie. Komponent danych przestrzennych obejmuje pewną grupę danych przestrzennych o podobnej charakterystyce, nie uwzględniając skali; - Zbiory danych przestrzennych (Spatial data sets): najniższy poziom niniejszej koncepcji ramowej - zbiory danych przestrzennych zawierają rzeczywiste dane ze zdefiniowaną zawartością oraz dokładnością/skalą. Rysunek 18 Hierarchiczna struktura do grupowania danych przestrzennych [Źródło: INS DAT] W ramach tak zdefiniowanej systematyki (koncepcji ramowej) rzeczywiste zbiory danych są identyfikowane w ramach każdego komponentu danych przestrzennych, przy czym każdy zbiór danych umieszczany jest tylko w jednym z komponentów danych przestrzennych. Na potrzeby opisywania danych przestrzennych metadanymi zbiory danych przestrzennych mogą być grupowane w serie danych przestrzennych. W ramach europejskiej i krajowej IIP wyróżniono następujące tematy danych przestrzennych. Załącznik I 1. Systemy odniesienia za pomocą współrzędnych 2. Systemy siatek geograficznych 3. Nazwy geograficzne 4. Jednostki administracyjne 5. Adresy 6. Działki katastralne 7. Sieci transportowe Strona 99 z 185

8. Hydrografia 9. Obszary chronione Załącznik II 1. Ukształtowanie terenu 2. Użytkowanie terenu 3. Sporządzanie ortoobrazów 4. Geologia Załącznik III 1. Jednostki statystyczne 2. Budynki 3. Gleba 4. Zagospodarowanie przestrzenne 5. Zdrowie i bezpieczeństwo ludzi 6. Usługi użyteczności publicznej i służby państwowe 7. Urządzenia do monitorowania środowiska 8. Obiekty produkcyjne i przemysłowe 9. Obiekty rolnicze oraz akwakultury 10. Rozmieszczenie ludności demografia 11. Gospodarowanie obszarem/strefy ograniczone/regulacyjne oraz jednostki sprawozdawcze 12. Strefy zagrożenia naturalnego 13. Warunki atmosferyczne 14. Warunki meteorologiczno-geograficzne 15. Warunki oceanograficzno-geograficzne 16. Regiony morskie 17. Regiony biogeograficzne 18. Siedliska i obszary przyrodniczo jednorodne 19. Rozmieszczenie gatunków 20. Zasoby energetyczne 21. Zasoby mineralne. Strona 100 z 185

5.6.2 Charakterystyka metadanych Dane przestrzenne (dane geograficzne) są wykorzystywane przez bardzo wielu użytkowników systemów geoinformacyjnych (GIS), niebędących, zazwyczaj ich wytwórcami. Właściwe, celowe oraz poprawne zastosowanie określonego zbioru danych opiera się na wiedzy o tym zasobie, wiedzy, która powinna być dostępna w formie opisu stanowiącego swoistą dokumentację techniczną zbioru danych. Dokumentacja ta, będąca w minimalnym zakresie specyfikacją wybranych, określonych dla danego zbioru danych cech, nazywana jest metadanymi lub opisem, zbiorem metadanych. 5.6.3 Cel tworzenia Metadane tworzy się w celu: - ułatwienia wyszukiwania zasobów danych i nawiązania kontaktu z ich dysponentem, - określenia przydatności zbiorów danych pod względem wymagań użytkownika, - promowania dostępności danych przestrzennych i poszerzenia kręgu ich użytkowników poprzez zapewnienie możliwości łatwego znalezienia ich opisu w sieci Internet, - usprawnienia funkcjonowania systemów gromadzących dane przestrzenne, zwłaszcza systemów rozproszonych, - wspomożenia użytkowników w ustaleniu, czy dane geograficzne znajdujące się w zbiorze będą dla nich przydatne. 5.6.4 Standardy metadanych Dla poprawnego i efektywnego zarządzania metadanymi oraz ich powszechnego wykorzystania niezwykle istotnym jest, aby były one jednoznaczne w swej postaci i zawartości, niezależnie od tego, przez kogo i w jaki sposób (w jakim systemie) zostały utworzone. 5.6.4.1 ISO 19115 Celem normy ISO 19115 jest dostarczenie struktury do opisu cyfrowych danych geograficznych (danych przestrzennych). Norma ta jest przeznaczona do stosowania przez analityków systemów informatycznych, projektantów i programistów systemów informacji geograficznej, jak również inne osoby w celu zrozumienia podstawowych zasad i ogólnych wymagań standaryzacji informacji geograficznej. Norma ISO 19115 definiuje podstawowe elementy metadanych, dostarcza schemat i ustanawia wspólny zbiór terminologii, definicji i procedur rozbudowy metadanych. Strona 101 z 185

Norma ISO 19115 przeznaczona jest do: - katalogowania zbiorów danych, wykorzystania ich w hurtowniach danych oraz pełnego opisu zbiorów danych; - opisu zbiorów danych geograficznych, serii zbiorów i pojedynczych obiektów geograficznych oraz ich właściwości; Norma ISO 19115 definiuje: - obligatoryjne i warunkowe sekcje metadanych, encje metadanych i elementy metadanych; - podstawowy zbiór metadanych wymagany do zapewnienia pełnego zakresu zastosowań metadanych (wyszukiwanie danych, określanie przydatności danych, dostęp do danych, transfer danych i wykorzystanie danych cyfrowych); - fakultatywne elementy metadanych, za pomocą których można szczegółowo opisać dane geograficzne w sposób znormalizowany (normatywny), o ile opis taki jest wymagany; - metodę rozbudowy metadanych (definiowania nowych metadanych) w celu zaspokojenia specyficznych potrzeb. 5.6.4.2 ISO/TS 19139 Model metadanych zdefiniowany w ISO 19115 ma charakter abstrakcyjny, tym samym jego poszczególne implementacje mogą się od siebie różnić w zależności od interpretacji normy przyjętej przez poszczególnych autorów metadanych. Dlatego też specyfikacja techniczna ISO/TS 19139 określa model interpretacyjny UML (Unified Modeling Language) dla abstrakcyjnego modelu metadanych ISO 19115 oraz definiuje odpowiadający jemu schemat XML Schema (XSD) dla potrzeb gromadzenia i transferu meta informacji. Norma ta wprowadza sposób zapisu technicznego normy ISO 19115 tak, aby był on jednoznaczny i gwarantował interoperacyjność pomiędzy różnymi systemami metadanych. 5.6.4.3 ISO 19119 W zakresie matadanych norma ISO 19119 jest rozszerzeniem modelu metadanych zdefiniowanego w ISO 19115 przez dostarczenie struktur do opisu identyfikacji usług danych przestrzennych. Węzeł SV Service Identification zastępuje informacje o identyfikacji zawarte w normie ISO 19115 i zawiera informacje określające przeznaczenie opisywanej usługi, sposób komunikacji oraz możliwe operacje do wykonania w jej ramach. Strona 102 z 185

Podobnie jak norma ISO 19115, standard ten jest przeznaczony do stosowania przez analityków systemów informatycznych, projektantów i programistów systemów informacji geograficznej, jak również inne osoby w celu zrozumienia podstawowych zasad i ogólnych wymagań standaryzacji informacji geograficznej. Model interpretacji UML (Unified Modeling Language) dla abstrakcyjnego modelu metadanych ISO 19119 w postaci schematu XML Schema (XSD) określa [CSW ISO AP]. 5.6.5 Profil metadanych Norma ISO 19115 definiuje około 400 elementów metadanych, z których większość jest fakultatywna. Elementy te zostały zdefiniowane w celu ułatwienia użytkownikom dokładnego zrozumienia tego, co jest opisywane oraz sprawnego wdrożenia mechanizmu metadanych. Poszczególne społeczności, społeczeństwa lub organizacje mogą utworzyć, w celu zaspokojenia swoich specyficznych potrzeb, własny podzbiór klas i elementów podstawowego standardu metadanych, który opcjonalnie może zostać rozszerzony o elementy metadanych niewystępujące w standardzie podstawowym. Taki podzbiór elementów utworzony zgodnie z zasadami opisanymi w normie nazywany jest profilem metadanych. 5.6.5.1 Profil INSPIRE Profil dla metadanych tworzonych w ramach europejskiej infrastruktury informacji przestrzennej (INSPIRE) utworzony został Rozporządzeniem z dnia 3 grudnia 2008 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady Europejskiej w zakresie metadanych. Rozporządzenie to wprowadziło wymagania w zakresie tworzenia i przechowywania metadanych dla zbiorów danych przestrzennych, serii zbiorów danych przestrzennych i usług danych przestrzennych dotyczących tematów wymienionych w załącznikach I, II i III do dyrektywy INSPIRE. Zawarty w rozporządzeniu zestaw elementów metadanych z założenia jest uniwersalny i niezależny od środowiska komputerowego. 5.6.5.2 Profil i wytyczne krajowe W Polsce nie zdefiniowano podstawowego profilu metadanych w zakresie informacji przestrzennej, który mógłby być wykorzystywany w różnych działach gospodarki narodowej, gwarantując porównywalność metadanych powstających w różnych ośrodkach i grupach zawodowych. Strona 103 z 185

Co prawda w 2008 roku Główny Urząd Geodezji i Kartografii opublikował na swoich stronach internetowych dokument opracowany przez zespół ekspertów pt. Polski krajowy profil metadanych w zakresie geoinformacji, jednakże nigdy nie został on zatwierdzony przez właściwy organ administracji rządowej jako dokument formalny, a i sam GUGiK traktuje go, jako dokument studyjny, który nigdy nie wyszedł poza fazę projektu. Jedynym formalnym krajowym dokumentem w zakresie metadanych są opublikowane w listopadzie 2010 roku przez GUGiK Wytyczne do przygotowania metadanych w zakresie działek ewidencyjnych. Jest to opracowanie sporządzone na potrzeby tworzenia metadanych dla zbiorów danych przestrzennych ewidencji gruntów i budynków, stanowiących zasób źródłowy dla tematu Działki ewidencyjne określonego w załączniku do Ustawy z dnia 4 marca 2010 roku o infrastrukturze informacji przestrzennej. 5.6.5.3 Portal katalogowy Standardowa przeglądarka internetowa jest wystarczającym, przyjaznym dla użytkownika środowiskiem zapewniającym interfejs dostępu do usługi katalogowej. Może ona służyć zarówno użytkownikom, jak i administratorom katalogu metadanych do wywołania odpowiedniej aplikacji webowej (transportowanej poprzez protokół HTTP w postaci HTML i XML z możliwymi rozszerzeniami), która implementuje elementy interfejsu użytkownika do wyszukiwania i publikacji zasobów danych przestrzennych. Zakres funkcjonalności tej aplikacji powinien wspierać autoryzowanych administratorów w czynnościach edycji istniejących metadanych i zarządzania rozproszonymi źródłami metadanych, które istnieją w postaci innych usług wyszukiwania bądź udostępnianych repozytoriów rekordów metadanych. Komunikacja pomiędzy aplikacją webową i usługą wyszukiwania następuje zgodnie z profilem aplikacyjnym usługi typu OGC CSW dla protokołów HTTP GET/POST lub HTTP/SOAP. Fizyczne rozlokowanie tych komponentów niekoniecznie musi nastąpić w tym samym węźle infrastruktury technicznej. Komunikacja pomiędzy usługą wyszukiwania i bazą metadanych nie podlega normatywnym ustaleniom środowiska geomatycznego i może zostać zaimplementowana w dowolny sposób. Strona 104 z 185

Rysunek 19 Ogólna architektura techniczna usługi wyszukiwania i portalu katalogowego [Źródło: A.Śliwinski, S.Podlasek Podstawy wdrożenia infrastruktury przestrzennej w Polsce zgodnie z architekturą zorientowaną na usługi sieciowe, Roczniki Geomatyki, rok 2007, T. 5, z. 5] 5.7 Usługi danych przestrzennych 5.7.1 Charakterystyka usług Jednym z podstawowych założeń budowy infrastruktury informacji przestrzennej jest jej zorientowanie na usługi. Usługa danych przestrzennych to operacje, które mogą być wykonywane przy użyciu oprogramowania komputerowego na danych zawartych w zbiorach danych przestrzennych lub na powiązanych z nimi metadanych. W ramach norm serii 19100 i specyfikacji OGC można wyróżnić grupę standardów definiujących protokoły oraz interfejsy programowe poszczególnych rodzajów usług sieciowych pozwalające na komunikację klienta z usługą. Strona 105 z 185

Architektura tych usług bazuje na koncepcji SOA, gdzie szczególną rolę pełni magistrala usług, na której poszczególne węzły udostępniają własne usługi lub też za pośrednictwem, której uzyskują dostęp do usług wystawionych przez inne węzły. Magistrala ma charakter generyczny, co oznacza, że usługi są bytami wykorzystywanymi przez aplikacje komputerowe. Zwykły użytkownik widzi je poprzez graficzny interfejs aplikacji posiadającej zdolność do komunikacji z usługami, zgodnie z określonymi protokołami oraz interfejsami programowymi usług. 5.7.2 Usługi sieciowe OGC Usługi sieciowe OGC (ang. OGC Web Services) bazują na modelu klient-serwer (serwer jest dostarczycielem usługi, a klient konsumentem), w którym komunikacja pomiędzy uczestnikami dialogu odbywa się za pomocą plików XML. Komunikacja ta jest realizowana w warstwie protokołu sieciowego (protokół danej usługi) nad warstwą protokołu HTTP. Najpopularniejsze obecnie usługi OGC wskazane do implementacji w zakresie prac nad budową infrastruktury informacji przestrzennej to: Web Map Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS), Web Procesing Service (WPS) oraz Web Catalogue Services (CSW). 5.7.2.1 Usługa WMS Usługa Web Map Service (WMS) jest usługą, której podstawowym zadaniem jest dynamiczne tworzenie mapy na podstawie danych przestrzennych. Zgodnie z ISO 19128 przez mapę rozumie się prezentację danych przestrzennych w postaci obrazu cyfrowego, nadającego się do wyświetlenia na ekranie komputera. Mapa nie jest tym samym co dane. Mapy utworzone za pomocą usługi WMS są zapisywane najczęściej w takich formatach graficznych, jak PNG, GIF i JPEG, a sporadycznie także jako wektorowe elementy graficzne w formacie SVG lub WebCGM. Specyfikacja usługi WMS zawiera opis protokołu, służącego do wysyłania żądań i udzielania odpowiedzi pomiędzy klientami a serwerami map. Żądania te dotyczą udostępniania map i szczegółowych informacji o specyficznych cechach przedstawionych na mapie. W ramach protokołu WMS wyróżnia się trzy podstawowe operacje, które zestawiono w poniższej tabeli. Operacja GetCapabilities GetMap Rola Dostarcza niezbędnych informacji dotyczących usługi i opisuje możliwości usługi. Zwraca mapę o poprawnie zdefiniowanych parametrach geograficznych i wymiarach Strona 106 z 185

Operacja GetFeatureInfo Rola Zwraca informację na temat wybranych obiektów przestrzennych pokazanych na mapie (operacja opcjonalna). Tabela 1 Podstawowe operacje usługi WMS 5.7.2.2 Usługa WFS Usługa Web Feature Service (WFS) jest usługą, której podstawowym zadaniem jest udostępnianie danych przestrzennych w postaci źródłowej oraz umożliwienie ich aktualizacji. Usługa WFS stanowi zmianę w sposobie udostępnia danych przestrzennych. Umożliwia ona ich tworzenie, modyfikowanie i wymianę w Internecie. Zamiast wymiany danych przestrzennych na poziomie plików, usługa WFS oferuje bezpośredni dostęp do danych przestrzennych na poziomie obiektów i ich właściwości. Usługa WFS pozwala klientom pobierać tylko zestaw danych, który zawiera informację przez nich poszukiwane, a nie jak to ma miejsce w przypadku udostępniania plików zawierający znacznie więcej. Pobrane przez użytkownika (klienta usługi) dane mogą być następnie wykorzystane do różnych celów, w tym do celów innych niż cele wyznaczone przez ich producentów. 5.7.3 Usługa WCS Usługa Web Coverage Service (WCS) jest usługą, której podstawowym zadaniem jest udostępnianie danych przestrzennych typu GRID coverage, czyli pokryć w postaci siatkowej. Pokrycia są kategorią danych przestrzennych opisującą zbiór lokalizacji przestrzennych, podając dla każdej lokalizacji jedną lub więcej cech (mogą nimi być: zakres, atrybutz ilościowe i jakościowe). Dane pokrycia mogą byś rozmieszczone na siatkach regularnej lub nieregularnej. 5.7.4 Usługa WPS Usługa Web Procesing Service (WPS) jest usługą, która definiuje standardowy interfejs publikowania procesów geoprzestrzennych oraz uruchomiania procesu przez klienta. Specyfikacja tej usługi standaryzuje sposób, w jaki są opisywane procesy wraz z ich parametrami wejściowymi i wyjściowymi, definiuje postać żądań, jakie mogą zgłaszać klienci w celu wykonania danego procesu oray określa sposób obsługi wyników działania tego procesu. Usługa WPS może działać jako nakładka na istniejące lub planowane usługi przetwarzania danych przestrzennych, może też być wykorzystywana w połączeniu z innymi usługami, tworząc z nimi cały łańcuch przetwarzania. Przykładem takiego profilu aplikacyjnego usługi WPS jest usługa Web Coordinate Strona 107 z 185

Transformation Service (WCTS) służąca transformacji danych przestrzennych pomiędzy różnymi układami odniesienia. 5.7.5 Usługa CSW Usługa Web Catalogue Services (CSW) jest usługą, która definiuje standardowy interfejs pozwalający na przeglądanie i wyszukiwanie metadanych opisujących zasoby danych przestrzennych. Opublikowanie usługi sieciowej polega na jej zarejestrowaniu. Jest to rodzaj kontraktu między rejestrem usług a dostawcą. W momencie, kiedy dostawca usługi umieszcza jej opis (metadane) w rejestrze, czyli usłudze wyszukiwania, potencjalni klienci mają dostęp do szczegółowych informacji na temat jej funkcji. Wyszukiwanie jest niemal lustrzanym odbiciem operacji publikowania. Jest to relacja pomiędzy klientem usługi a rejestrem usług. Za pomocą tej operacji klient usługi określa kryteria wyszukiwania na przykład, jaki jest typ usługi lub jej zakres tematyczny czy obszar geograficzny. Rejestr usług, czyli usługa wyszukiwania, wyszukuje wśród przechowywanych opisów (metadanych) wszystkie usługi spełniające podane kryteria. 5.7.6 Usługi danych przestrzennych INSPIRE Zgodnie z definicję zawartą w dyrektywie INSPIRE jednym z najważniejszych komponentów europejskiej infrastruktury informacji przestrzennej są usługi danych przestrzennych, które w jej ramach tworzą architekturę usług sieciowych. Architektura usług sieciowych INSPIRE jest rozwiązaniem bazującym na paradygmacie SOA. W architekturze tę warstwę dostępową stanowią aplikacje i geoportale. Z ich poziomu użytkownicy mogą sposób wywoływać usługi danych przestrzennych, które są wystawiane na magistrali usług INSPIRE przez ich dostawców. Punkty dostępowe do usług INSPIRE mogą być tworzone na różnych poziomach infrastruktury, w węzłach poziomu lokalnego, przez węzły poziomu krajowego, aż po poziom węzła europejskiego. Dostęp do usług powinien być przezroczysty, co oznacza, że użytkownik nie zauważa pochodzenia danych z różnych źródeł i poziomów. Strona 108 z 185

Rysunek 20 Architektura usług sieciowych INSPIRE [Źródło: Recommendations for INSPIRE Spatial Data Services v1.1, 2011] Zgodnie z przyjętą wykładnią, usługa INSPIRE to usługa sieciowa zgodna ze specyfikacjami usług INSPIRE pod względem definicji protokołu, czyli listą poleceń, składnią tych poleceń, a także listą i składnią argumentów poszczególnych poleceń, lecz również odpowiedzi serwera w postaci danych zgodnych z odpowiednią specyfikacją danych INSPIRE. W architekturze usług danych przestrzennych INSPIRE wyróżnia się następujące typy usług: usługi wyszukania, usługi przeglądania, usługi pobierania, usługi przekształcania, usługi uruchamiania. 5.7.7 Usługa wyszukania INSPIRE Discovery Service Usługa wyszukiwania, umożliwia wyszukiwanie zbiorów oraz usług danych przestrzennych na podstawie zawartości odpowiadających im metadanych oraz umożliwia wyświetlanie zawartości metadanych. W ramach europejskiej infrastruktury informacji przestrzennej usługi te muszą być implementowane zgodnie z [INS NS] i [INS NS DS]. Usługa wyszukania jest rozszerzeniem profilu aplikacyjnego OGC CSW ISO AP. Usługa wyszukiwania jest usługą obligatoryjną. 5.7.8 Usługa przeglądania INSPIRE View Service Usługa przeglądania umożliwia wyświetlanie, nawigowanie, powiększanie i pomniejszanie, przesuwanie lub nakładanie na siebie zbiorów danych przestrzennych oraz wyświetlanie informacji z legendy i wszelkiej istotnej zawartości metadanych. W ramach europejskiej infrastruktury informacji przestrzennej usługi te muszą być implementowane zgodnie z [INS NS] i [INS NS VS]. Usługa przeglądania Strona 109 z 185