Szczegółowy Opis Przedmiotu Zamówienia

Transkrypt

1 Załącznik nr 1 Szczegółowy Opis Przedmiotu Zamówienia 1. Informacje wstępne 1.1 Podstawowe informacje o projekcie Celem bezpośrednim projektu jest wzrost liczby oraz poprawa jakości publicznych e-usług świadczonych przez Miasto Rybnik poprzez utworzenie Geoinformacyjnej Platformy Usług Elektronicznych (GPUE), jako zintegrowanego funkcjonalnie systemu prowadzenia referencyjnych zbiorów danych przestrzennych i rejestrów Wydziału Geodezji i Kartografii Urzędu Miasta Rybnika. System GPUE musi dostarczać wysokiej jakości mechanizmy utrzymania danych dotyczące ich: spójności, aktualności, dokładności, wiarygodności oraz zgodności ze standardami europejskimi oraz krajowymi. Szczegółowe cele projektu obejmują: 1) modernizację sposobu funkcjonowania administracji poprzez zwiększenie efektywności udostępniania referencyjnych zbiorów danych przestrzennych za pośrednictwem elektronicznych usług geoinformacyjnych na potrzeby administracji, jednostek wykonawstwa geodezyjnego i innych dziedzin życia społecznego, 2) utworzenie zintegrowanych geometryczno opisowych baz danych w celu uzyskania wyższego stopnia interoperacyjności systemów funkcjonujących w UM oraz minimalizacji i redundancji kosztów przetwarzania tych danych, 3) możliwość uzyskania zestawień informacji przestrzennych zgodnych z indywidualnymi potrzebami użytkowników (wewnętrznych i zewnętrznych) poprzez system obsługi metadanych oraz mechanizmy transakcyjnej interakcji pomiędzy użytkownikami przy zachowaniu bezpieczeństwa informacyjnego, 4) poprawę skuteczności zarządzania miastem i optymalizację procedur administracyjnych poprzez udostępnienie przez WGK elektronicznych usług typu back-office dla: komórek organizacyjnych Urzędu Miasta, wykonawstwa geodezyjnego oraz gestorów sieci, 5) integrację systemową pomiędzy Systemem GPUE a elektronicznym Systemem obiegu dokumentów, 6) integrację systemową pomiędzy Systemem GPUE a RSIP, 7) integrację systemową pomiędzy Systemem GPUE a systemem Ratusz F-K. W ramach projektu podjęte zostaną działania inwestycyjne, obejmujące rozbudowę infrastruktury techniczno - funkcjonalnej poprzez wdrożenie Systemu GPUE obsługującego referencyjne zbiory informacji przestrzennej WGK. Nowe rozwiązania technologiczne pozwolą na prowadzenie zbiorów danych za pomocą zintegrowanych serwisów systemowych, oraz pozwolą na ich udostępnianie w postaci elektronicznych, transakcyjnych usług geoinformacyjnych. 1.2 Opis stanu obecnego infrastruktury technicznej Zamawiającego Kluczowe procesy administracyjne Wydziału Geodezji i Kartografii podzielone są na dwa obszary dziedzinowe obsługiwane przez Referat Ewidencji Gruntów i Budynków oraz Referat Ośrodka Dokumentacji Geodezyjno - Kartograficznej. 1/53

2 Całością infrastruktury teleinformatycznej w Urzędzie Miasta Rybnika zarządza Wydział Informatyki (WI), który realizuje również zadania związane z Rybnickim Systemem Informacji Przestrzennej. Zadania te realizowane są przez Referat Systemów Informacji Przestrzennej. Wydział Informatyki zarządza wewnętrzną siecią komputerową Urzędu i sprzętem, a także oprogramowaniem i licencjami na oprogramowanie, wykorzystywanym we wszystkich jednostkach organizacyjnych całego Urzędu. Dodatkowo zarządza on również miejskim serwisem WWW w zakresie sprzętowym. W kompetencji WI znajdują się również kwestie bezpieczeństwa przetwarzanych danych. W UM ogólna architektura systemów komputerowych opiera się o architekturę klient serwer gdzie komputery podzielone są na serwery i stacje robocze. Część serwerowa sprzętu komputerowego jest wykorzystywana jako serwery plików, baz danych i innych zasobów mających szczególne znaczenia dla funkcjonowania sieci. Część serwerowa objęta jest przez WI systemem archiwizowania i backup owania danych. Wdrażany System GPUE swoje kluczowe dane musi umieszczać w części serwerowej co zapewni odpowiedni poziom bezpieczeństwa. Obecnie Wydział Geodezji i Kartografii liczy 26 stanowisk komputerowych wraz ze stanowiskami obsługi. Stanowiska te jak i całą sieć teleinformatyczną zabezpiecza centralny UPS. Dane przechowywane lokalnie na stacjach roboczych nie są zabezpieczane i odpowiada za nie bezpośrednio użytkownik stacji roboczej. 2. Organizacja techniczna Systemu GPUE 2.1 Wykaz ewidencji (rejestrów) i baz danych, które musi obsługiwać GPUE System GPUE musi obsługiwać następujące ewidencje (rejestry) i bazy danych: W.1 Baza danych ewidencji gruntów, budynków i lokali, W.2 Rejestr cen i wartości nieruchomości, W.3 Ewidencja prac geodezyjnych, W.4 Ewidencja dokumentacji geodezyjnej, W.5 Ewidencja wypożyczeń materiałów geodezyjnych, W.6 Baza danych BDOT 500, W.7 Baza danych GESUT, W.8 Ewidencja spraw ZUDP, W.9 Baza danych osnów geodezyjnych, W.10 Ewidencja faktur i zamówień, W.11 Ewidencja klientów Wydziału Geodezji i Kartografii, W.12 Ewidencja geodetów uprawnionych, W.13 Ewidencja miejscowości, ulic i adresów, W.14 Rejestr granic (miasta i obrębów ewidencyjnych), W.15 Rejestr nazw geograficznych, W.16 Ortofotomapa. 2.2 Architektura logiczna Systemu GPUE System musi zapewnić sposób komunikacji wewnętrznej pomiędzy serwisami oraz zewnętrznej z systemami zewnętrznymi zgodnie ze schematem przedstawionym na rys. 1. 2/53

3 Rysunek 1 Schemat logiczny systemu GPUE (kierunki strzałek oznaczają kierunki nawiązywania połączenia pomiędzy usługami/systemami) Sieć komputerowa UM podzielona jest na 2 strefy: 1) strefa LAN sieć wewnętrzna, 2) strefa DMZ sieć zdemilitaryzowana, która umożliwia komunikację z systemami zewnętrznymi. Komunikacja pomiędzy strefami LAN a DMZ może być inicjowana tylko i wyłącznie po stronie LAN. 3/53

4 2.3 Technologia budowy GPUE Technologie, które zostaną wykorzystane do budowy GPUE muszą spełniać następujące wymagania: W.17 System GPUE musi być zbudowany w oparciu o technologię SOA (Service Oriented Architecture) zgodnie z metodologią przetwarzania informacji przestrzennych w ramach infrastruktury korporacyjnej (Enteprise Spatial Data Infrastructure), W.18 system musi działać w oparciu o obowiązujący w UM trójwarstwowy model budowy systemów komputerowych, składający się z: 1) warstwy wewnętrznej, którą stanowi serwer centralnej bazy danych, 2) warstwy pośredniej, którą tworzą specjalistyczne aplikacje wspomagające obsługę hurtowni danych oraz pracę użytkowników, 3) warstwy zewnętrznej, stanowiącej środowisko aplikacji użytkowników. 2.4 Podział serwisów Systemu GPUE System GPUE musi składać się z dwóch zintegrowanych obszarów serwisów: 1) serwisy prowadzenia źródłowych baz danych przestrzennych (SPBD_GPUE), 2) serwisy komunikacji i współpracy z użytkownikami (SKW_GPUE). Serwisy SPBD_GPUE oraz SKW_GPUE muszą zapewnić działanie 7 aplikacji w Systemie GPUE wymienionych w punkcie niniejszego załącznika. 2.5 Wymagania ogólne dla serwisów prowadzenia źródłowych baz danych SPBD_GPUE System GPUE musi zawierać serwisy prowadzenia źródłowych baz danych przestrzennych (SPBD_GPUE) spełniające następujące wymagania ogólne: W.19 muszą zarządzać wszystkimi źródłowymi referencyjnymi bazami danych Systemu GPUE, W.20 do prowadzenia źródłowych baz danych musi być wykorzystana architektura grubego klienta, aby optymalne rozłożyć obciążenie pomiędzy serwerem bazy danych, a stacjami roboczymi operatorów, W.21 muszą gromadzić dane opisowe i geometryczne w formie zintegrowanej w zakresie wszystkich ewidencji (rejestrów) i baz danych wymienionych w punkcie 2.1 niniejszego załącznika, W.22 muszą umożliwiać gromadzenie danych historycznych w zakresie wszystkich danych opisowych i geometrycznych, W.23 muszą umożliwiać gromadzenie danych zawierających rozbieżności między treścią opisową i geometryczną w jednej bazie (dotyczy to w szczególności ewidencji gruntów i budynków) oraz umożliwiać obsługę heterogenicznych zbiorów do czasu pełnej integracji danych, W.24 muszą zawierać jednolite procedury komunikowania się na poziomie aplikacji działające niezależnie od obszaru tematycznego, W.25 muszą zapewniać realizację trzech głównych grup funkcjonalności: 1) administracji systemem, 2) edycji danych, 3) udostępniania danych. 4/53

5 2.6 Wymagania ogólne dla serwisów komunikacji i współpracy z użytkownikami SKW_GPUE System GPUE musi zawierać serwisy komunikacji i współpracy z użytkownikami (SKW_GPUE) spełniające następujące wymagania ogólne: W.26 muszą zapewniać obsługę następujących grup użytkowników / systemów: 1) jednostki wykonawstwa geodezyjnego, 2) węzły KIIP, 3) RSIP, 4) System obiegu dokumentów, 5) Ratusz F-K w zakresie faktur i opłat, W.27 muszą zapewniać komunikację (pobieranie/wymiana) ze źródłowymi bazami danych SPBD_GPUE oraz udostępniać dane w nich zawarte poprzez replikę baz danych znajdującą się na serwerze wymiany w formie umożliwiającej ich wykorzystanie przez innych użytkowników oraz systemy informatyczne w oparciu o usługi sieciowe, W.28 użytkownicy serwisów SKW_GPUE nie mogą modyfikować danych zawartych w bazach źródłowych SPBD_GPUE (takie uprawnienia mają tylko użytkownicy serwisów SPBD_GPUE), W.29 muszą zapewniać usługi udostępniania/wymiany danych i metadanych w sposób znormalizowany w oparciu o standardowe usługi sieciowe, W.30 mechanizmy udostępniania danych muszą uwzględniać istnienie różnych grup użytkowników, posiadających różny poziom uprawnień zarówno do danych jak i funkcji systemu, W.31 muszą wykorzystywać system weryfikacji uprawnień, który zapewni odpowiedni poziom zabezpieczeń w Systemie GPUE, W.32 przy każdym dostępie do zasobów za pomocą serwisów SKW_GPUE musi następować weryfikacja uprawnień użytkowników, W.33 niezależnie od wewnętrznych sposobów komunikacji SKW_GPUE z SPBD_GPUE, serwisy SKW_GPUE muszą udostępniać usługi w następujących standardach: 1) WMS, 2) WFS, 3) Portal katalogowy metadanych, W.34 muszą umożliwiać import i export danych systemu, W.35 muszą umożliwiać obsługę jednostek wykonawstwa geodezyjnego poprzez interfejs WWW oparty o usługi WebServices, W.36 muszą umożliwić integrację ze strukturami KIIP w zakresie uzgodnionym z Zamawiającym poprzez usługi WebServices (System GPUE ma wymieniać dane ze strukturami KIIP, w tym z Geoportalem prowadzonym przez Głównego Geodetę Kraju), W.37 muszą udostępniać dane dla systemu RSIP w zakresie uzgodnionym z Zamawiającym poprzez usługi WebServices lub replikę bazy danych referencyjnych, W.38 muszą zapewniać wymianę informacji z Systemem Obiegu Dokumentów oraz Ratusz F-K funkcjonującym w UM, W.39 muszą umożliwiać współpracę (wymianę danych) z systemami gestorów sieci uzbrojenia terenu poprzez interfejs WWW oparty o WebServices (WMS, WFS zgodnie z Inspire, poprzez plik shp, dbf). 2.7 Wymagania ogólne wspólne dla obu obszarów serwisów SPBD_GPUE oraz SKW_GPUE Serwisy prowadzenia źródłowych baz danych przestrzennych (SPBD_GPUE) oraz serwisy komunikacji 5/53

6 i współpracy z użytkownikami (SKW_GPUE) muszą wspólnie spełniać następujące wymagania ogólne: W.40 oba obszary serwisów muszą umożliwiać prowadzenie i publikację metadanych w oparciu o przyjęte dla realizacji GPUE standardy wymienione w punkcie 2.13 niniejszego załącznika, W.41 serwisy SPBD_GPUE muszą komunikować się z serwisami SKW_GPUE za pomocą interfejsu zbudowanego w oparciu o standardy Open Geospatial Consortium z wykorzystaniem usług Web Services, W.42 dostęp do referencyjnych danych przestrzennych Systemu GPUE musi odbywać się z uwzględnieniem obowiązujących norm i standardów wymienionych w punktach 2.13 oraz uwarunkowań prawnych wymienionych w punkcie 2.14 niniejszego załącznika, W.43 dla serwisów komunikacji pomiędzy dostawcami i odbiorcami usług przestrzennych muszą zostać zastosowane protokoły HTTP (Hypertext Transfer Protocol), W.44 w zakresie autoryzacji użytkowników należy wykorzystać protokół HTTPS (Hypertext Transfer Protocol over Secure Socket Layer), W.45 w zakresie udostępniania metadanych, serwisy GPUE muszą korzystać z rozszerzenia protokołu HTTP - protokół WebDAV (Web-based Distributed Authoring and Versioning), W.46 zabezpieczenie w procesach udostępniania danych dla użytkowników spoza UM musi być zrealizowane poprzez wykorzystanie sieci wirtualnej VPN (autoryzację RADIUS) lub protokołu SSL, W.47 serwisy Systemu GPUE muszą umożliwiać odbieranie i wysyłanie komunikatów informujących o zdarzeniach systemowych w celu umożliwienia przyszłej integracji wszystkich systemów UM. 2.8 Wymagania ogólne dotyczące usług on-line udostępnianych przez System GPUE Serwisy GPUE muszą udostępniać następujące usługi on-line: W.48 na poziomie interakcji jednostronnej serwisy GPUE muszą udostępniać usługę przyjmowania drogą elektroniczną operatów geodezyjnych w wersji numerycznej w celu ich sprawdzenia oraz kartowania, W.49 na poziomie interakcji dwustronnej serwisy GPUE muszą udostępniać następujące usługi: 1) przyjmowania i zatwierdzania zgłoszeń prac geodezyjnych drogą elektroniczną, 2) zamawiania i przekazywanie drogą elektroniczną map, 3) wydawania na wniosek elektronicznych informacji o gruntach, budynkach i lokalach z ewidencji gruntów i budynków. 2.9 Wymagania ogólne dotyczące rejestrów publicznych udostępnianych on-line przez System GPUE Serwisy GPUE muszą umożliwiać udostępnienie następujących rejestrów on-line: W.50 elektroniczna wersja ewidencji gruntów i budynków publikująca dane nie objęte ustawą o ochronie danych osobowych 6/53

7 2.10 Wymagania ogólne dotyczące mechanizmów synchronizacji bazy danych źródłowych z bazą danych wymiany Mechanizmy synchronizacji bazy danych źródłowych z bazą danych wymiany muszą spełniać następujące wymagania ogólne: W.51 System musi posiadać mechanizm zarządzania tworzeniem repliki baz danych źródłowych dla serwisów SKW_GPUE. Zakres danych repliki musi ograniczać się tylko do danych niezbędnych dla funkcjonalności określonych dla SKW_GPUE. Baza danych źródłowych i baza danych wymiany muszą znajdować się na osobnych serwerach i nie mogą być połączone w klaster, W.52 w przypadku przechowywania danych w repozytorium plikowym system musi zapewnić synchronizację niezbędnych plików pomiędzy serwerami w sieci LAN i DMZ, W.53 inicjalizacja procesu synchronizacji musi następować z podsieci LAN UM (inicjalizacja z DMZ jest niedopuszczalna), W.54 System GPUE musi umożliwiać przeprowadzenie następujących scenariuszy synchronizacji: 1) automatyczny: synchronizacja będzie wykonywana zgodnie z ustalonym wcześniej harmonogramem, 2) ręczny: w każdej chwili operator systemu musi mieć możliwość ręcznego rozpoczęcia synchronizacji, W.55 w przypadku stosowania w bazie danych wymiany widoków zmaterializowanych lub tabel pośrednich Zamawiający wymaga, aby ich aktualizacja odbywała się nie rzadziej niż raz na dobę i trwała nie dłużej niż 3 godziny 2.11 Wymagania ogólne dotyczące silnika baz danych Systemu GPUE W ramach zamówienia Wykonawca musi dostarczyć silniki baz danych Oracle Database lub równoważne (jeden dla serwera geodezyjnego oraz jeden dla serwera wymiany), które muszą spełniać następujące wymagania: W.56 licencje dla baz danych muszą umożliwiać działanie Systemu przez nieograniczony czas i na nieograniczoną liczbę stanowisk i użytkowników, W.57 muszą być otwarte (silnik musi umożliwiać zakładanie nowych tabel itp.), skalowalne i umożliwiać obsługę rozproszonych baz danych oraz zasobów plikowych, W.58 muszą przetwarzać dane transakcyjnie zachowując wysoką wydajność, W.59 muszą umożliwiać pracę wielu użytkownikom jednocześnie, W.60 muszą zapewniać wysoki poziom bezpieczeństwa danych oraz procesów ich przetwarzania, W.61 muszą umożliwiać przetwarzanie i zarządzanie dużymi zbiorami danych różnego typu, W.62 muszą umożliwiać współpracę z aplikacjami typu GIS poprzez zapis danych przestrzennych do bazy danych przechowywanych w obiektach - typ danych SDO_GEOMETRY, W.63 muszą umożliwiać indeksowanie danych przestrzennych, szczególnie w odniesieniu do dużych zasobów danych, W.64 muszą umożliwić przechowywanie danych rastrowych, W.65 muszą udostępniać mechanizm tzw. długich transakcji, W.66 muszą udostępniać mechanizmy tworzenia replik baz danych, W.67 dane muszą być przechowywane w jawnych strukturach bazodanowych, W.68 modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może 7/53

8 ich blokować do celów modyfikacji, jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych, W.69 muszą umożliwić przetwarzanie z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności, W.70 muszą posiadać możliwość zagnieżdżania transakcji musi istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej (na przykład musi być możliwy następujący scenariusz: każda próba modyfikacji tabeli X musi w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana), W.71 muszą zapewnić wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode), W.72 muszą mieć możliwość migracji zestawu znaków bazy danych do Unicode, W.73 muszą umożliwiać redefiniowania przez klienta ustawień narodowych symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych, W.74 muszą wspierać skalowanie rozwiązań opartych o architekturę trójwarstwową: możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych, W.75 muszą umożliwiać otworzenie wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych, W.76 muszą wspierać protokół XA, W.77 muszą wspierać standard JDBC 3.0, W.78 muszą być zgodne ze standardem ANSI/ISO SQL 2003 lub nowszym, W.79 muszą umożliwiać wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz dla wybranych zapytań. Musi istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL, W.80 nie mogą mieć formalnych i rzeczywistych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy), W.81 muszą zapewniać wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania powinien być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek musi być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu, W.82 procedury i funkcje składowane muszą mieć możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje muszą mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe muszą umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np.: zatwierdzanie bądź wycofanie transakcji wewnątrz procedury), W.83 muszą umożliwiać kompilację procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej), W.84 muszą obsługiwać deklarowanie wyzwalaczy (triggerów) na poziomie instrukcji DML 8/53

9 (INSERT, UPDATE, DELETE) wykonywanej na tabeli, na poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy musi umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views). W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił w/w błąd lub wyjątek, W.85 muszą posiadać możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych, W.86 bazy danych muszą pozwalać na wymuszanie złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku przekroczenia limitu nieudanych logowań, W.87 przywileje użytkowników baz danych muszą być określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu/modyfikacji tabeli, wykonania procedury). Bazy danych muszą umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników/ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych, W.88 muszą posiadać możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer bazy danych. Możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów. Możliwość integracji z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, OmniBack, ArcServer itd.). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online (hot backup), W.89 odtwarzanie danych musi umożliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych. W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników, W.90 muszą umożliwiać obsługę wyrażeń regularnych zgodną ze standardem POSIX dostępne z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych, W.91 muszą umożliwiać pracę na maszynie wyposażonej minimalnie w 2 gniazda procesorowe (ang. sockets), W.92 muszą działać na systemach 32 i 64 bitowych. Zamawiający wyjaśnia, iż zapis dotyczący dostarczenia bazy danych Oracle wynika m.in. z faktu, iż Zamawiający dąży do ujednolicenia systemów informatycznych w UM. Wszystkie rozwiązania w zakresie systemów GIS w UM oparte są właśnie na tych bazach. Rozwiązanie takie jest korzystne dla Zamawiającego z uwagi na jednolite mechanizmy wymiany danych wykorzystywane przez Zamawiającego oraz posiadanie kadry przeszkolonej w zakresie administracji, zarządzania i optymalizacji baz danych Oracle. Poprzez bazę danych równoważną Zamawiający rozumie, iż: 9/53

10 1. warunki licencji w każdym aspekcie licencjonowania są nie gorsze niż licencja Oracle, 2. nabycie licencji oprogramowania równoważnego pozwala na legalne używanie posiadanych przez Zamawiającego licencji oprogramowania Oracle, 3. funkcjonalność oprogramowania równoważnego nie może być gorsza od funkcjonalności oprogramowania Oracle, 4. oprogramowanie równoważne musi być kompatybilne i w sposób niezakłócony współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego, 5. oprogramowanie równoważne nie może zakłócić pracy środowiska systemowo-programowego Zamawiającego, 6. oprogramowanie równoważne musi w pełni współpracować z systemami już eksploatowanymi u Zamawiającego, 7. oprogramowanie równoważne musi zapewniać pełną, równoległą współpracę w czasie rzeczywistym i pełną funkcjonalną zamienność produktu z produktem Oracle. Wykonawca, który zaoferuje produkt równoważny musi udowodnić spełnienie wszystkich warunków określonych w w/w punkcie. W tym celu Wykonawca: 1. złoży wraz z ofertą nw. dokumenty: 1) pełne postanowienia licencji oprogramowania równoważnego, 2) wykaz pełnej funkcjonalności oprogramowania równoważnego, 2. dokona wspólnie z Zamawiającym instalacji, przeniesienia danych oraz testowania oprogramowania równoważnego w środowisku sprzętowo-programowym Zamawiającego, 3. w przypadku, gdy zaoferowane przez Wykonawcę równoważne oprogramowanie nie będzie właściwie współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego i/lub spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u Zamawiającego, Wykonawca pokryje wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowo-programowej Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo-programowego Zamawiającego również po odinstalowaniu oprogramowania równoważnego. W przypadku dostarczenia przez Wykonawcę bazy równoważnej szkolenia, o których mowa w pkt. 5.7 niniejszego załącznika, będą musiały również obejmować zakres z jej administracji, zarządzania i optymalizacji i będą musiały zostać przeprowadzone dla 2 pracowników Wydziału Informatyki Wymagania ogólne dotyczące interoperacyjności rozwiązań System musi zapewnić współpracę z systemami zewnętrznymi z wykorzystaniem standardowych interfejsów dostępu do danych na poziomie usług. W celu zapewnienia pełnej interoperacyjności System GPUE musi: W.93 zapewnić interoperacyjność na poziomie mechanizmu wymiany danych, W.94 zapewnić interoperacyjność na poziomie prezentacji danych (musi zapewnić taki sam sposób prezentacji danych dla obiektów tego samego typu), W.95 umożliwiać dostosowanie poszczególnych warstw danych referencyjnych do jednolitego schematu danych zgodnie z dyrektywą INSPIRE, W.96 stosować jednolite słowniki wartości atrybutów dla obiektów poszczególnych warstw, W.97 zapewnić jednolity styl prezentacji obiektów Wymagania dotyczące zgodności z normami i standardami OGC, ISO oraz krajowymi w zakresie dostępu do metadanych i udostępniania danych przestrzennych 10/53

11 System GPUE musi być zgodny z następującymi normami i standardami: W.98 ISO 19111:2007 Geographic information Spatial referencing by coordinates, W.99 OGC Simple feature access - Part 1: Common architecture 1.1.0, W.100 OGC Simple feature access - Part 2: SQL option 1.1.0, W.101 OGC Geography Markup Language 2.1.2, W.102 OGC Geography Markup Language 3.1.1, W.103 OGC Geography Markup Language 3.2, W.104 OGC Web Map Service 1.1.1, W.105 OGC Styled Layer Descriptor 1.0, W.106 OGC Web Feature Service 1.0, W.107 OGC Filter Encoding 1.1, W.108 OGC Web Coverage Service 1.0, W.109 ISO 19115:2003 Geographic information Metadata, W.110 ISO 19119:2005 Geographic information Services, W.111 ISO 19139:2007 Geographic information Metadata XML schema implementation, W.112 OGC Catalog Services Sepcification 2.0.1, W.113 ISO Metadata Application Profile for CSW (Soap + HTTP/Post binding), W.114 Wszystkie Metadane gromadzone w systemie powinny być zgodne ze standardami ISO 19115:2003, ISO 19139:2007 oraz krajowym profilem metadanych dla danych przestrzennych, zaś udostępniane usługi systemowe powinny być zgodne z normą ISO 19119: Wymagania dotyczące zgodności z przepisami prawa System GPUE musi być zgodny ze wszystkimi przepisami dotyczącymi PZGiK, INSPIRE, Infrastruktury Informacji Przestrzennej, dyrektywami i rozporządzeniami towarzyszącymi (krajowymi i unijnymi) oraz z innymi przepisami dotyczącymi przedmiotu zamówienia, a w szczególności: W.115 Ustawa z dnia 17 maja 1989 roku Prawo geodezyjne i kartograficzne (Dz. U. z 2010 r. Nr 193 poz z późn. zm.), W.116 Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 29 marca 2001 r. w sprawie ewidencji gruntów i budynków (Dz. U. z 2001 r. nr 38, poz. 454), W.117 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 9 listopada 2011 r. w sprawie standardów technicznych wykonywania geodezyjnych pomiarów sytuacyjnych i wysokościowych oraz opracowania i przekazywania wyników tych pomiarów do państwowego zasobu geodezyjnego i kartograficznego (Dz. U. z 2011 r. nr 263 poz. 1572), W.118 Rozporządzenie Rady Ministrów z dnia 10 stycznia 2012 r. w sprawie państwowego rejestru granic i powierzchni jednostek podziałów terytorialnych kraju (Dz. U. z 2012 r. poz. 199), W.119 Rozporządzenie Rady Ministrów z dnia 15października 2012 r. w sprawie państwowego systemu odniesień przestrzennych (Dz. U. z 2012 r. poz. 1247), W.120 Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 14 lutego 2012 r. w sprawie osnów geodezyjnych, grawimetrycznych i magnetycznych (Dz. U. z 2012 r. poz. 352), W.121 Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 2 kwietnia 2001 r. w sprawie geodezyjnej ewidencji sieci uzbrojenia terenu oraz zespołów uzgadniania dokumentacji projektowej (Dz. U. z 2001 r. nr 38 poz. 455), W.122 Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 16 lipca 2001 r. w sprawie zgłaszania prac geodezyjnych i kartograficznych, ewidencjonowania systemów 11/53

12 i przechowywania kopii zabezpieczających bazy danych, a także ogólnych warunków umów o udostępnianie tych baz (Dz. U. z 2001 r. Nr 78 poz. 837), W.123 Rozporządzenie Ministra Infrastruktury z dnia 19 lutego 2004 r. w sprawie wysokości opłat za czynności geodezyjne i kartograficzne oraz udzielanie informacji, a także za wykonywanie wyrysów i wypisów z operatu ewidencyjnego (Dz. U. z 2004 r. Nr 37 poz. 333), W.124 Rozporządzenie Rozwoju Regionalnego i Budownictwa z dnia 12 lipca 2001 r. w sprawie szczegółowych zasad i trybu założenia i prowadzenia krajowego systemu informacji o terenie (Dz. U. z 2001 r. Nr 80 poz. 866), W.125 Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 12 lutego 2013 r. w sprawie bazy danych geodezyjnej ewidencji sieci uzbrojenia terenu, bazy danych obiektów topograficznych oraz mapy zasadniczej (Dz. U. z 2013 r. poz. 383), W.126 Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 9 stycznia 2012 r. w sprawie ewidencji miejscowości, ulic i adresów (Dz. U z 2012 r. poz. 125), W.127 Ustawa z dnia 21 sierpnia 1997 r o gospodarce nieruchomościami (Dz. U. z 2010r Nr 102, poz. 651 z późn. zm.), W.128 Ustawa z dnia 4 marca 2010 r. o infrastrukturze informacji przestrzennej (Dz. U. z 2010 r. Nr 76 poz. 489), W.129 Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych gromadzonych w rejestrze publicznym (Dz. U. z 2005 r. Nr 205, poz. 1692), W.130 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. z 2012 r. poz.526), W.131 Rozporządzenia Rady Ministrów z dnia 15 grudnia 1998 r. w sprawie szczegółowych zasad prowadzenia, stosowania i udostępniania krajowego rejestru urzędowego podziału terytorialnego kraju oraz związanych z tym obowiązków organów administracji rządowej i jednostek samorządu terytorialnego (Dz. U. z 1998 r. Nr 157, poz z późn. zm.), W.132 Ustawa z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010r. Nr 113 poz. 759 z późn. zm.), W.133 Ustawa z dnia 29 czerwca 1995 r. o statystyce publicznej (Dz. U. z 2012 r. poz. 591), W.134 Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2005 r. Nr 64 poz.565 z późn.zm.), W.135 Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. poz. 926), W.136 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. z 2004 r. Nr 100, poz. 1024), W.137 Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. z 2001 r. Nr 128, poz. 1402), W.138 Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz. U z 2000 r. Nr 98 poz.1071 z późn.zm.), W.139 Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. z 2002 r. Nr.144 poz.1204 z późn.zm.), W.140 Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach" (Dz. U. z 2011 r. Nr 12 poz. 698), W.141 Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z 2001 r. Nr 130 poz.1450), W.142 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października /53

13 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. z 2006 r. Nr.206, poz.1517), W.143 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. z 2011r. nr 206 poz. 1216). Przy realizacji przedmiotu zamówienia Wykonawcę wiązać będą przepisy aktów prawnych, które wejdą w życie w okresie jego realizacji, nie później jednak niż 60 dni przed terminem realizacji przedmiotu zamówienia. W szczególności dotyczy to projektów przepisów, które obejmują projekty aktów prawnych znajdujących się w procesie legislacyjnym: 1) rozporządzenia Ministra Administracji i Cyfryzacji zmieniające rozporządzenie w sprawie ewidencji gruntów i budynków, 2) rozporządzenia Ministra Administracji i Cyfryzacji w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego. Jeżeli którykolwiek z projektów aktów prawnych, o których mowa powyżej, nie stanie się aktem obowiązującym w terminie określonym powyżej (60 dni), Wykonawcę wiązać będzie ostatnia wersja projektu tego aktu, udostępniona przez Zamawiającego nie później niż 90 dni przed umownym terminem realizacji przedmiotu zamówienia. Działanie Systemu GPUE oraz dane w nim zawarte muszą być zgodne z przepisami prawa obowiązującymi w dniu odbioru końcowego. W sytuacji gdy przepisy przestały obowiązywać i nie ustanowiono nowych, działanie Systemu GPUE oraz dane w nim zawarte muszą być zgodne z przepisami prawa ostatnio obowiązującymi, z wyjątkiem przepisów dotyczących EGiB Szczegółowe minimalne wymagania funkcjonalne Systemu GPUE Podział systemu na aplikacje funkcjonalne Pod względem funkcjonalnym GPUE musi się składać z następujących 7 aplikacji: W.144 Aplikacja do administracji - dla administratorów Systemu z Wydziału Informatyki, W.145 Aplikacja do edycji - dla użytkowników z Wydziału Geodezji i Kartografii, W.146 Aplikacja dla geodety dla jednostek wykonawstwa geodezyjnego i gestorów sieci, W.147 Aplikacja do podglądu dla użytkowników z innych wydziałów Urzędu Miasta, W.148 Aplikacja do komunikacji z RSIP, W.149 Aplikacja do komunikacji z Systemem obiegu dokumentów i Ratusz F-K, W.150 Aplikacja do komunikacji z KIIP Wymagania funkcjonalne dla aplikacji do administracji Aplikacja do administracji musi być wykonana zgodnie z następującymi wymaganiami: W.151 musi działać w architekturze klient-serwer, W.152 musi działać jako aplikacja WWW (w oknie przeglądarki) lub samodzielna aplikacja działająca na systemie Windows, W.153 musi działać w sieci intranet UM (strefa LAN). 13/53

14 Aplikacja do administracji musi spełniać niżej wymienione funkcjonalności: W.154 musi wymagać autoryzowanego dostępu do zasobów systemu - każdy użytkownik musi posiadać własny login i hasło do aplikacji i bazy (aplikacja musi zapewniać integrację z Active Directory - po zalogowaniu do Active Directory System GPUE nie wymaga ponownego zalogowania do Systemu). Użytkownik na podstawie poświadczeń systemu Windows jest automatycznie rozpoznawany w Systemie, W.155 musi umożliwiać administratorom systemu możliwość zarządzania i parametryzowania Systemu GPUE, W.156 musi umożliwiać zarządzanie systemem w pełnym zakresie (LAN, DMZ), W.157 musi umożliwiać dodawanie, edycję i konfigurację raportów i dokumentów generowanych w systemie, W.158 musi umożliwiać: 1) tworzenie użytkowników, 2) edycję użytkowników, 3) nadawanie uprawnień w systemie, 4) nadawanie uprawnień w bazie danych, 5) zarządzanie użytkownikami systemu, 6) zarządzanie rolami użytkowników, 7) zarządzanie zasobami, 8) zarządzanie nadawaniem uprawnień do funkcji oraz zasobów zgromadzonych w systemie, 9) rejestrację użytkowników, 10) utworzenie w systemie użytkownika anonimowego, W.159 musi umożliwiać konfigurowanie dostępu do danych wykorzystywanych przez serwisy SPBD_GPUE i SKW_GPUE, W.160 musi umożliwiać konfigurację importu i eksportu danych (np. poprzez określanie zakresów danych, formatów danych itp.), W.161 musi umożliwiać monitorowanie i analizę bieżącego stanu Systemu w zakresie: 1) przeglądanie wykazu zainstalowanych aplikacji i komponentów GPUE (numery wersji, daty ostatnich aktualizacji, itp.), 2) wylistowanie wszystkich danych przestrzennych załadowanych do baz danych systemu wraz ze statystykami ilości obiektów, dat ostatniej aktualizacji, itp., 3) wgląd do rejestru wykonywanych zasileń (np.: plików SWDE, plików SHP+DBF, plików XLS) prezentując, co najmniej informacje o: momencie inicjalizacji i czasu trwania kolejnych zasileń, nazwach plików, statusach prawidłowości przebiegu procesów zasilania, a w przypadku wystąpienia błędów stosownych komunikatów wspierających administratorów w dokonywaniu diagnoz, 4) monitorowania operacji wykonywanych przez poszczególnych pracowników wydziału, W.162 musi umożliwić tworzenie raportów pozwalających na kontrolę wydajności pracy poszczególnych pracowników w zakresie uzgodnionym z Zamawiającym, W.163 musi umożliwiać centralne zarządzanie wprowadzaniem aktualizacji i poprawek, W.164 musi umożliwiać konfigurowanie uprawnień dostępu do danych w zakresie: 1) określanie, zakresu dostępu do danych dla poszczególnych ról systemowych, 2) określanie sposobu prezentacji danych na mapach, W.165 musi umożliwiać konfigurowanie metadanych udostępnianych dla portalu katalogowego, W.166 musi umożliwiać monitorowanie działania Systemu kontrola prawidłowości działania wszystkich elementów Systemu, reagowanie na sytuacje wyjątkowe, W.167 musi zapewnić wykonywanie kopii zapasowej lokalnych repozytoriów danych i metadanych z wykorzystaniem dedykowanych do tego celu mechanizmów Systemu 14/53

15 GPUE, W.168 musi zapewnić spójność pomiędzy danymi gromadzonymi w Systemie, a metadanymi poprzez: 1) wyszukiwanie i automatyczne usuwanie metadanych dla niedostępnych już zbiorów danych zatwierdzeniu przez administratora systemu, 2) tworzenie nowych zbiorów metadanych w przypadku udostępnienia nowych zbiorów danych. Wszystkie zmiany muszą zostać zarejestrowane w systemie oraz przedstawione w postaci raportu, W.169 musi zapewnić wykrywanie niezgodności pomiędzy danymi Systemu, a opisującymi je metadanymi (np. nieprawidłowa identyfikacja układu odniesienia, nieprawidłowy zakres danych, data aktualności), W.170 musi umożliwiać przeglądanie niektórych działań w Systemie w celach informacyjnych i statystycznych dostępnych dla operatora i administratora w tym minimum: 1) statystyki odwiedzin, to jest liczby odwiedzin wszystkich użytkowników Systemu z podziałem na role, w tym także użytkowników anonimowych, 2) lista aktualnie zalogowanych użytkowników, W.171 musi umożliwiać definiowanie własnych statystyk na podstawie danych dostępnych w Systemie GPUE, W.172 musi umożliwiać generowanie wszystkich raportów oraz wykresów o stanie Systemu na podstawie statystyk systemowych w formatach.doc,.pdf, xls, W.173 musi umożliwiać konfigurowanie niestandardowych pól informacyjnych, dla wszystkich obiektów Systemu GPUE, W.174 musi umożliwiać konfigurację czasu po upływie którego dane automatycznie generowane dla wykonawców prac geodezyjnych będą automatycznie usuwane z serwera wymiany, W.175 musi umożliwiać konfigurację zakresu i zawartości danych automatycznie generowanych dla wykonawców prac geodezyjnych na serwerze wymiany, W.176 musi umożliwiać konfigurację formatu, zakresu, miejsca przechowywania pliku wymiany (XML) do synchronizacji z Systemem obiegu dokumentów, W.177 musi umożliwiać konfigurację parametrów wymiany z Ratusz F-K (wymiana poprzez plik wymiany danych, struktura pliku zostanie udostępniona Wykonawcy po podpisaniu umowy) w zakresie: księga rachunkowa (oddział), rejestr w księdze rachunkowej, strony konta księgowego (konto winien, konto ma), dysponent środków, klasyfikacja (wydatki, dochody), symbol dokumentu budżetowego (DBStrona, DBStronaWn), VAT (wartość VAT, konto dla VAT), ścieżka eksportu, klasyfikacja budżetowa (dział, rozdział, paragraf, pozycja), W.178 musi umożliwiać konfigurację zakresu danych udostępnianych do KIIP, W.179 musi umożliwiać konfigurowanie dostępu do metadanych Systemu, w ramach edycji metadanych, dla poszczególnych użytkowników, W.180 musi umożliwiać tworzenie nowych obiektów, łącznie z możliwością definiowania atrybutów opisowych, graficznych, symboliki, etykiet i opisów na mapie Wymagania funkcjonalne dla aplikacji do edycji Aplikacja do edycji musi być wykonana zgodnie następującymi wymaganiami: W.181 musi być utworzona w oparciu o architekturę klient-serwer, W.182 aplikacja kliencka musi działać w architekturze grubego klienta w formie aplikacji Windows MDI(Multi Document Interface), W.183 musi działać w sieci intranet (LAN) UM, 15/53

16 W.184 musi posiadać środowisko graficzne do generowania i przedstawiania map. Aplikacja do edycji musi posiadać wszystkie niżej wymienione funkcjonalności: a) funkcjonalność aplikacji do edycji w zakresie wszystkich obsługiwanych ewidencji (rejestrów) i baz danych: W.185 musi umożliwiać wyszukiwanie i aktualizację danych, W.186 musi umożliwiać prowadzenie pełnej edycji danych mapowych i opisowych przez uprawnionych użytkowników, W.187 musi umożliwiać generowanie map, wprowadzanie zmian geometrycznych i manipulowanie obiektami geometrycznymi na podstawie danych systemowych za pomocą dedykowanego środowiska graficznego, W.188 musi wymagać autoryzowanego dostępu do zasobów Systemu - każdy użytkownik musi posiadać własny login i hasło do aplikacji i bazy (aplikacja musi zapewniać integrację z Active Directory - po zalogowaniu do Active Directory System GPUE nie wymaga ponownego zalogowania do Systemu ). Użytkownik na podstawie poświadczeń systemu Windows jest automatycznie rozpoznawany w Systemie, W.189 musi umożliwiać identyfikację obiektu poprzez: 1) wybór z wykazu obiektów, 2) wyszukiwanie po zadanych wartościach atrybutów, 3) wskazanie obiektu na mapie, W.190 musi umożliwiać przechowywanie i udostępnianie informacji o metodzie pozyskania punktu (np. pomiar, skanowanie, konstrukcja, metoda nieznana) dla każdego z punktów mapy, W.191 musi przechowywać i udostępniać informacje dotyczące daty utworzenia i modyfikacji danego obiektu oraz informacje o użytkownikach, którzy utworzyli i zmodyfikowali dany obiekt, W.192 musi umożliwiać wprowadzanie i przechowywanie informacji o wszystkich nr KERG dla każdego obiektu mapy (w przypadku kilku pomiarów tego samego obiektu musi istnieć możliwość wprowadzenia kilku nr KERG), W.193 aplikacja musi umożliwiać prezentację wybranego obiektu na mapie z szerokimi możliwościami modyfikacji sposobu wyświetlania (zmiana wyglądu obiektu na mapie), W.194 musi umożliwić edycję metadanych przez pracowników Wydziału Geodezji i Kartografii w zakresie posiadanych uprawnień, W.195 musi posiadać mechanizmy zabezpieczania właściwej konstrukcji i integralności obiektów (z kontrolą geometrii i topologii) podczas procesów wprowadzania danych aktualizacyjnych i edycji obiektów, uwzględniając przy tym obiekty powiązane topologicznie oraz obiekty zintegrowane. Metody wprowadzania i aktualizacji obiektów muszą umożliwiać: 1) otwieranie, zamykanie i cofanie zmian, 2) usuwanie obiektów (np. działka w działce), 3) dzielenie obiektów (np. podział działki), 4) dodawanie i odejmowanie punktów z obiektów złożonych (powierzchniowych i liniowych), 5) uzupełnianie i edytowanie danych w niestandardowych polach informacyjnych konfigurowanych z poziomu aplikacji do administracji, W.196 musi zapewnić następujące sposoby wprowadzania obiektów geometrycznych na podstawie dokumentacji geodezyjnej oraz konstrukcji pomocniczych: 1) na podstawie współrzędnych, 2) na podstawie miar, 16/53

17 3) rysowanie ortogonalne, 4) rysowanie biegunowe, 5) digitalizacja rastra, 6) na przedłużeniu linii, 7) na przecięciu linii, 8) rzutowanie punktów na linię, 9) na przecięciu okręgów o zadanym promieniu, W.197 musi umożliwiać sygnalizowanie (np. poprzez generowanie raportów dla wszystkich zgłoszeń lub dla wybranego wykonawcy prac) sytuacji w których zbliża się/minął termin oddania wyników prac geodezyjnych do zasobu. System musi umożliwiać automatyczne generowanie informacji i prezentowanie jej operatorowi Systemu oraz wysyłanie jej do wykonawcy prac za pośrednictwem poczty elektronicznej, W.198 musi umożliwiać konfigurację i edycję słowników przez uprawnionego użytkownika, W.199 musi umożliwiać wykrywanie potencjalnie zdublowanych wartości słownikowych, W.200 musi umożliwiać prezentację ortofotomapy, W.201 musi umożliwiać przedstawianie obiektów graficznych na tle ortofotomapy. b) szczegółowa funkcjonalność aplikacji do edycji w zakresie prowadzenia baz danych ewidencji gruntów, budynków i lokali (EGiB): W.202 musi umożliwiać wykonywanie wszystkich zadań związanych z prowadzeniem EGiB (w tym wprowadzanie zmian geometryczno-opisowych) w całym ich zakresie. Niedopuszczalne jest używanie kilku środowisk aplikacyjnych w celu wykonania całości zmiany, W.203 musi zawierać mechanizmy kontroli poprawności topologicznej obiektów ewidencyjnych, pozwalające na wykrywanie, sygnalizację i korygowanie błędów w topologii obiektów, W.204 musi zawierać mechanizmy kontroli i sprawdzania poprawności danych w następującym zakresie: 1) zgodności udziałów własności i władania, 2) zgodności klaso-użytków oraz ich powierzchni w rejestrze i na mapie, 3) kontroli prac w toku na obszarze objętym zmianą ewidencyjną, W.205 musi zawierać mechanizmy umożliwiające jednoczesne wprowadzanie zmian przedmiotowych i podmiotowych w tej samej jednostce rejestrowej przez jednego operatora, W.206 musi umożliwiać wprowadzanie udziału podmiotu w sposób znakowy tak, aby możliwy był zapis np.: 1/2 z 1/8 oraz automatycznie przeliczać taki zapis na wartość liczbową w postaci ułamka, W.207 musi umożliwiać sumowanie wartości ułamkowych przynajmniej do 10 miejsc po przecinku, W.208 musi umożliwiać blokowanie w słownikach pozycji, które mają charakter historyczny i nie mogą być przypisywane do nowo wprowadzanych obiektów, W.209 musi umożliwiać powiązanie każdego zarejestrowanego w systemie dokumentu, będącego podstawą wprowadzenia zmiany ewidencyjnej, ze źródłem jego pochodzenia, np. akt notarialny z nazwą kancelarii notarialnej, W.210 musi umożliwiać seryjną rejestrację zmian ewidencyjnych poprzez podpowiadanie ostatnio wprowadzonych danych dla całej serii rejestrowanych zmian, W.211 musi podpowiadać grupy rejestrowe dla podmiotów, W.212 musi umożliwiać wpisywanie uwag do podmiotu i przedmiotu w zakresie rejestru gruntu, budynku i lokalu z możliwością ich ukrycia przy generowaniu dokumentów, W.213 musi umożliwiać wpisywanie adresów do korespondencji z możliwością ich ukrycia przy 17/53

18 generowaniu dokumentów, W.214 metryka zmiany musi zawierać datę wpływu dokumentu będącego podstawą zmiany, W.215 musi umożliwiać przypisywanie budynków do innych działek bez utraty danych o lokalach wyodrębnionych w tym budynku, W.216 musi umożliwiać anulowanie zmiany na podstawie dokumentu prawnego uchylającego wcześniejszą prawomocną decyzję w taki sposób, aby można było ponownie wprowadzić działkę o numerze wcześniej wykorzystywanym przez działkę przeniesioną przedmiotową zmianą do historii, np.: w wyniku podziału, W.217 musi umożliwiać modyfikację jawnego identyfikatora obiektu nie powodując utraty dostępu do dotychczasowej historii tego obiektu. Jawny identyfikator obiektu w EGiB nie może być identyfikatorem rekordu w bazie danych, W.218 musi traktować małżeństwo jako jeden obiekt, którego składnikami są dwie osoby o różnych płciach, W.219 musi traktować podmiot grupowy jako jeden obiekt, złożony co najmniej z dwóch różnych podmiotów, w tym osób fizycznych, osób prawnych, małżeństw i innych podmiotów grupowych, W.220 musi umożliwiać automatyczne wyliczenie nierozdysponowanego udziału w przypadku, gdy w jednostce rejestrowej gruntu jest kilku wieczystych użytkowników o łącznej wartości udziału mniejszej od 1/1 - system wylicza i wstawia na żądanie operatora brakującą część udziału osobie gospodarującej zasobem nieruchomości, W.221 musi umożliwiać automatyczne generowanie liczby kolejnego małżeństwa, np. M11, dopisywanego do jednostki gruntowej jako współwłaściciela bądź wieczystego użytkownika, W.222 musi umożliwiać zapis danych z błędnymi udziałami w gruncie poprzedzony odpowiednią informacją o niezgodności, W.223 musi umożliwiać podłączenie do zmiany cyfrowych, bądź przekształconych do postaci cyfrowej dokumentów, W.224 musi umożliwiać generowanie następujących raportów: 1) rozbieżności dotyczących zgodności klaso-użytków, działek, budynków w rejestrze i na mapie, w zakresie ich oznaczeń i powierzchni, 2) błędów w ramach danych podmiotowych i przedmiotowych, 3) zestawienie gruntów dla wybranego podmiotu, 4) zestawienie budynków dla wybranego podmiotu, 5) zestawienie wybranych użytków dla obrębu, działki, podmiotu, 6) zestawienie budynków o określonej funkcji dla obrębu, działki, podmiotu, 7) zestawienie gruntów o określonym sposobie użytkowania, 8) zestawienie gruntów dla wybranego podmiotu posiadającego określone prawo do gruntu, 9) historii zmian z wybranego przedziału czasu lub stan na dany dzień według podmiotu i przedmiotu, 10) określających ilość i rodzaj wygenerowanych dokumentów z podziałem na osoby generujące, 11) określenie ilości dokumentów generowanych dla instytucji typu ZUS, komornik, 12) wykazu rocznego (zbiorczych zestawień) danych dotyczących gruntów, budynków i lokali, 13) określających ilość i rodzaj wprowadzonych zmian ewidencyjnych przez konkretnego operatora z rozbiciem na dane przedmiotowe i podmiotowe, 14) określających ilości materiałów wydanych do zgłoszonych prac geodezyjnych i kartograficznych z uwzględnieniem ich rodzaju, W.225 musi umożliwiać rejestrowanie w systemie zapytań o nieruchomości będące we władaniu 18/53

19 danej listy osób oraz automatyczne generowanie odpowiedzi w postaci plików w formacie dokumentu tekstowego, W.226 musi umożliwiać wyszukiwanie informacji po wszystkich atrybutach obiektów np.: numer działki, numer KW, właściciel/władający, KERG, adres, W.227 musi umożliwiać wyszukiwanie wszystkich wystąpień danej osoby fizycznej, łącznie z jej wystąpieniami jako składnika małżeństwa, podmiotu grupowego oraz małżeństwa stanowiącego składnik podmiotu grupowego, W.228 musi umożliwiać wyszukiwanie informacji w bazie danych za pomocą kreatora zapytań SQL z poziomu aplikacji, W.229 musi umożliwiać sporządzanie wypisów z rejestru gruntów, budynków i lokali (pełnych jak i uproszczonych), na wybrany dzień z możliwością określenia zakresu informacji objętych wypisem, dla: 1) zdefiniowanego obszaru określonego za pomocą dowolnego wielokąta, 2) wybranych działek, 3) wybranych nieruchomości, 4) właścicieli, 5) władających, 6) KW, 7) rejestrów, 8) jednostek rejestrowych, W.230 musi umożliwiać sporządzanie wypisów z rejestru gruntów z możliwością generowania bądź ukrycia informacji o wartości nieruchomości pochodzącej z RCiWN, W.231 musi umożliwiać sporządzanie wyrysów z mapy ewidencji gruntów i budynków z następującymi możliwościami: 1) wybrania daty w celu generowania wyrysów archiwalnych na wybrany dzień, 2) wybrania rodzaju obiektów na wyrysie, 3) wybrania zakresu informacji objętych wyrysem (zdefiniowany obszar, wybrane działki), W.232 musi umożliwiać eksport danych opisowych i geometrycznych (zarówno w pełnym zakresie jak i wybranym przez użytkownika) w następujących formatach: 1) SWDE z możliwością określania zakresów obszarowych eksportowanych danych np. gmina, jednostka ewidencyjna, obręb, oraz określenia typów obiektów objętych eksportem wraz z możliwością eksportu danych aktualnych na wybrany dzień, 2) SWDE z możliwością eksportu pełnego, 3) SWDE metodą różnicową, 4) SWDE dla gruntów, budynków i lokali - zestawień z RCiWN na potrzeby GUS, 5) SHP + DBF, 6) TXT. Eksport do formatu SWDE ma być generowany z zachowaniem stałych identyfikatorów, W.233 musi umożliwiać import i eksport danych geometryczno-opisowych do pliku w formacie GML. Jeśli w trakcie trwania projektu nastąpią zmiany w przepisach, Wykonawca dostosuje mechanizm importu i eksportu do formatu GML zgodnie z przepisami, W.234 musi umożliwiać eksport danych geometrycznych do plików: DXF, DGN, TXT, W.235 musi umożliwiać import danych opisowych i geometrycznych z plików zapisanych w następujących formatach: SWDE (z zachowaniem historii zmian), SHP + DBF, W.236 musi umożliwiać import danych geometrycznych z plików zapisanych w następujących formatach: DXF, DGN, TXT, 19/53

20 c) szczegółowa funkcjonalność aplikacji do edycji w zakresie prowadzenia baz danych BDOT500 oraz prowadzenia baz danych GESUT W.237 musi umożliwiać wykonywanie wszystkich zadań związanych z prowadzeniem bazy danych BDOT500 oraz GESUT w całym ich zakresie z poziomu jednego programu. Niedopuszczalne jest używanie kilku środowisk aplikacyjnych w celu wykonania całości zmiany, W.238 musi umożliwiać wizualizację i wydruk danych z baz danych BDOT500 i GESUT w postaci mapy zasadniczej o pełnej treści lub treści określonej przez użytkownika w skali 1:500 1:5000, W.239 musi umożliwiać edycję mapy zasadniczej, W.240 musi stosować mechanizmy uniemożliwiające jednoczesne wprowadzanie kilku zmian na tych samych obiektach mapy, W.241 musi umożliwiać buforowanie zmian geometrycznych dotyczących ewidencji gruntów i budynków z możliwością ich zatwierdzenia i wprowadzenia do bazy dopiero po wydaniu decyzji zatwierdzającej, W.242 musi umożliwiać pokazanie na mapie obiektów niezatwierdzonych, W.243 musi umożliwiać wczytywanie punktów z pliku tekstowego oraz ich zapis do bazy danych, W.244 musi umożliwiać przeprowadzanie transformacji obiektów geometrycznych w zakresie współrzędnych punktów pomiędzy układami współrzędnych z uwzględnieniem poprawek Hausbrandta, W.245 musi zapewniać kontrolę poprawności topologicznej i poprawności atrybutów wprowadzanych obiektów oraz sygnalizację błędów w postaci listy sprzężonej z miejscem występowania na mapie, W.246 musi umożliwiać automatyczną obsługę kroju sekcyjnego i godeł map w skalach 1:500-1:5000 dla układów 2000 i 1965, W.247 musi umożliwiać niezależne prowadzenie redakcji mapy dla skali 1:500 oraz 1:5000, W.248 musi umożliwiać automatyczną generalizację treści mapy oraz dostosowanie symboliki w zależności od wybranej skali (1:500-1:5000), W.249 musi umożliwiać generowanie ramek sekcyjnych i dowolnych opisów pozaramkowych określonych przez użytkownika wraz z mechanizmami automatycznego wypełniania opisu i możliwością modyfikacji, W.250 musi umożliwiać automatyczne docinanie elementów mapy do formatu rysunku bądź wskazanego zakresu, W.251 musi umożliwiać wizualizację danych ze zgłoszeń prac geodezyjnych i kartograficznych, (wizualizację mapy zakresów prac), W.252 musi zawierać narzędzia kontroli plików różnicowych przekazanych przez wykonawców prac geodezyjnych i kartograficznych do wsadowej aktualizacji zasobu zapewniające: 1) wierny import danych utworzonych w wyniku prac geodezyjnych i kartograficznych, z zachowaniem położenia, redakcji, justyfikacji, symboliki, atrybutów opisowych obiektów mapy, 2) zabezpieczenie przed utratą elementów lub atrybutów w momencie zasilenia mapy, 3) możliwość graficznej komparacji zawartości pliku na tle odpowiedniego wycinka aktualnej mapy, 4) możliwość wyróżnienia wybranymi kolorami elementów mapy, które zostały dodane, zmodyfikowane lub usunięte jeszcze przed zapisem zmian do bazy danych, 5) kontrolę (przed zapisem do bazy) poprawności topologicznej danych dodanych bądź zmodyfikowanych w plikach oddanych przez wykonawcę pracy geodezyjnej 20/53