OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 Załącznik nr 4 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Województwa Kujawsko Pomorskiego. 1

2 1 SPIS TREŚCI 1 SPIS TREŚCI DEFINICJE I SKRÓTY UŻYTE W OPISE PRZEDMIOTU ZAMÓWIENIA OPIS PRZEDMIOTU ZAMÓWIENIA ZAKRES RZECZOWY REALIZOWANEGO PROJEKTU WYMAGANIA OGÓLNE DOTYCZĄCE PRZEDMIOTU ZAMÓWIENIA WYMAGANIA PRAWNE Prawo dziedzinowe Prawo cywilne i administracyjne Prawo dotyczące rejestrów publicznych WYMAGANIA DOTYCZĄCE WDROŻENIA WYMAGANIA W ZAKRESIE HARMONOGRAMU WYMAGANIA DOTYCZĄCE SZKOLEŃ Szkolenia dla użytkowników systemu Szkolenia dla administratorów systemu WYMAGANIA DOTYCZĄCE LICENCJONOWANIA WYMAGANIA DOTYCZĄCE GWARANCJI SYSTEMU Serwis gwarancyjny systemu Serwis pozagwarancyjny systemu WYMAGANIA DOTYCZĄCE SPRZĘTU KOMPUTEROWEGO WARUNKI TECHNICZNE REALIZACJI PRZEDMIOTU WYMAGANIA TECHNOLOGICZNE WYMAGANIA DOTYCZĄCE WYDAJNOŚCI I POJEMNOŚCI WYMAGANIA DOTYCZĄCE BEZPIECZEŃSTWA WYMAGANIA DOTYCZĄCE HARMONIZACJI I INTEROPERACYJNOŚCI ZBIORÓW DANYCH PRZESTRZENNYCH I USŁUG WYMAGANIA DOTYCZĄCE ARCHITEKTURY SYSTEMU OGÓLNE WYMAGANIA FUNKCJONALNE SYSTEMU WYMAGANIA OGÓLNE DOTYCZĄCE SYSTEMU WYMAGANIA OGÓLNE DOTYCZĄCE REJESTRÓW I EWIDENCJI SYSTEMU WYMAGANIA OGÓLNE DOTYCZĄCE E-USŁUG SZCZEGÓŁOWE WYMAGANIA FUNKCJONALNE MODUŁÓW DZIEDZINOWYCH SYSTEMU MODUŁ ZARZĄDZANIA SYSTEMEM REFERENCYJNYM MODUŁ ZARZĄDZANIA INFRASTRUKTURĄ DROGOWĄ MODUŁ ZARZĄDZANIA INFRASTRUKTURĄ MOSTOWĄ MODUŁ ZARZĄDZANIA STANEM PRAWNYM ULIC I DRÓG MODUŁ ZARZĄDZANIA ORGANIZACJĄ RUCHU MODUŁ ZAJĘCIA PASA DROGOWEGO MODUŁ ZARZĄDZANIA OBJAZDAMI DRÓG MODUŁ ZARZĄDZANIA UTRZYMANIEM BIEŻĄCYM MODUŁ ZARZĄDZANIA ROBOTAMI BUDOWLANYMI MODUŁ ZARZĄDZANIA NAWIERZCHNIĄ DROGOWĄ

3 8.11 MODUŁ ZARZĄDZANIA NATĘŻENIEM RUCHU DROGOWEGO MODUŁ ZARZĄDZANIA DOKUMENTACJĄ MODUŁ ZARZĄDZANIA TERMINAMI TERMINARZ DROGOWY MODUŁ ZARZĄDZANIA MOBILNĄ PRACĄ W TERENIE MODUŁ MONITORINGU SIECI DRÓG WOJEWÓDZKICH WOJEWÓDZTWA Stacje Monitoringu Wizyjnego Inteligentny System Transportowy (ITS) Wymagania funkcjonalne dotyczące systemu informatycznego zarządzania systemem ITS Szczegółowe wymagania dotyczące System informatycznego ITS Szczegółowe uwarunkowania techniczne dla urządzeń umieszczanych w pasie drogowym w ramach projektu MODUŁ ZARZĄDZANIA GPS I UTRUDNIENIAMI DROGOWYMI System zarządzania GPS w Zimowym Utrzymaniu Dróg System zarządzania GPS we flocie samochodowej System zarządzania utrudnieniami drogowymi SZCZEGÓŁOWE WYMAGANIA FUNKCJONALNE PODSYSTEMU ZARZĄDZANIA INFORMACJĄ SERWER MAP KOMPONENT MAPOWY Wymagania komponentu mapowego po stronie klienta Wymagania dotyczące komponentu mapowego po stronie serwera GEOPORTAL INTRANET GEOPORTAL INTERNET SZCZEGÓLOWE WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA NARZĘDZIOWEGO Oprogramowanie bazodanowe Stanowisko analityczne POZYSKANIE DANYCH DO SYSTEMU ZARZĄDZANIA INFRASTURKTURĄ DROGOWĄ SYSTEM REFERENCYJNY STAN PRAWNY ULIC I DRÓG INFRASTRUKTURA DROGOWA I MOSTOWA PRZEGLĄD OKRESOWY (5 LETNI) SZCZEGÓŁOWE WYMAGANIA SPRZĘTU KOMPUTEROWEGO I OPROGRAMOWANIA SYSTEMOWEGO SPRZĘT KOMPUTEROWY I OPROGRAMOWANIE SYSTEMOWE SCHEMAT POŁĄCZEŃ SERWERÓW KOLOKACJA SERWERÓW SYSTEMOWYCH

4 2 DEFINICJE I SKRÓTY UŻYTE W OPISE PRZEDMIOTU ZAMÓWIENIA W opisie przedmiotu zamówienia użyto następujące definicje i skróty: 1. Architektura systemu teleinformatycznego opis składników systemu teleinformatycznego, powiązań i relacji pomiędzy tymi składnikami; 2. Autentyczność właściwość polegającą na tym, że pochodzenie lub zawartość danych opisujących obiekt są takie, jak deklarowane; 3. Baza danych zbiór danych lub jakichkolwiek innych materiałów i elementów zgromadzonych według określonej systematyki lub metody, indywidualnie dostępnych w jakikolwiek sposób, w tym środkami elektronicznymi, wymagający istotnego, co do jakości lub ilości, nakładu inwestycyjnego w celu sporządzenia, weryfikacji lub prezentacji jego zawartości, 4. Dane wartości logiczne, liczbowe, tekstowe, jakościowe lub ich zbiory, które można rozpatrywać w powiązaniu z określonymi zasobami lub w oderwaniu od jakichkolwiek zasobów, podlegające przetwarzaniu w toku określonych procedur; 5. Dane typu on-line dane dostępne w czasie rzeczywistym tzn. natychmiast po wprowadzeniu do określonego modułu systemu. 6. Dane typu off-line - dane pochodzące z migracji z innych modułów systemu, dostępne w czasie zdefiniowanym przez administratora systemu, np. z opóźnieniem 8 godzinnym. 7. Dane referencyjne dane opisujące cechę informacyjną obiektu pierwotnie wprowadzone do rejestru publicznego w wyniku określonego zdarzenia, z domniemania opatrzone atrybutem autentyczności; 8. Dostępność właściwość określającą, że zasób systemu teleinformatycznego jest możliwy do wykorzystania na żądanie, w założonym czasie, przez podmiot uprawniony do pracy w systemie teleinformatycznym; 9. Ewidencja rejestr wraz z określonymi procedurami aktualizacji, którego atrybuty mogą stanowić referencję do obiektów w innych rejestrach i ewidencjach; 10. Ewidencji gruntów i budynków (katastrze nieruchomości) rozumie się przez to jednolity dla kraju, systematycznie aktualizowany zbiór informacji o gruntach, budynkach i lokalach, ich właścicielach oraz o innych osobach fizycznych lub prawnych władających tymi gruntami, budynkami i lokalami; 4

5 11. GML język znaczników geograficznych, oparty na formacie XML, o którym mowa w przepisach wydanych na podstawie art. 18 pkt. 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, przeznaczony do zapisu danych przestrzennych w celu ich wymiany między systemami informatycznymi; 12. Harmonizacji zbiorów danych rozumie się przez to działania o charakterze prawnym, technicznym i organizacyjnym, mające na celu doprowadzenie do wzajemnej spójności tych zbiorów oraz ich przystosowanie do wspólnego i łącznego wykorzystywania. 13. Integralność właściwość polegającą na tym, że zasób systemu teleinformatycznego nie został zmodyfikowany w sposób nieuprawniony; 14. Informacja dane, które dostarczają opisu właściwości lub stanu wybranych obiektów lub opisują relacje pomiędzy obiektami lub wartościują poszczególne obiekty lub opisują stan układu obiektów należących do pewnego zbioru w odniesieniu do innego układu; 15. Informatyczny nośnik danych materiał lub urządzenie służące do zapisywania, przechowywania i odczytywania danych w postaci cyfrowej; 16. Interoperacyjność zdolność różnych podmiotów oraz używanych przez nie systemów teleinformatycznych i rejestrów publicznych do współdziałania na rzecz osiągnięcia wzajemnie korzystnych i uzgodnionych celów, z uwzględnieniem współdzielenia informacji i wiedzy przez wspierane przez nie procesy biznesowe realizowane za pomocą wymiany danych za pośrednictwem wykorzystywanych przez te podmioty systemów teleinformatycznych. 17. Metadane - W odniesieniu do zbioru danych przestrzennych, są to dane o tym zbiorze określające zawarte w nim dane pod względem: położenia i rodzaju obiektów oraz ich atrybutów, pochodzenia, dokładności, szczegółowości i aktualności danych zbioru, zastosowanych standardach, prawach własności i prawach autorskich, cenach, warunkach i sposobach uzyskania dostępu do danych zbioru oraz ich użycia w określonym celu. 18. Model usługowy model architektury, w którym dla użytkowników zdefiniowano stanowiące odrębną całość funkcje systemu teleinformatycznego (usługi sieciowe) oraz opisano sposób korzystania z tych funkcji, inaczej system zorientowany na usługi (Service Oriented Architecture SOA); 19. Moduł dziedzinowy systemu oprogramowanie do obsługi danego rejestru lub ewidencji, dostarczające aplikację przeznaczoną dla użytkownika końcowego, adresowane do określonych dziedzin działania administracji publicznej, stanowiące jeden z elementów aplikacyjnej warstwy architektury systemu. 5

6 20. Moduł narzędziowy systemu oprogramowanie niezbędne zapewnienia spójności i transakcyjności systemu, stanowiące jeden z elementów aplikacyjnej warstwy architektury systemu. 21. Podmiot osoba fizyczna, prawna, jednostka nie posiadająca osobowości prawnej; 22. Podsystem grupa modułów dziedzinowych lub narzędziowych stanowiąca integralną całość i obsługująca określone zagadnienia dziedzinowe lub funkcjonalne systemu. 23. Projekt informatyczny o publicznym zastosowaniu - określony w dokumentacji zespół czynności organizacyjnych i technicznych mających na celu zbudowanie, rozbudowanie lub unowocześnienie systemu teleinformatycznego używanego do realizacji zadań publicznych, świadczenie usług dotyczących utrzymania tego systemu lub opracowanie procedur realizowania zadań publicznych drogą elektroniczną; 24. Rejestr uporządkowany, wyposażony w system identyfikatorów wykaz zasobów wraz z atrybutami; 25. Rejestr publiczny - rejestr, ewidencję, wykaz, listę, spis albo inną formę ewidencji, służące do realizacji zadań publicznych, prowadzone przez podmiot publiczny na podstawie odrębnych przepisów ustawowych; 26. Środki komunikacji elektronicznej - środki komunikacji elektronicznej w rozumieniu art. 2 pkt. 5 ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną; 27. System informatyczny system informacyjny, zarządzający informacją z wykorzystaniem narzędzi informatycznych. 28. System operacyjny oprogramowanie zarządzające systemem komputerowym, tworzące środowisko do uruchamiania i kontroli zadań użytkownika, ustalania połączeń sieciowych, zarządzanie plikami systemu. 29. Zasoby obiekty, którymi są przedmioty materialne (rzeczy) i niematerialne (wartości, prawa, dane i informacje) oraz zbiory tych obiektów, stanowiące przedmiot wymiany, przetwarzania lub zarządzania; 30. Zasoby informacyjne obiekty, którymi są dane i informacje oraz zbiory tych obiektów, gromadzone jako rejestry, ewidencje, dokumenty oraz zbiory dokumentów; 31. XML - Format XML (Extensible Markup Language) jest to obecnie powszechnie uznany standard publiczny, umożliwiający wymianę danych między różnymi systemami. 6

7 3 OPIS PRZEDMIOTU ZAMÓWIENIA Celem bezpośrednim projektu jest usprawnienie zarządzania drogami Województwa Kujawsko- Pomorskiego poprzez wdrożenie nowoczesnych systemów teleinformatycznych, wykorzystujących najnowsze technologie pozyskiwania, przetwarzania i przesyłania danych celem zapewnienia mieszkańcom, przedsiębiorcom oraz użytkownikom dróg wojewódzkich lepszej dostępności do informacji w zakresie infrastruktury drogowej oraz warunków ruchowych (komunikacyjnych). Osiągnięcie celu bezpośredniego wymaga realizacji następujących celów szczegółowych: 1 Zapewnienie dostępu do informacji o infrastrukturze drogowej, wykorzystywanej w codziennych procesach związanych z zarządzaniem drogami wojewódzkimi. 2 Zwiększenie efektywności usług świadczonych przez Zarząd Dróg Wojewódzkich, poprzez wdrożenie kompleksowego systemu zarządzania infrastrukturą drogową. 3 Zapewnienie ZDW w Bydgoszczy redukcji kosztów funkcjonowania, poprzez wdrożenie elektronicznych metod komunikacji, zapewnienie dostępu i przepływu informacji pomiędzy jego jednostkami. 4 Zapewnienie racjonalnego gospodarowania funduszami publicznymi, poprzez wdrożenie procesowego systemu zarządzania utrzymaniem bieżącym, remontami i inwestycjami, ze szczególnym uwzględnieniem integracji systemu rejestracji awarii i usterek z systemem zarządzania gwarancjami. 5 Zwiększenie efektywności prac terenowych, poprzez wdrożenie mobilnego systemu pozyskiwania i przesyłania danych. 6 Zwiększenie efektywności pracy poprzez wdrożenie systemów wspomagających zarządzanie w ujęciu procesowym, gwarantującym jednolitość i spójność procedur w Zarządzie Dróg Wojewódzkich i podległych mu Rejonach Dróg. 7 Zapewnienie obywatelom, przedsiębiorcom oraz użytkownikom dróg dostępności do usług świadczonych przez zarząd dróg wojewódzkich, realizujący zadania publiczne w postaci elektronicznej, poprzez wdrożenie publicznego geoportalu drogowego. 8 Zwiększenie transparentności działań Zarządu Dróg Wojewódzkich poprzez publikowanie informacji o działaniach bieżących i planowanych na publicznym geoportalu drogowym. 9 Rozwój zawodowy pracowników ZDW oraz RDW (Rejonów Dróg Wojewódzkich) poprzez dostęp do najnowszej technologii i wykorzystywanie jej do codziennej pracy. 7

8 Bezpośredni cel projektu zostanie osiągnięty poprzez wdrożenie, centralnego systemu zarządzania infrastrukturą dróg wojewódzkich, zapewniającego obsługę procesów związanych z jej właściwym utrzymaniem i rozbudową przez ZDW w Bydgoszczy i jej rejony. Wdrażany system zapewni dostęp do aktualnych danych dla celów decyzyjnych, umożliwi wymianę informacji pomiędzy Rejonami Dróg Wojewódzkich i Zarządem Dróg, a jego realizacja w technologii WWW, zapewni dostęp do usług związanych z prowadzeniem i udostępnianiem baz danych systemu. 8

9 4 ZAKRES RZECZOWY REALIZOWANEGO PROJEKTU W ramach zakresu realizacji projektu, są przewidziane następujące działania: 1. Dostawa oprogramowania dziedzinowego i licencji, ich wdrożenie, zgodnie z wymaganiami, obejmująca: a) Zarządzanie systemem referencyjnym b) Zarządzanie stanem prawnym ulic i dróg c) Zarządzanie infrastrukturą drogową d) Zarządzanie infrastrukturą mostową e) Zarządzanie organizacją ruchu f) Zarządzanie zajęciem pasa drogowego g) Zarządzanie objazdami dróg h) Zarządzanie utrzymaniem bieżącym i) Zarządzanie robotami budowlanymi j) Zarządzanie nawierzchnią drogową k) Natężenie ruchu drogowego l) Zarządzanie dokumentacją m) Terminarz drogowy n) Mobilna praca w terenie o) Moduł integracji z systemem monitoringu sieci dróg wojewódzkich p) Moduł integracji z systemem GPS i utrudnieniami drogowymi q) System zarządzania informacją, w tym: i. Serwer map, ii. Komponent mapowy, iii. Geoportal Intranetowy, iv. Geoportal Internetowy. 2. Dostawa oprogramowania narzędziowego i licencji, ich wdrożenie, w tym: a) Oprogramowanie bazodanowe, b) Stanowisko analityczne. 3. Dostawa, instalacja i konfiguracja sprzętu komputerowego wraz z oprogramowaniem systemowym zgodnie z wymaganiami opisanymi w rozdziale 10, obejmująca: 9

10 a) Mobilna stacja robocza (laptop) 12 sztuk b) Tablet RTK z anteną 15 sztuk c) Smartfon 15 sztuk d) Laptop do administracji systemem 1 sztuka e) Rozgałęźnik zasilania zapalniczki samochodowej 42 sztuki f) Zewnętrzny moduł GPS 14 sztuk g) Zestaw komputerowy (stacja robocza) z oprogramowaniem 25 sztuk h) Serwer plików (główny) 1 sztuka i) Serwer plików (zapasowy) 1 sztuka j) Lokalny kontroler domeny 6 sztuk k) Serwer do obsługi GPS i Zimowego Utrzymania Dróg 1 sztuka l) Serwer do obsługi Monitoringu i ITS 1 sztuka m) Serwer danych georeferencyjnych 1 sztuka n) Serwer telekomunikacyjny 1 sztuka o) Serwer kopii zapasowej 1 sztuka p) Macierz dyskowa ISCSI 1 sztuka q) Szafa Rack U 1 sztuka r) Konsola KVM 1 sztuka s) Przełącznik sieciowy 1 sztuka t) Zasilacz UPS 1 sztuka u) Monitor LCD 50" 4 sztuki v) Tablice TID 4 sztuki w) Znaki VMS 4 sztuki x) Kamery IP 40 sztuk y) Kamery IP obrotowe 2 sztuki z) Stacje meteorologiczne 9 sztuk aa) Urządzenia ANPR 5 sztuk bb) Urządzenia GPS (ZIMA) 80 sztuk cc) Czujnik posypu 80 sztuk dd) Czujnik pługa 80 sztuk 10

11 ee) Rejestrator video 12 sztuk ff) Urządzenia GPS (osobowe) 50 sztuk 4. Wdrożenie w terenie sprzętu obsługującego System monitoringu, ITS i GPS wraz ze wszystkimi modułami, oraz kolokacja serwerów 5. Pozyskanie danych do następujących rejestrów i ewidencji zgodnie z wymaganiami opisanymi w rozdziale Przeprowadzenie szkoleń użytkowników i administratorów systemu zgodnie z wymaganiami opisanymi w rozdziale Prowadzenie niezbędnego serwisu systemu gwarancyjnego i poza gwarancyjnego zgodnie z wymaganiami opisanymi w rozdziale

12 5 WYMAGANIA OGÓLNE DOTYCZĄCE PRZEDMIOTU ZAMÓWIENIA 5.1 WYMAGANIA PRAWNE Przedmiotowy projekt musi być realizowany zgodnie z przepisami prawnymi (łącznie z wchodzącymi zmianami) w zakresie: - prawa dziedzinowego, - prawa dotyczącego rejestrów publicznych, - prawa cywilnego i administracyjnego, Szczegółowy zakres przepisów prawnych został opisany w poniższych podrozdziałach PRAWO DZIEDZINOWE a) Geodezja i Kartografia - Ustawa z dnia 17 maja 1989 r. Prawo geodezyjne i kartograficzne (tj. Dz. U. z 2010 r. Nr 193, poz. 1287) - Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 29 marca 2001 w sprawie ewidencji gruntów i budynków (Dz. U. z 2001 r. Nr 38, poz. 454) - 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. Nr 38, poz. 455) d. Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia r. w sprawie zgłaszania prac geodezyjnych i kartograficznych, ewidencjonowania systemów 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 z późn. zm.) - Rozporządzenie Prezesa Rady Ministrów z dnia r. w sprawie państwowego systemu odniesień przestrzennych (Dz. U. z 2000 r. Nr 70, poz. 821 z późn. zm.) - Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 15 kwietnia 1999 r. w sprawie ochrony znaków geodezyjnych, grawimetrycznych i magnetycznych (Dz. U. z 1999 r. Nr 45, poz. 454 z późn. zm.) - Dyrektywa 2007/2/WE Parlamentu Europejskiego i Rady z dnia 14 marca 2007 r. ustanawiająca infrastrukturę informacji przestrzennej we Wspólnocie Europejskiej (INSPIRE) (Dziennik Urzędowy Unii Europejskiej L 108/1PL z dnia ). 12

13 - 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 (Dziennik Urzędowy Unii Europejskiej L 326/12 PL z ). - 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 (Dziennik Urzędowy Unii Europejskiej L 274/9 PL z ). - Ustawa z dnia 4 marca 2010 o infrastrukturze informacji przestrzennej (Dz. U. z 2010 r. Nr 76 Poz. 489). - Rozporządzenie Ministra Spraw Wewnętrznych z dnia 9 listopada 2011 r. w sprawie standardów technicznych wykonywania geodezyjnych pomiarów sytuacyjnych i wysokościowych oraz opracowywania i przekazywania wyników tych pomiarów do państwowego zasobu geodezyjnego i kartograficznego (Dz. U. z 2011 r. Nr 263 Poz. 1572). - Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 9 stycznia 2012 r. w sprawie ewidencji miejscowości, ulic i adresów (Dz. U Nr 0 Poz. 125). - Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 14 lutego 2012 r. w sprawie osnów geodezyjnych, grawimetrycznych i magnetycznych (Dz. U nr 0 poz. 352, z późn. zm.). - Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 14 lutego 2012 r. w sprawie państwowego rejestru nazw geograficznych (Dz. U nr 0 poz. 309). - 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 nr 0 poz. 199). - Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 3 listopada 2011 r. w sprawie baz danych dotyczących zobrazowań lotniczych i satelitarnych oraz ortofotomapy i numerycznego modelu terenu (Dz. U nr 263 poz. 1571). - Rozporządzenie Rady Ministrów z dnia 3 października 2011 r. w sprawie rodzajów kartograficznych opracowań tematycznych i specjalnych (Dz. U nr 222 poz. 1328). 13

14 - Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 22 grudnia 2011 r. w sprawie rodzajów materiałów geodezyjnych i kartograficznych, które podlegają ochronie zgodnie z przepisami o ochronie informacji niejawnych (Dz. U nr 299 poz. 1772). - Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 15 maja 2001 r. w sprawie określenia rodzajów map, materiałów fotogrametrycznych i teledetekcyjnych, stanowiących państwowy zasób geodezyjny i kartograficzny, których rozpowszechnianie, rozprowadzanie oraz reprodukowanie w celu rozpowszechniania i rozprowadzania wymaga zezwolenia, oraz trybu udzielania tych zezwoleń (Dz. U. Nr 56 poz. 588); - Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 14 listopada 2000 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. Nr 115 poz z 2000 r.); - Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 17 listopada 2011 r. w sprawie bazy danych obiektów topograficznych oraz bazy danych obiektów ogólno geograficznych, a także standardowych opracowań kartograficznych (Dz.U nr 279 poz. 1642). - Wytyczne techniczne G-5 Ewidencja gruntów i budynków, Główny Geodeta Kraju (z 2003 r.) 2003 r. w. Rozporządzenie Rady Ministrów z dnia 12 września 2012 r. sprawie gleboznawczej klasyfikacji gruntów (Dz. U. z 2012 r. poz. 199). - Rozporządzenie Rady Ministrów z dnia 17 stycznia 2013 r. w sprawie zintegrowanego systemu informacji o nieruchomościach (Dz. U. z 2012 r. poz. 249). - Rozporządzenie Rady Ministrów z dnia 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.) - 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 (tj. Dz. U nr 0 poz. 383) 14

15 b) Gospodarka nieruchomościami - Ustawa z dnia 21 sierpnia 1997 r. o gospodarce nieruchomościami (tj. Dz. U. z 2010 r. Nr 102, poz. 651). - Rozporządzenie Rady Ministrów z dnia 29 czerwca 2005 r. w sprawie powszechnej taksacji nieruchomości (tj. Dz. U. z 2005r. Nr 131, poz. 1092), - Rozporządzenie Rady Ministrów z dnia 21 września 2004 r. w sprawie wyceny nieruchomości i sporządzania operatu szacunkowego (tj. Dz. U. z 2005r. Nr 131, poz. 1092), - Ustawa z dnia 26 lipca 2001 r. o nabywaniu przez użytkowników wieczystych prawa własności nieruchomości (tj. Dz. U. z 2001r. Nr 97, poz. 1051), - Ustawa z dnia 29 września 1994 r. o rachunkowości (tj. Dz. U. z 2009r. Nr 152, poz. 1223, z późn. zm.), - Rozporządzenie Rady Ministrów z dnia 10 grudnia 2010 r. w sprawie Klasyfikacji Środków Trwałych (KŚT) (tj. Dz. U. z 2010r. Nr 242, poz. 1622). - Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 9 stycznia 2012r. w sprawie ewidencji miejscowości ulic i adresów (tj. Dz. U. z 2012r. poz. 125). c) Kształtowanie ładu przestrzennego - Ustawa z dnia 27 marca 2003 r. o planowaniu i zagospodarowaniu przestrzennym (Dz. U. z 2003 r. Nr 80, poz. 717 z późn. zm.); - Rozporządzenie Ministra Infrastruktury z dnia 26 sierpnia 2003 r. w sprawie wymaganego zakresu projektu miejscowego planu zagospodarowania przestrzennego (Dz. U. z 2003 r. Nr 164, poz. 1587); - Ustawa z dnia 7 lipca 1994 r. Prawo budowlane (tj. Dz. U r. Nr 243, poz z późn. zm.) - Rozporządzenie Ministra Infrastruktury z dnia 12 kwietnia 2002 r. w sprawie warunków technicznych, jakim powinny odpowiadać budynki i ich usytuowanie (Dz. U. z 2002 r. Nr 75, poz. 690 z późn. zm.) - Rozporządzenie Ministra Infrastruktury z dnia r. w sprawie książki obiektu budowlanego (Dz. U. z 2003 r. Nr 120, poz z późn. zm.). 15

16 d) Transport, drogi publiczne - Ustawa z dnia 21 marca 1985 r. o drogach publicznych (tj. Dz. U. z 2007 r. Nr 19, poz. 115 z późn. zm.). - Ustawa z dnia 6 września 2001 r. o transporcie drogowym (tj. Dz. U. z 2007r. Nr 125, poz. 874 z późn. zm.). - Rozporządzenie Ministra Infrastruktury z dnia 16 lutego 2005 r. w sprawie sposobu numeracji i ewidencji dróg publicznych, obiektów mostowych, tuneli, przepustów i promów oraz rejestru numerów nadanych drogom, obiektom mostowym i tunelom (Dz. U nr 67 poz. 582). - Rozporządzenie Ministra Infrastruktury z dnia 16 lutego 2005 r. w sprawie trybu sporządzania informacji oraz gromadzenia i udostępniania danych o sieci dróg publicznych, obiektach mostowych, tunelach oraz promach (Dz. U nr 67 poz. 583). - Rozporządzenie Rady Ministrów z dnia 1 kwietnia 2004 r. w sprawie określenia warunków udzielania zezwoleń na zajęcie pasa drogowego (Dz. U. z 2004 nr 140 poz z późn. zm.). - Ustawa z dnia 20 czerwca 1997 r. Prawo o ruchu drogowym (tj. Dz. U. z 2005 r. Nr 108, poz. 908 z późn. zm.). - Rozporządzenie Ministrów Infrastruktury oraz Spraw Wewnętrznych i Administracji z dnia 31 lipca 2002 r. w sprawie znaków i sygnałów drogowych. (Dz. U nr 170 poz z późn. zm.). - Rozporządzenie Ministra Infrastruktury z dnia 17 czerwca 2011 r. w sprawie warunków lokalizacji, sposobu oznakowania i dokonywania pomiarów przez urządzenia rejestrujące (Dz. U nr 133 poz. 770). - Rozporządzenie Ministra infrastruktury z dnia 3 lipca 2003 r. w sprawie szczegółowych warunków technicznych dla znaków i sygnałów drogowych oraz urządzeń bezpieczeństwa ruchu drogowego i warunków ich umieszczania na drogach (Dz.U nr 220 poz z późn. zm.). 16

17 e) Ochrona środowiska - Ustawa z dnia 18 lipca 2001 r. - Prawo wodne (tj. Dz. U. z 2001r. Nr 115, poz. 1229). Ochrona zabytków - Ustawa z dnia 23 lipca 2003 r. o ochronie zabytków i opiece nad zabytkami (Dz. U. z 2003 r. Nr 162, poz z późn. zm.); - Rozporządzenie Ministra Kultury I Dziedzictwa Narodowego z dnia 26 maja 2011 r. w sprawie prowadzenia rejestru zabytków, krajowej, wojewódzkiej i gminnej ewidencji zabytków oraz krajowego wykazu zabytków skradzionych lub wywiezionych za granicę niezgodnie z prawem (Dz. U. z 2011 r. Nr 113 Poz. 661); - Rozporządzenie Ministra Kultury i Dziedzictwa Narodowego z dnia 18 lutego 2011 w sprawie wzorów dokumentów oceny wskazującej czas powstania zabytku, wyceny zabytku oraz potwierdzenia wwozu zabytku na terytorium Rzeczypospolitej. f) Ochrona środowiska - Ustawa z dnia 7 września 1991r. o systemie oświaty (Dz. U. z 2004 r. Nr 256, poz z późn. zm.), - Rozporządzenie Ministra Edukacji Narodowej z dnia 9 sierpnia 2012 r. w sprawie szczegółowego zakresu danych gromadzonych w bazach danych oświatowych, zakresu danych identyfikujących podmioty prowadzące bazy danych oświatowych, terminów przekazywania danych między bazami danych oświatowych oraz wzorów wydruków zestawień zbiorczych (tj. Dz. U. z 2011 r. poz. 957), - Ustawa z dnia 15 kwietnia 2011 r. o systemie informacji oświatowej (tj. Dz. U. z 2011 r. Nr 139, poz. 814), - Ustawa z dnia 27 lipca 2012 r. o zmianie ustawy o systemie informacji oświatowej oraz niektórych innych ustaw (tj. Dz. U. z 2012 r. poz. 941). g) Zarządzanie kryzysowe - Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (tj. Dz. U. z 2007r. Nr 89, poz.590), 17

18 - Ustawa z dnia 18 kwietnia 2002 r. o stanie kęski żywiołowej (tj. Dz.U. z 2002 r. Nr 62, poz.558 z późn. zm.), - Ustawa z dnia 5 czerwca 1998 r. o samorządzie powiatowym (tj. Dz.U. z 2001 r., Nr 142, poz z późn. zm.), - Ustawa z dnia 24 sierpnia 1991 r. o ochronie przeciwpożarowej (tj. Dz.U. z 2002 r., Nr 147, poz z późn. zm.), - Ustawa z dnia 6 kwietnia 1990 r. o Policji (tj. tekst jednolity Dz.U. z 2002 r. Nr 7, poz. 58 z późn. zm.), - Ustawa z dnia 22 sierpnia 1997 r. o bezpieczeństwie imprez masowych (tj. tekst jednolity Dz.U. z 2005 r., Nr 108, poz. 909 z późn. zm.), - Ustawa z dnia 18 lipca 2001r. Prawo wodne (tj. tekst jednolity Dz.U. z 2005 r. Nr 239, poz z późn. zm.), - Rozporządzenie Rady Ministrów z dnia 20 lutego 2003r. w sprawie szczegółowych zasad udziału pododdziałów i oddziałów Sił Zbrojnych Rzeczypospolitej Polskiej w zapobieganiu skutkom klęski żywiołowej lub ich usuwaniu (tj. Dz.U. z 2003 r. Nr 41, poz. 347), - Rozporządzenie Rady Ministrów z dnia 16 października 2006 r. w sprawie systemów wykrywania skażeń i właściwości organów w tych sprawach (tj. Dz.U. z 2006 r. Nr 191, poz. 1415), - Ustawa z dnia 31 sierpnia 2011 r. o zmianie ustawy o bezpieczeństwie imprez masowych oraz niektórych innych ustaw (tj. Dz.U. z 2011 r. Nr 217, poz. 1280), - Ustawa z dnia 4 września 1997 r. o działach administracji rządowej (tj. Dz.U. z 2007 r. Nr 65, poz. 437), - Ustawa z 20 marca 2009 r. o bezpieczeństwie imprez masowych (tj. Dz.U. z 2009 r. Nr 62, poz. 504) PRAWO CYWILNE I ADMINISTRACYJNE a) Prawo cywilne - Ustawa z dnia 23 kwietnia 1964 r. Kodeks cywilny (Dz.U. z 1964 r. Nr 16, poz. 93 z późn. zm.). 18

19 b) Prawo administracyjne - Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (tj. Dz. U. z 2000 r. Nr 98, poz z późn. zm.). c) Samorząd terytorialny - Ustawa z dnia 8 marca 1990 r. o samorządzie gminnym (tj. Dz.U. z 2001 r. Nr 142, poz z późn. zm.) - Ustawa z dnia 5 czerwca 1998 r. o samorządzie powiatowym (Dz. U. z 2001 r. Nr 142, poz z późn. zm.). d) Informacja publiczna, dane osobowe i informatyzacja - Dyrektywa 2003/98/We Parlamentu Europejskiego I Rady z dnia 17 listopada 2003 r. w sprawie ponownego wykorzystywania informacji sektora publicznego. - Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. z 2001 r. Nr 112, poz z późn. zm.). c. Ustawa z dnia r. o ochronie danych osobowych (Dz.U. z 2002 r. Nr 101, poz. 926 z późn. zm.) - Ustawa z dnia 20 lipca 2000 r. o ogłaszaniu aktów normatywnych i niektórych innych aktów prawnych (tj. Dz. U. z 2011 r. Nr 197, poz z późn. zm.) - Rozporządzenie Prezesa Rady Ministrów z dnia 27 grudnia 2011 r. w sprawie wymagań technicznych dla dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, dzienników urzędowych wydawanych w postaci elektronicznej oraz środków komunikacji elektronicznej i informatycznych nośników danych (Dz.U. z 2011 r. 289 Poz. 1699). - Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. z 2002 r. Nr 144, poz z późn. zm.). - Ustawa z dnia r. o ochronie niektórych usług świadczonych drogą elektroniczną opartych lub polegających na dostępie warunkowym (Dz.U. z 2002 r. Nr 126, poz z późn. zm.) - Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. z 2001 r. Nr 130, poz z późn. zm.) i. Ustawa z dnia r. o ochronie baz danych (Dz.U. z 2001 r. Nr 128, poz z późn. zm.) 19

20 - Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 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 2004r. Nr 100, poz. 1024). - Rozporządzenie Prezesa Rady Ministrów z dnia 29 września 2005 r. w sprawie warunków organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym art. 16 ust. 3 ustawy (Dz. U. Nr 200 z dnia r. poz. 1651). - Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych art. 18 pkt.1 ustawy (Dz. U. Nr 212 z dnia r. poz. 1766), - Rozporządzenie Ministra Nauki i Informatyzacji z dnia 29 sierpnia 2005 r. w sprawie sposobu prowadzenia oraz trybu dostarczania i udostępniania danych z Krajowej Ewidencji Systemów Teleinformatycznych i Rejestrów Publicznych art. 20 ust. 6 pkt. 1 i 2 ustawy (Dz. U. Nr 200 z dnia r. poz. 1655). - 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 art. 21 ust. 6 pkt. 1-5 ustawy (Dz. U. Nr 217 z dnia r. poz. 1836). - Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 14 marca 2006 r. w sprawie kryteriów i trybu przeznaczania oraz rozliczania środków finansowych na informatyzację art. 12 ust. 6 ustawy (Dz. U. Nr 53 z dnia r., poz.388). - Ustawa z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. Nr 171, poz i Nr 273, poz. 2703). - Rozporządzenie Ministra Infrastruktury z dnia 24 marca 2005 r. w sprawie szczegółowych wymagań dotyczących świadczenia usługi powszechnej oraz wymagań dotyczących świadczenia usługi szerokopasmowego dostępu do Internetu dla jednostek uprawnionych. 20

21 - Rozporządzenie Ministra Nauki i Informatyzacji z dnia 23 marca 2005 r. w sprawie warunków udzielania oraz sposobu przekazywania i wykorzystania dotacji przeznaczonej dla jednostek uprawnionych art. 100 ust. 3 ustawy (Dz. U nr 46 poz. 439) PRAWO DOTYCZĄCE REJESTRÓW PUBLICZNYCH - 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.). - Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej art. 18 pkt. 2 ustawy (Dz. U. Nr 214 z dnia r. poz.1781). - Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych z rejestru publicznego art. 15 ust. 3 ustawy (Dz. U. Nr 205 z dnia r. poz. 1692). - 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. Nr 0, poz. 526 z późn. zm.). 5.2 WYMAGANIA DOTYCZĄCE WDROŻENIA Budowa Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego obejmuje dostawę sprzętu specjalistycznego i niezbędnego do funkcjonowania systemu, dostawy licencji i wdrożenie oprogramowania dziedzinowego wraz z pozyskaniem danych, dostawy licencji i wdrożenie oprogramowania narzędziowego, wdrożenie modułów monitoringu i ITS wraz z montażem wszystkich elementów w terenie, wdrożenie i montaż w terenie systemu GPS, szkolenia użytkowników oraz instalację i konfigurację sprzętu komputerowego z oprogramowaniem systemowym. Proces wdrożenia obejmuje w szczególności: 1. W zakresie sprzętu komputerowego i oprogramowania systemowego: 21

22 a) dostawę, instalację, konfigurację i fizyczny montaż serwerów plików głównych wraz z serwerem zapasowym z oprogramowaniem systemowym, w szafie serwerowej w głównej serwerowni Zamawiającego; b) dostawę, instalację, konfigurację i fizyczny montaż lokalnych kontrolerów domeny w Rejonach Dróg Wojewódzkich (RDW Inowrocław, RDW Toruń, RDW Tuchola, RDW Wąbrzeźno, RDW Włocławek, RDW Żołędowo) c) dostawę, instalację, konfigurację i fizyczny montaż serwera do obsługi systemu monitoringu i ITS, serwer do obsługi systemu GPS i ZUD, serwer do obsługi danych georeferencyjnych, serwer telekomunikacyjny, serwer kopii zapasowej wraz z oprogramowaniem systemowym, zasilacza awaryjnego, konsoli KVM, zapory sieciowej, przełącznika oraz pozostałych komponentów w szafie serwerowej w serwerowni Zamawiającego lub w serwerowni wybranej przez Wykonawcę o wymaganiach minimalnych określonych przez Zamawiającego w OPZ do SIWZ; d) dostawę, instalację, konfiguracje i fizyczny montaż zestawów komputerowych stacjonarnych (w siedzibie Zamawiającego i jego Rejonach) w ustalonej lokalizacji przez Zamawiającego; e) instalację, konfigurację i uruchomienie wszelkiego niezbędnego oprogramowania f) podłączenie sprzętu do najbliższego punktu styku z Internetem oraz siecią energetyczną i wszystkimi wymaganymi instalacjami teletechnicznymi. 2. W zakresie oprogramowania dziedzinowego: a) instalację, konfigurację i uruchomienie oprogramowania dziedzinowego; b) integrację oprogramowania dziedzinowego, w zakresie zapewnienia harmonizacji zbiorów i usług danych przestrzennych oraz zapewnienia interoperacyjności wdrażanego oprogramowania, 3. W zakresie oprogramowania narzędziowego: a) instalację, konfigurację i uruchomienie oprogramowania zarządzania bazami danych; b) instalację, konfigurację i uruchomienie oprogramowania narzędziowego udostępniającego metadane, dane przestrzenne i mapowe (usługi w standardzie OGC: CSW, WMS, WFS, GML i inne niezbędne dla uzyskania wymaganej funkcjonalności); 22

23 4. W zakresie pozyskania danych a) pozyskanie danych do określonych w przedmiocie projektu rejestrów i ewidencji; b) konwersja danych z aktualnie użytkowych aplikacji. 5. W zakresie szkoleń: a) przeprowadzenie szkoleń użytkowników systemu w siedzibie Zamawiającego wg uzgodnionego harmonogramu; b) przeprowadzenie szkoleń administratorów systemu w siedzibie Zamawiającego wg uzgodnionego harmonogramu. 6. W zakresie serwisu systemu: a) prowadzenie niezbędnego serwisu systemu (poza gwarancyjnego) mającego na celu zapewnienie aktualizacji Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego, zgodnie ze zmieniającymi przepisami prawnymi; b) prowadzenie niezbędnego serwisu systemu (poza gwarancyjnego) w zakresie wsparcie użytkowników w zakresie użytkowania systemu; c) aktualizacja systemu Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego (aktualizacja do nowych wersji zastosowanego oprogramowania). 23

24 5.3 WYMAGANIA W ZAKRESIE HARMONOGRAMU Przy realizacji Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego należy uwzględnić następujący harmonogram realizacji: Nazwa IV Kwartał 2013 I Kwartał 2014 II Kwartał 2014 III Kwartał 2014 IV Kwartał 2014 Jednostki Sprzętowe (Sprzęt komputerowy, Jednostki Mobilne, Sprzęt do systemu GPS, Systemu ITS i Monitoring) Oprogramowanie dziedzinowe Etap I (Zarządzanie systemem referencyjnym, Zarządzanie infrastrukturą drogową, Zarządzanie infrastrukturą mostową, Zarządzanie organizacją ruchu drogowego, Zarządzanie zajęciem pasa drogowego) Oprogramowanie dziedzinowe Etap II (Zarządzanie objazdami dróg, Zarządzanie utrzymaniem bieżącym, Zarządzanie robotami budowlanymi, Zarządzanie stanem prawnym ulic i dróg,) Oprogramowanie dziedzinowe Etap III (Natężenie ruchu drogowego, Terminarz drogowy, Zarządzanie dokumentacją) Oprogramowanie dziedzinowe Etap IV (Moduł integracji z system monitoringu, Moduł integracji z system ITS, Moduł integracji z systemem utrudnień zimowych, Moduł integracj z system GPS, Mobilna praca, Zarządzanie nawierzchnią drogową) Oprogramowanie Narzędziowe Wdrożenie systemu Etap I (Zarządzanie systemem referencyjnym, Zarządzanie infrastrukturą drogową, Zarządzanie infrastrukturą mostową, Zarządzanie organizacją ruchu drogowego, Mobilna praca, Zarządzanie nawierzchnią drogową, ) Wdrożenie systemu Etap II (Zarządzanie objazdami dróg, Zarządzanie utrzymaniem bieżącym, Zarządzanie robotami budowlanymi, Zarządzanie stanem prawnym ulic i dróg, Zarządzanie zajęciem pasa drogowego) Wdrożenie systemu Etap III ( Natężenie ruchu drogowego, Terminarz drogowy, Zarządzanie dokumentacją) Wdrożenie systemu Etap IV (Moduł integracji z systemem monitoringu, Moduł integracji z system ITS, Moduł integracji z systemem utrudnień zimowych, Moduł integracj z system GPS) Pozyskanie danych (System Referencyjny, Ewidencja dróg dla odcinków testowych (190 km), Ewidencja obiektów inżynieryjnych, Ewidencja dróg, Ocena stanu technicznego nawierzchni) Promocja projektu Nadzór techniczny Audyt projektu x 24

25 1. Dostawa i instalacja sprzętu komputerowego, dostawa i instalacja architektury serwerowej w terminie do r. 2. Dostawa licencji, wdrożenie i instalacja oprogramowania narzędziowego do r. 3. Dostawa sprzętu odpowiedzialnego za funkcjonowanie modułów monitoringu dróg wojewódzkich i ITS oraz modułu GPS w terminie do r. 4. Dostawa licencji, wdrożenie i instalacja oprogramowania dziedzinowego w terminie do r., w ramach następujących modułów dziedzinowych : a) Moduł Zarządzania Systemem Referencyjnym b) Moduł Zarządzania Infrastrukturą Drogową c) Moduł Zarządzania Infrastrukturą Mostową d) Moduł Zarządzania Organizacją Ruchu e) Moduł Zajęcia Pasa Drogowego 5. Dostawa licencji, wdrożenie i instalacja oprogramowania dziedzinowego w terminie do r., w ramach następujących modułów dziedzinowych : a) Moduł Zarządzania Stanem Prawnym Ulic i Dróg b) Moduł Zarządzania Natężeniem Ruchu Drogowego c) Moduł Zarządzania Dokumentacją d) Moduł Zarządzania Terminami Terminarz Drogowy e) Moduł Zarządzania Objazdami Dróg f) Moduł Zarządzania Utrzymaniem Bieżącym g) Moduł Zarządzania Robotami Budowlanymi 6. Dostawa licencji, wdrożenie i instalacja oprogramowania dziedzinowego w terminie do r., w ramach następujących modułów dziedzinowych : a) Moduł Zarządzania Nawierzchnią Drogową b) Moduł Monitoringu Sieci Dróg Wojewódzkich w Woj. Kuj.-Pom. i ITS c) Moduł Zarządzania Utrudnieniami zimowymi i GPS d) Moduł Zarządzania Mobilną Pracą w Terenie 7. Pozyskanie danych w terminie do r. dla następujących wcześniej wdrożonych modułów dziedzinowych systemu : a) Moduł Zarządzania Natężeniem Ruchu Drogowego 25

26 b) Moduł Zarządzania Dokumentacją c) Moduł Zarządzania Terminami Terminarz Drogowy d) Moduł Zarządzania Objazdami Dróg e) Moduł Zarządzania Utrzymaniem Bieżącym f) Moduł Zarządzania Robotami Budowlanymi g) Moduł Zajęcia Pasa Drogowego 8. Pozyskanie danych w terminie do r. dla następujących wcześniej wdrożonych modułów dziedzinowych systemu : a) Moduł Zarządzania Infrastrukturą Drogową b) Moduł Zarządzania Infrastrukturą Mostową c) Moduł Zarządzania Organizacją Ruchu d) Moduł Zarządzania Stanem Prawnym Ulic i Dróg e) Moduł Zarządzania Mobilną Pracą w Terenie f) Moduł Zarządzania Nawierzchnią Drogową g) Moduł Zarządzania Systemem Referencyjnym 9. Wdrożenie i instalacja w terenie sprzętu funkcjonalnego w terminie do r., w ramach następujących modułów dziedzinowych : a) Moduł Zarządzania Utrudnieniami zimowymi i GPS 10. Wdrożenie i instalacja w terenie sprzętu funkcjonalnego w terminie do r., w ramach następujących modułów dziedzinowych : a) Moduł Monitoringu Sieci Dróg Wojewódzkich w Woj. Kuj.-Pom. i ITS 11. Przeprowadzenie szkoleń wewnętrznych dla pracowników i administratorów z obsługi i administracji systemu w terminie do r. Szkolenia dotyczące poszczególnych modułów będą realizowane etapami, równolegle do ich wdrożenia. 12. Promocja projektu w terminie do r. 13. Świadczenie serwisu systemu w trakcie realizacji umowy tj. do dnia r. 26

27 5.4 WYMAGANIA DOTYCZĄCE SZKOLEŃ SZKOLENIA DLA UŻYTKOWNIKÓW SYSTEMU 1. Harmonogram szkoleń dla użytkowników systemu, uzgodniony zostanie na etapie wdrożenia każdego podsystemu Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego, przez przedstawicieli Zamawiającego i Wykonawcy. Wykonawca przedstawi do akceptacji propozycję harmonogramu szkoleń najpóźniej w dniu rozpoczęcia instalacji poszczególnych modułów danego podsystemu na serwerach Zamawiającego. 2. Wykonawca musi przygotować i przesłać do uzgodnienia szczegółowy zakres każdego szkolenia, co najmniej 2 tygodnie przed planowanym terminem szkolenia. 3. Wykonawca winien przygotować szkolenia w rozbiciu na poszczególne moduły systemu Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego (uwzględniając wszystkie moduły). 4. Szkolenia muszą obejmować szkolenia: a) ogólne (w grupach) dla wszystkich użytkowników polegające na prezentacji i szczegółowym wytłumaczeniu systemu, b) indywidualne (stanowiskowe) dla każdego z użytkowników Systemu także w Rejonach Dróg przy założeniu, że zapewni ono użytkownikowi wykonywanie podstawowych czynności w pracy z podsystemem w stopniu wystarczającym do rozpoczęcia samodzielnej pracy. 5. W ramach szkolenia muszą być zagwarantowane: a) Sprzęt i środowisko na czas trwania szkolenia, b) Śniadanie w formie kanapek, lunch, przerwy kawowe, c) Autoryzowane przez producenta środowiska wirtualizacyjnego materiały szkoleniowe, 6. Szkolenie należy przeprowadzić w godzinach pracy urzędu. 7. Wykonawca zobowiązany jest zorganizować szkolenia w zakresie umożliwiającym każdemu użytkownikowi sprawne posługiwanie się określonymi modułami systemu stosownie do pełnionej przez nią roli. 9. Szkolenia odbywać się mają na stanowiskach komputerowych wybranych pracowników - przedstawicieli Zamawiającego, z wykorzystaniem sprzętu komputerowego Zamawiającego, a także w oparciu o system zainstalowany na sprzęcie serwerowym dostarczonym przez 27

28 Wykonawcę. W przypadku, gdy Zamawiający nie będzie dysponował wystarczającym wyposażeniem technicznym zapewniającym odpowiednią pomoc przy prowadzeniu szkoleń (np. rzutnik), Wykonawca musi wykorzystać własny sprzęt. 10. Z przeprowadzonych szkoleń Wykonawca sporządzi protokoły, które zawierać muszą informację o dacie i miejscu szkolenia, uczestnikach szkolenia oraz podpisy uczestników szkolenia potwierdzające uczestnictwo i zakres zdobytych umiejętności. 11. Wykonawca po przeprowadzeniu szkolenia powinien przekazać Zamawiającemu dokumentacje systemu objętego przedmiotem. Dokumentacja powinna zostać dostarczona w postaci dwóch egzemplarzy kompletu podręczników, oraz na nośniku informatycznym (CD/DVD) w postaci dokumentów formatu PDF SZKOLENIA DLA ADMINISTRATORÓW SYSTEMU 1. Poziom wyszkolenia powinien pozwalać przeszkolonym administratorom na szkolenie pozostałych użytkowników końcowych systemu oraz świadczenie im wsparcia w zakresie typowo występujących problemów i sytuacji praktycznych, w szczególności obejmując: a) wprowadzenie danych do Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko - Pomorskiego ; b) wprowadzanie i modyfikowanie uprawnień użytkowników; c) wykonywanie kopii bezpieczeństwa systemu i odzyskiwania danych po awarii. 2. W ramach szkolenia muszą być zagwarantowane: a) Sprzęt i środowisko na czas trwania szkolenia, b) Śniadanie w formie kanapek, lunch, przerwy kawowe, c) Autoryzowane przez producenta środowiska wirtualizacyjnego materiały szkoleniowe, 3. Szkolenia odbywać się mają na stanowiskach komputerowych wybranych pracowników - przedstawicieli Zamawiającego, z wykorzystaniem sprzętu komputerowego Zamawiającego, a także w oparciu o system zainstalowany na sprzęcie serwerowym dostarczonym przez Wykonawcę. W przypadku, gdy Zamawiający nie będzie dysponował wystarczającym wyposażeniem technicznym zapewniającym odpowiednią pomoc przy prowadzeniu szkoleń (np. rzutnik), Wykonawca musi wykorzystać własny sprzęt. 4. Szkolenie należy przeprowadzić w godzinach pracy urzędu. 28

29 5.5 WYMAGANIA DOTYCZĄCE LICENCJONOWANIA Licencje na oprogramowanie zakupione w ramach Projektu powinny posiadać następujące cechy: a) Z wyjątkiem aplikacji typu desktop do analiz danych przestrzennych i oprogramowania bazodanowego powinny zostać zakupione licencje na system na nieograniczoną liczbę stanowisk, b) Licencje na oprogramowanie systemowe powinny posiadać odpowiednie certyfikaty licencyjne, zapewniające korzystanie przez pracowników Zarządu Dróg Wojewódzkich, c) Licencje obejmować powinny wszystkie elementy systemu, każde oprogramowanie, które potrzebne jest do jego funkcjonowania łącznie z oprogramowaniem bazodanowym. d) Licencje powinny być licencjami wydawanymi na czas nieokreślony. e) Licencje na oprogramowanie bazodanowe, ze względów finansowych i ilości korzystających z nich użytkowników muszą być zakupione jako licencje procesorowe. 5.6 WYMAGANIA DOTYCZĄCE GWARANCJI SYSTEMU SERWIS GWARANCYJNY SYSTEMU Gwarancja systemu obejmować będzie: 1. Wykonawca udziela Zamawiającemu licząc od daty końcowego bezusterkowego odbioru przedmiotu umowy : a) rękojmi na okres 12 miesięcy na zainstalowany sprzęt, oprogramowania, urządzenia i wyposażenie, b) gwarancji na okres 36 miesięcy na zainstalowany sprzęt, oprogramowania, urządzenia i wyposażenie oraz wykonane usługi liczonego od dnia odbioru końcowego w zakresie dostawy zgodnie z WYMAGANIA DOTYCZĄCE SPRZĘTU KOMPUTEROWEGO. 2. Wykonawca gwarantuje, że System ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego będzie działał zgodnie z jego opisem, oraz dostarczonymi opisami i instrukcjami zgodnie z warunkami zamówienia. 3. Udzielona gwarancja i rękojmia na System ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego obejmuje dokumentację techniczną dostarczoną wraz z nim oraz zgodność Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa 29

30 Kujawsko Pomorskiego ze specyfikacjami oficjalnie publikowanymi lub dostarczonymi Zamawiającemu przez Wykonawcę SERWIS POZAGWARANCYJNY SYSTEMU Serwis pozagwarancyjny będzie trwał od momentu wdrożenia modułów do końca projektu, czyli do dnia r. i będzie obejmował: 1. Modyfikację oraz aktualizację systemu (wszystkich modułów) i składających się na niego aplikacji na potrzebę Zamawiającego; 2. Dostosowanie systemu do nowych wymogów przepisów prawa, także wówczas, gdy wiąże się to ze zwiększeniem funkcjonalności systemu, bądź poszczególnych podsystemów lub modułów; 3. Świadczenie usług konsultacyjnych dla użytkowników systemu drogą telefoniczną, za pośrednictwem internetowych formularzy zgłoszeń oraz pod wydzielonym adresem e- mail; 4. Świadczenie usług konsultacyjnych dla administratora w zakresie obsługi technicznej i użytkowej oprogramowania; 5. Wizyty konsultanta w siedzibie Zamawiającego z częstotliwością raz na miesiąc w ustalonym wcześniej terminie; 6. Udzielanie pomocy merytorycznej w obsłudze systemu, jak również techniczne wsparcie w sytuacjach losowych (np. zniszczenie programów, zbiorów danych, itp.); Serwis pozagwarancyjny nie obejmuje uszkodzeń, napraw i wymian sprzętu wynikających z działania osób trzecich lub eksploatowanie nie zgodnie z przeznaczeniem. 5.7 WYMAGANIA DOTYCZĄCE SPRZĘTU KOMPUTEROWEGO 1. Gwarancje na sprzęt komputerowy nie mogą być krótsze niż gwarancje producentów. L.p. Nazwa Ilość sztuk Min. Okres gwarancji liczony od daty odbioru końcowego 30 Czas reakcji na zgłoszoną awarię Czas naprawy (w dniach kalendarzowych) 1. Serwer plików (główny) 1 min. 3 lata do końca następnego dnia roboczego 7 dni 2. Serwer plików (zapasowy) 1 min. 3 lata do końca następnego dnia roboczego 7 dni 3. Lokalny kontroler domeny 6 min. 3 lata do końca następnego dnia roboczego 7 dni 4. Serwer GPS i ZUD 1 min. 3 lata do końca następnego 7 dni

31 5. Serwer Monitoringu i ITS 1 min. 3 lata 6. Serwer danych georeferencyjnych 1 min. 3 lata 7. Serwer Telekomunikacyjny 1 min. 3 lata 8. Serwer Kopii Zapasowej 1 min. 3 lata 9. Szafa Rack 19 42U 1 min. 5 lata 10. Konsola KVM 1 min. 2 lata 11. Przełącznik sieciowy 1 min. 3 lata 12. Macierz dyskowa ISCSI 1 min. 3 lata 13. Zasilacz UPS 1 min. 2 lata 14. Monitor LCD 50 4 min. 3 lata 15. Mobilna Stacja Robocza 12 min. 3 lata Zestaw komputerowy (stacja robocza) wraz z oprogramowaniem Laptop do administrowania systemem 25 min. 3 lata 1 min. 3 lata 18. Tablety RTK z anteną 15 min. 3 lata 19. Smartfony 15 min. 3 lata dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego do końca następnego dnia roboczego 7 dni 7 dni 7 dni 7 dni 14 dni 14 dni 14 dni 7 dni 14 dni 14 dni 7 dni 7 dni 7 dni 7 dni 7 dni 2. Gwarancje i wykonywanie świadczeń gwarancyjnych muszą być wykonane według następujących wymagań: a) Przez czas reakcji na zgłoszoną awarię, rozumie się czas od przyjęcia zgłoszenia awarii do serwisu. b) Przez czas naprawy, rozumie się czas liczony od przybycia serwisu do siedziby ZAMAWIAJĄCEGO po zgłoszeniu awarii, nie później jednak niż w ramach czasu reakcji, liczony do momentu dokonania skutecznej naprawy. c) Bieg gwarancji rozpoczyna się z dniem podpisania protokołu zdawczo odbiorczego dotyczącego dostawy sprzętu i oprogramowania systemowego. d) Wymiana sprzętu w okresie gwarancji na nowy nastąpi w przypadku wystąpienia wady niemożliwej do usunięcia lub wystąpienia 3 istotnych jego awarii; za istotne 31

32 uszkodzenie (awarie) przyjmuje się każde uszkodzenie ograniczające funkcjonowanie danego urządzenia. 3. W sprawach nie uregulowanych w/w zapisami, obowiązują warunki gwarancyjne przedstawione przez producenta. 32

33 6 WARUNKI TECHNICZNE REALIZACJI PRZEDMIOTU 6.1 WYMAGANIA TECHNOLOGICZNE 1. Dostarczony System ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego musi umożliwiać użytkownikom wydajną pracę na stanowiskach roboczych wykorzystywanych przez pracowników Zarządu Dróg Wojewódzkich w Bydgoszczy i podległych mu Rejonów Dróg. 2. Dostarczone w ramach niniejszego zamówienia oprogramowanie musi działać w sieci komputerowej Zarządu Dróg Wojewódzkich w Bydgoszczy i podległych mu Rejonów Dróg w standardzie TCP/IP. 3. Dostarczone w ramach niniejszego zamówienia oprogramowanie musi być zrealizowane w technologii WWW, gdzie interfejsem użytkownika jest oprogramowanie uruchamiane z poziomu przeglądarki internetowej. 4. Dostarczone w ramach niniejszego zamówienia oprogramowanie musi poprawnie działać z następującymi przeglądarkami WWW w aktualnych wersjach odpowiednich dla poszczególnych systemów operacyjnych z obsługą Wirtualnej Maszyny Javy (przynajmniej Internet Explorer 8.0, Firefox 4.0, Opera 11.0, Google Chrome 5 lub nowsze). 5. Dostarczone oprogramowanie w ramach Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego nie powinno wymagać instalacji dodatkowych komponentów typu plug-in przez użytkowników (pracowników, administratorów i klientów urzędu). Dla realizacji wybranych funkcji lokalnych (obsługa podpisu elektronicznego, skanowanie, backup) dopuszcza się wykorzystanie zainstalowanych lokalnych aplikacji wchodzących w skład systemu operacyjnego. 6. Jeżeli Wykonawca opiera swoje rozwiązanie o platformy open source, to oprogramowanie dostarczone przez niego w ramach niniejszego przetargu nie może być oparte na wersjach niestabilnych jak również wersjach bez zagwarantowanego wsparcia technicznego. 33

34 6.2 WYMAGANIA DOTYCZĄCE WYDAJNOŚCI I POJEMNOŚCI 1 System powinien posiadać wydajność i pojemność wystarczającą do sprawnego funkcjonowania, przez minimum 5 lat od odbioru końcowego. 2 Wydajność systemu powinna być dostosowana do ilości przetwarzanych danych, liczby użytkowników oraz liczby transakcji przy zachowaniu zapasu zakładającego wzrost obciążenia systemu w przyszłości. 3 System powinien spełniać następujące wymagania dotyczące wydajności: 1) maksymalny czas odpowiedzi nieprzekraczający 3 sek. (przy założeniu warunków sieci LAN 100 Mbps i większej oraz zamawianego sprzętu i oprogramowania), 2) przepustowość - min. 30 obsługiwanych jednocześnie poleceń usługi wyszukiwania, 3) dostępność - 99 % czasu funkcjonowania danego serwisu. 4 System musi być skalowalny, przy czym skalowanie systemu może odbywać się przez: 1) dołączenie dodatkowych stanowisk - zwiększanie liczby użytkowników, 2) rozbudowę warstwy aplikacyjnej poprzez zwiększenie zasobów serwera, rozbudowę pamięci, zwiększenie liczby procesorów, 3) rozbudowę warstwy bazodanowej poprzez zwiększenie zasobów serwera, rozbudowę pamięci, zwiększenie liczby procesorów, zwiększenie pojemności pamięci masowych. 5 Odpowiednia pojemność systemu oznacza możliwość przechowywania w systemie takiej ilości danych, jaka średnio zgromadzona będzie w okresie 5 lat oraz dodatkowo 20 % tej wielkości (zapas). 6 System powinien zapewniać właściwą skalowalność w zakresie usług sieciowych zgodnie z załącznikiem nr 1 rozporządzenia komisji (WE) NR 976/2009 z dnia 19 października 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady. 34

35 6.3 WYMAGANIA DOTYCZĄCE BEZPIECZEŃSTWA 1. System ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego powinien umożliwiać tworzenie kopii zapasowych (archiwizację pełną i przyrostową) danych nie rzadziej niż raz dziennie. 2. System ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego powinien umożliwiać wybór między archiwizacją pełną, a przyrostową, przy założeniu takim, że na podstawie kopii zapasowych powinno być możliwe automatyczne odtworzenie systemu wraz z danymi w dowolnym momencie. 3. System ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego powinien zapewnić działania zgodnie z zasadami gwarantującymi taką eksploatację infrastruktury, aby zapewnić bezpieczeństwo informacji rozumiane jako: poufność, integralność i dostępność, przy uwzględnieniu autentyczności, rozliczalności, niezaprzeczalności i niezawodności. 6.4 WYMAGANIA DOTYCZĄCE HARMONIZACJI I INTEROPERACYJNOŚCI ZBIORÓW DANYCH PRZESTRZENNYCH I USŁUG 1. Zamawiający wymaga, by zbiory danych Systemu ewidencji i zarządzania drogami wojewódzkimi, Województwa Kujawsko Pomorskiego były zbudowane i zharmonizowane, zgodnie z obowiązującymi w czasie wykonywania umowy przepisami prawa, normami i standardami, obwiązującymi na terenie kraju, a w przypadku ich braku, zgodnie z normami i standardami międzynarodowymi. 2. System musi zapewniać interoperacyjność zbiorów danych przestrzennych poprzez stosowanie otwartych i jawnych standardów zapisu danych przestrzennych zgodnie z normą PN-EN-ISO Informacja geograficzna Środki dostępu do obiektów prostych (odpowiednik - Standard OGC: OpenGIS Simple Features - SQL - Types and Functions). Norma ta gwarantuje neutralność technologiczną, otwartość i jawność używanych standardów i specyfikacji zapisu danych przestrzennych, uznanych przez organizacje międzynarodowe. 35

36 6.5 WYMAGANIA DOTYCZĄCE ARCHITEKTURY SYSTEMU 1. Architektura systemu musi składać się z modułów dziedzinowych, w ramach których prowadzone są poszczególne rejestry i ewidencje. 2. Interfejsy systemu muszą być dostępne z poziomu przeglądarki internetowej, 3. Architektura systemu musi zapewniać przechowywanie danych w relacyjnej bazie danych w jawnych, otwartych standardach. 4. Architektura systemu musi zapewniać centralizację gromadzonych w nim danych przy jednoczesnym rozproszeniu dostępności usług, pozwalających na formalne zarządzanie tymi zasobami przez upoważnione osoby, zgodnie z ich formalnymi kompetencjami. 5. Architektura systemu musi zapewniać dostęp do aktualnych danych systemu, w trybie online, umożliwiając pełne zarządzanie tymi danymi (dostęp do danych, edycja, danych, zarządzanie danymi, generowanie raportów, wydruków map itp.). 6. Architektura systemu musi zapewnić wzajemne udostępnianie usług danych przestrzennych (np. WMS) przez poszczególne moduły dziedzinowe systemu. 7. Architektura systemu musi pozwalać na: a) definiowanie hierarchii poszczególnych poziomów administracji systemem, zgodnie z odpowiedzialnością poszczególnych użytkowników zarządu za utrzymywane zasoby, b) zarządzanie określonymi modułami dziedzinowymi na wskazanych stanowiskach w zakresie uprawnień edycyjnych lub informacyjnych, c) obsługę poszczególnych procedur dzięki e-usługom, z zapewnieniem dostępu do aktualnych danych prowadzonych przez Zarząd Dróg Wojewódzkich w Bydgoszczy lub Rejony Dróg Wojewódzkie, d) udostępnienie informacji publicznej oraz e-usług dla obywateli, przedsiębiorców oraz innych jednostek. 8. Architektura systemu musi zapewniać scentralizowaną administrację uprawnieniami dostępu do poszczególnych rejestrów i ewidencji, przynajmniej w zakresie: a) definiowania użytkowników, b) przypisywania ról aplikacyjnych do użytkowników, c) definiowana grup użytkowników i przypisanych im ról, 36

37 d) definiowania parametrów zabezpieczeń logowania i reguł haseł, e) definiowana harmonogramów logowania. 9. Architektura systemu musi zapewniać scentralizowane monitorowanie czynności wykonywanych przez użytkowników w poszczególnych rejestrach i ewidencjach, z uwzględnieniem hierarchii poszczególnych poziomów administracji systemem, przynajmniej w zakresie: a) dziennika logowania do systemu, b) aktywności przeglądania stron poszczególnych rejestrów, c) szczegółowych aktywności wykonanych operacji w poszczególnych rejestrach. 10. Architektura systemu musi umożliwiać przechowywanie informacji dotyczącej daty utworzenia i modyfikacji danego rekordu oraz informacji o użytkowniku, który utworzył lub zmodyfikował dany rekord. Informacja ta musi być dostępna dla użytkownika z poziomu interfejsu rejestrów i ewidencji. 37

38 7 OGÓLNE WYMAGANIA FUNKCJONALNE SYSTEMU Zamawiający wymaga, aby System ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego cechował się interoperacyjnością na poziomie organizacyjnym, semantycznym i technologicznym, obejmującą Zarząd Dróg Wojewódzkich w Bydgoszczy i podległe mu Rejony, gwarantującą neutralność technologiczną, otwarte standardy formatu danych przestrzennych oraz zharmonizowane zarządzanie zbiorami danych. Biorąc po uwagę powyższe, Zamawiający bezwzględnie wymaga, aby wdrożone oprogramowanie, obejmujące wszystkie rejestry i ewidencje zamawianego Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego, spełniało poniższe wymagania. 7.1 WYMAGANIA OGÓLNE DOTYCZĄCE SYSTEMU System ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego powinien zostać wykonany zgodnie z następującymi ogólnymi wymaganiami funkcjonalnymi: 1. Realizacja Systemu ewidencji i zarządzania drogami wojewódzkimi Województwa Kujawsko Pomorskiego musi być zgodna z aktualnymi przepisami prawnymi, a usługi serwisowe muszą obejmować zmiany prawne, jeśli takie nastąpią w trakcie realizacji umowy nawet po wykonaniu danego podsystemu. 2. System musi zapewniać bezpieczeństwo, szybkość przepływu i aktualność zgromadzonych w nim informacji, poprzez oparcie go na jednej bazie danych. 3. Dane i informacje muszą być wymieniane pomiędzy podmiotami na bieżąco, poprzez posiadaną infrastrukturę sieciową, tak aby nie kopiować i nie powielać zasobów utrzymywanych przez poszczególne podmioty, a tym bardziej uniknąć wielokrotnego i kosztownego ich opracowywania. 4. Integracja dostępu do usług mapowych musi być wykonana w ramach technologii WWW, w której klientem systemu będzie aplikacja, uruchamiana w przeglądarce internetowej. 5. System musi umożliwić wzajemne wykorzystywanie danych z poszczególnych rejestrów, w celu zapewnienia ich wiarygodności i aktualności, a także utworzyć relacje pomiędzy obiektami zachowywanymi w różnych rejestrach, aby dostęp do określonych obiektów był możliwy przez powiązane obiekty z innych rejestrów. 38

39 7. System musi posiadać charakter otwarty, posiadając jednocześnie bezpieczne mechanizmy umożliwiające pozyskanie i aktualizację danych rejestrów i ewidencji zarówno dla pracowników zarządu, jak i pracowników rejonów zlokalizowanych na terenie województwa. 8. System powinien posiadać spójną strukturę baz danych, zapewniającą jednocześnie zgodność z minimalnymi wymaganiami dla rejestrów publicznych i wymiany informacji w postaci elektronicznej określonymi w nowym rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. jakimi są : a) integralności danych, b) autentyczności danych, c) dostępności do danych, 9. Użytkownicy zewnętrzni systemu (mieszkańcy, przedsiębiorcy i inne podmioty) korzystający z e-usług, powinni mieć udostępniony odpowiedni interfejs poprzez przeglądarki internetowe. 7.2 WYMAGANIA OGÓLNE DOTYCZĄCE REJESTRÓW I EWIDENCJI SYSTEMU. Poniżej przedstawiono kluczowe wymagania funkcjonalne dotyczące integracji podsystemów: 1) System będzie posiadał charakter modułowy, składający się z poszczególnych podsystemów dziedzinowych, w ramach których prowadzone będą określone rejestry i ewidencje, których celem będzie wspieranie procesów realizowanych przez jednostki organizacyjne Zarządu Dróg Wojewódzkich (centrala i sześć rejonów). 2) System musi zapewniać współdziałanie rejestrów i ewidencji, osiągane poprzez: a) ich jednolitość, rozumianą jako stosowanie kompatybilnych norm, standardów i procedur do ich budowy, b) ich zgodność, rozumianą jako przydatność produktów, procesów lub usług przeznaczonych do ich wspólnego użytkowania. 3) System musi zapewniać współdziałanie rejestrów i ewidencji na poziomie: a) organizacyjnym, gwarantującym: i) przepływ informacji pomiędzy jednostkami organizacyjnymi, ii) standaryzację i ujednolicenie procedur w poszczególnych jednostkach organizacyjnych, 39

40 iii) zapewnienie dostępu do danych publicznych zawartych w rejestrach, z poziomu WWW, b) semantycznym, gwarantującym: i) stosowanie jednolitych modeli danych i ich znaczenia, ii) wzajemną referencyjność rejestrów i ewidencji, ze szczególnym uwzględnieniem krajowej infrastruktury informacji przestrzennej oraz projektu budowy SIP województwa kujawsko-pomorskiego, realizowanego w ramach projektu finansowanego ze środków UE pt.: Infostrada Pomorza i Kujaw, c) technologicznym, gwarantującym: i) jednolitość zastosowanych rozwiązań technologicznych, ii) neutralność technologiczną systemu. 4) Współdziałanie rejestrów i ewidencji systemu musi gwarantować dostęp do aktualnych danych zawartych w tych rejestrach, za pomocą jednolitych i standardowych interfejsów systemu, zapewniających standaryzację wykonywanych czynności. 5) System musi mieć charakter usługowy, dzięki czemu musi zapewniać: a) interfejsy zorientowane na procesy, uzależnione od uprawnień nadanych użytkownikowi oraz aktualnego stanu baz danych, b) możliwość kontekstowego uruchomienia interfejsów wielu rejestrów, w sytuacji gdy dane tych rejestrów są ze sobą powiązane, a obsługa danego rejestru wymaga dostępu do danych w innym rejestrze. 6) Poszczególne systemy dziedzinowe stanowić będą zintegrowane rozwiązanie do kompleksowego prowadzenia rejestrów i ewidencji. Będą oparte o technologię WWW, gdzie wszystkie czynności związane z obsługą danych (podgląd, edycja) będą realizowane z poziomu przeglądarki internetowej, bez konieczności instalowania dodatkowego oprogramowania po stronie użytkownika. Takie rozwiązania wraz z powszechnością dostępu do sieci telefonii komórkowych, zagwarantuje możliwość pracy z systemem z dowolnego miejsca, a w szczególności umożliwi pracę w jednym systemie wielu rejonom drogowym. 7) Dane użytkowe wraz z aplikacjami do ich odczytywania i edytowania będą znajdować się w jednej centralnej bazie danych, zlokalizowanej w siedzibie Zamawiającego lub w miejscu wskazanym przez Zamawiającego. 40

41 8) System będzie przechowywał dane w relacyjnej bazie danych, a dane przestrzenne przechowywane będą w jawnych, otwartych standardach, np. Oracle Spatial. 9) System zapewni prowadzenie rejestrów i ewidencji z poziomu zintegrowanych, standardowych dla niego interfejsów: a) opisowego (listy, zestawienia, formularze, tabele, zakładki), który umożliwia prowadzenie oraz przeglądanie relacyjnych baz danych i z poziomu którego użytkownik musi mieć możliwość przejścia do interfejsu graficznego, b) graficznego, gdzie dane prezentowane są poprzez okno mapy, które w zakresie przeglądania danych i ich prostej analizy jest zbliżone funkcjonalnością do klasycznych aplikacji GIS typu desktop i z poziomu którego użytkownik musi mieć możliwość przejścia do interfejsu opisowego. 10) Interfejs opisowy musi zapewnić prezentowanie aktualnych danych zawartych w rejestrach i ewidencjach w postaci tabelarycznej, a użytkownik musi posiadać możliwość zapisania jej konfiguracji i ponownego wykorzystania, przynajmniej przez: a) wybór lub ukrywanie kolumn tabeli, b) określenie sposobu sortowania kolumn tabeli, c) grupowanie po wybranych kolumnach tabeli, d) definiowanie ilości wierszy tabeli, 11) Z poziomu interfejsu opisowego, system musi zapewniać użytkownikowi standardowe funkcje wyszukiwania danych zawartych w rejestrach i ewidencjach, z możliwością zapisania parametrów wyszukiwania i ich ponownego wykorzystania, przynajmniej przez: a) wyszukiwanie na podstawie dowolnej frazy, b) wyszukiwanie poprzez definiowanie zapytania, w tym definiowanie poszukiwanych atrybutów, związanych z nimi operatorów logicznych i wartości, z zapewnieniem możliwości łączenia wielu wyszukiwań. 12) System musi zapewniać wyszukiwanie danych zawartych w rejestrach i ewidencjach z poziomu interfejsu graficznego poprzez określenie zakresu przestrzennego wyszukiwania. 13) System musi zapewnić łączenie wyszukiwania wykonanego z poziomu interfejsu opisowego i graficznego. 41

42 14) Wyniki wyszukiwania muszą być prezentowane w postaci tabelarycznej określonej w pkt. 10. i zawsze muszą prezentować aktualne dane. 15) Interfejs opisowy musi zapewnić użytkownikowi możliwość pobrania danych prezentowanych w postaci tabelarycznej do pliku formacie Excel lub pliku w formacie PDF. 16) Mapa i jej wydruk będzie dynamicznie tworzonym raportem prezentującym atrybuty geometryczne i opisowe pochodzące z bazy danych. System zapewni wgląd w dane przestrzenne realizowany bez konieczności generowania jakiekolwiek warstwy pośredniej (np. rysunku wektorowego). Aktualny stan bazy danych przestrzennych będzie widoczny (renderowany) na ekranie komputera w postaci mapy, a każda zmiana danych powinna powodować automatyczne uaktualnienie rysunku. 17) Dostęp do danych będzie regulowany poprzez system uprawnień dla zakresu rzeczowego i przestrzennego. Zapewni on nadzór nad działaniami użytkowników systemu, zarówno bezpośrednio uczestniczących w procesach zarządzania, jak i tych, dla których system będzie jedynie źródłem pozyskiwania danych wykorzystywanych do innych celów (np. Centrum Zarządzania Kryzysowego Wojewody Kujawsko - Pomorskiego, Departamenty Urzędu Marszałkowskiego). 18) Funkcjonalność aplikacji mobilnych będzie tożsama z aplikacjami stacjonarnymi. Różnić będzie się jedynie interfejsem użytkownika, którego wygląd zostanie dostosowany do wymagań i rozdzielczości wyświetlania urządzeń przenośnych. Ma to zapewnić jednolitość i spójność interfejsów bez względu na rodzaj urządzeń wykorzystywanych do ich obsługi. 19) System będzie posiadał budowę modułową, z możliwością rozbudowy o dalsze pola działania, zachowując przy tym integralność danych. 7.3 WYMAGANIA OGÓLNE DOTYCZĄCE E-USŁUG Przedmiot wdrożenia powinien obejmować dostawę, instalację i konfigurację usługi internetowej on-line na poziomie 1 informacja są to usługi zapewniające dostępność informacji (on-line) niezbędnej do rozpoczęcia jakiegoś procesu. 42

43 8 SZCZEGÓŁOWE WYMAGANIA FUNKCJONALNE MODUŁÓW DZIEDZINOWYCH SYSTEMU. 8.1 MODUŁ ZARZĄDZANIA SYSTEMEM REFERENCYJNYM 1. Określenie lokalizacji wszystkich zdarzeń drogowych będzie zachodziło w odniesieniu do systemu referencyjnego opartego na punktach węzłowych i odcinkach międzywęzłowych. Gdzie głównym założeniem będzie podział drogi na odcinki ograniczone punktami węzłowymi zlokalizowanymi w miejscach charakterystycznych drogi np. punkt przecięcia osi dróg, punkt przecięcia osi drogi z granica administracyjna, początek obiektu mostowego. 2. Lokalizacja wszystkich zdarzeń będzie zachodziła w dwojaki sposób. Poprzez określenie: a) kilometraża zdarzenia, licząc odległość zdarzenia od początku drogi (Nr drogi - kilometraż) b) pikietaża zdarzenia, licząc odległość od początkowego punktu referencyjnego odcinka na którym się znajduje dane zdarzenie (Nr drogi - nr odcinka - nr punktu początkowego - pikietaż) 3. Numeracja punktów referencyjnych będzie prowadzona według następujących zasad: a) Przyjęta zostanie 7-cyfrowy szablon numeru gdzie pierwsze cztery cyfry oznaczają numer sektora w którym znajduje się punkt, a trzy ostatnie oznaczają kolejny numer punktu w danym sektorze b) sektor początkowy o numerze 0101 bierze swój początek od 14 stopnia długości i 55 stopnia szerokości geograficznej c) obszar sektora odpowiada wielkości arkusza mapy topograficznej w skali 1 : d) numeracja sektorów rośnie w sposób następujący: w kierunku z zachodu na wschód 0101, 0102, 0103, ; oraz w kierunku z północy na południe 0101, 0201, ; 4. Punkty referencyjne będą posiadać następujące, edytowalne, atrybuty: a) Numer sektora b) Numer punktu w sektorze c) Współrzędne X i Y oraz ich pochodzenie 43

44 Ponadto do punktu będzie możliwość załączenia dowolnych dokumentów w postaci np. szkiców topograficznych lub zdjęć. 5. Odcinki międzywęzłowe będą numerowane narastająco zgodnie z kierunkiem przebiegu drogi według schematu 010, 020, a opisywać je będą następujące, edytowalne atrybuty: a) Numer drogi do której należy odcinek b) Numer kolejny odcinka c) Nazwa ulicy (jeżeli występuje) d) Kilometraż początkowy e) Kilometraż końcowy f) Numer punktu początkowego g) Numer punktu końcowego h) Klasę techniczną odcinka i) Rodzaj odcinka (główny, nieciągłość, sięgacz, łącznik...) j) Długość odcinka 6. Określenie lokalizacji danego zdarzenia drogowego w systemie referencyjnym musi zachodzić automatycznie, na podstawie relacji przestrzennej zdarzenia drogowego w stosunku do systemu referencyjnego. 7. System będzie umożliwiał edycję danych systemu referencyjnego z wykorzystaniem wyłącznie przeglądarki internetowej, podczas edycji możliwa będzie zmiana: a) korekta geometrii osi odcinka b) dodanie nowego odcinka c) dodanie nowego punktu d) korekta długości odcinka e) atrybutów opisowych f) kierunku przebiegu odcinka 8. Podczas edycji systemu referencyjnego zapewniona będzie możliwość nanoszenia osi dróg na podstawie źródeł (podkładów) w postaci: a) plików wektorowych w formacie DXF, b) plików rastrowych posiadających georeferencje, 44

45 c) współrzędnych X, Y punktów załamań linii, zasilanych z plików txt. d) ortofotomapy, e) map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego. 9. System zapewni narzędzi kontroli poprawności tworzenia i edycji systemu referencyjnego w zakresie: a) zgodności numeracji punktów referencyjnych z numeracją sektora w którym dany punkt się znajduje, b) poprawności topologicznej relacji pomiędzy odcinkami referencyjnymi a punktami referencyjnymi: pod każdym odcinkiem referencyjnym musi znajdować się punkt węzłowy początkowy i końcowy, zgodność numeracji odcinków referencyjnych z kierunkiem dróg, c) poprawności relacji atrybutowych pomiędzy punktami referencyjnymi, odcinakami referencyjnymi i drogą: droga może przebiegać przez klika odcinków referencyjnych, jedna droga może przebiegać przez klika ulic, każdy punkt referencyjny referuje do n - odcinków i n - dróg które przez niego przebiegają, każdy punkt referencyjny posiada przypisanych n - kilometraży w tym jeden główny itp. 10. W ramach prowadzenia systemu referencyjnego system zapewni prowadzenie rejestru granic pasa drogowego. System zapewni powiązanie pasa drogowego z drogą oraz zapewni funkcje kontroli poprawności tworzonych i edytowanych pasów drogowych np. nachodzenie na siebie pasów drogowych. 11. W ramach prowadzenia systemu referencyjnego system zapewni prowadzenie stref skrzyżowania. 12. System będzie miał możliwość generowania raportów określonych obowiązującymi przepisami jak również będzie umożliwiał zdefiniowanie przez użytkownika własnych raportów i generowania ich w formatach: html, pdf, xls. 13. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością 45

46 wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.2 MODUŁ ZARZĄDZANIA INFRASTRUKTURĄ DROGOWĄ System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System będzie zapewniał prowadzenie ewidencji dróg w dowiązaniu do systemu referencyjnego. Ewidencja zawierać będzie następujący zakres rzeczowy: a) Książka drogi, b) Dziennik objazdów, c) Mapa techniczno-eksploatacyjna. System będzie umożliwiał prowadzenie ewidencji zdarzeń drogowych (elementów powierzchniowych, liniowych i punktowych) zgodnie z obowiązującymi przepisami prawa. System musi przechowywać geometrię zdarzeń drogowych zgodnie z ich stanem faktycznym w terenie, bez konieczności dzielenia obiektów w obszarze skrzyżowań oraz bez konieczności dzielenia obiektów przy zmianie ich szerokości na kilometrażu o 0.5m. System musi umożliwiać automatyczne rejestrowanie atrybutów lokalizacji zdarzenia drogowego zlokalizowanego w pasie drogowym, z uwzględnieniem zdarzeń zlokalizowanych w obszarach skrzyżowań, w tym: a) numer drogi/ulicy b) kilometraż początkowy i końcowy zdarzenia drogowego, c) tzw. pikietaż tj. odległość zdarzenia drogowego od najbliższego punktu referencyjnego, wraz z numerem tego punktu i odcinka referencyjnego oraz długością zdarzenia. d) strona zdarzenia drogowego (lewa, prawa), System musi zapewniać automatyczne wyliczanie powierzchni i długości zdarzeń drogowych, z uwzględnieniem enklaw. System musi umożliwiać wyszukiwanie zdarzeń drogowych, poprzez podanie: a) kilometraża początkowego i końcowego drogi wraz z możliwością wskazania na mapie, 46

47 b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie, System musi umożliwiać wyszukiwanie zdarzeń drogowych poprzez narysowanie obszaru wyszukiwania na mapie, z automatycznym rozliczeniem zdarzeń drogowych w analizowanym obszarze. W takim przypadku systemu musi prezentować w postaci raportu atrybuty zdarzeń drogowych, w tym dane dotyczące rozliczonych powierzchni i długości zdarzeń drogowych, wraz z możliwością ich lokalizacji na mapie, a każda zmiana obszaru na mapie, powinna powodować automatyczne uaktualnienie raportu. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych zdarzeniach drogowych, takich jak: a) grupowanie według dowolnego atrybutu, b) sumowanie z uwzględnieniem grupowania, c) filtrowanie według wynranego atrybutu, d) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria. System musi umożliwiać edycję danych drogowych z wykorzystaniem przeglądarki internetowej. Podczas edycji musi być zapewniona następująca funkcjonalność: a) snapowanie do wybranych warstw infrastruktury drogowej lub innych, stanowiących źródło pozyskania geometrii zdarzeń, b) możliwość tworzenia obiektów na podstawie źródeł (podkładów) w postaci: I. plików rastrowych posiadających georeferencję, II. współrzędnych X,Y punktów załamań linii, zasilanych w postaci plików txt, III. wyników pomiarów bezpośrednich z terenu, wykonanych przy użyciu metody pomiarów ortogonalnych (bieżąca, domiar), IV. ortofotomapy, V. mapy ewidencyjnej, VI. map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego. 47

48 10. System musi mieć możliwość zdefiniowania przez użytkownika własnych raportów i generowania ich w formatach: html, pdf, xls. 11. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.3 MODUŁ ZARZĄDZANIA INFRASTRUKTURĄ MOSTOWĄ System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System będzie zapewniał prowadzenie ewidencja obiektów inżynieryjnych w dowiązaniu do systemu referencyjnego. 2. Ewidencja zawierać będzie następujący zakres rzeczowy: a) Książkę Obiektu Mostowego dla mostu, wiaduktu, estakady, kładki dla pieszych b) Książkę Tunelu dla tunelu drogowego c) Książkę Tunelu dla przejścia podziemnego d) Wykazy I. obiektów mostowych II. tuneli dla tuneli drogowych III. tuneli dla przejść podziemnych IV. przepustów e) Kartę Obiektu Mostowego System będzie umożliwiał prowadzenie ewidencji obiektów inżynieryjnych zgodnie z obowiązującymi przepisami prawa. System musi umożliwiać wyszukiwanie obiektów inżynieryjnych, poprzez podanie kilometraża początkowego i końcowego obiektu wraz z możliwością wskazania na mapie. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych obiektach inżynieryjnych, takich jak: a) grupowanie według dowolnego atrybutu, b) sumowanie z uwzględnieniem grupowania, c) filtrowanie według wybranego atrybutu, 48

49 d) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria. System musi umożliwiać edycję danych z wykorzystaniem przeglądarki internetowej. Podczas edycji musi być zapewniona następująca funkcjonalność: a) snapowanie do wybranych warstw infrastruktury drogowej lub innych, stanowiących źródło pozyskania geometrii obiektów, b) możliwość tworzenia obiektów na podstawie źródeł (podkładów) w postaci: I. plików rastrowych posiadających georeferencję, II. współrzędnych X,Y punktów załamań linii, zasilanych w postaci plików txt., III. wyników pomiarów bezpośrednich z terenu, wykonanych przy użyciu metody pomiarów ortogonalnych (bieżąca, domiar), IV. ortofotomapy, V. mapy ewidencyjnej, VI. map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego. 7. System musi umożliwiać wyszukiwanie obiektów inżynieryjnych poprzez narysowanie obszaru wyszukiwania na mapie. 8. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych obiektach inżynieryjnych, takich jak: a) grupowanie według dowolnego atrybutu, b) sumowanie z uwzględnieniem grupowania, c) filtrowanie według wynranego atrybutu, d) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria 9. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 49

50 8.4 MODUŁ ZARZĄDZANIA STANEM PRAWNYM ULIC I DRÓG System musi spełniać następujące, minimalne warunki integracji: 1. System musi zapewniać integrację z ewidencją gruntów i budynków, w zakresie: a) importu danych EGiB w formacie SWDE (pliki przedmiotowe, podmiotowe, zintegrowane), b) określania danych przedmiotowych i podmiotowych gruntów stanowiących drogi, c) kontroli spójności przebiegu pasów drogowych z granicami działek ewidencyjnych. 2. System musi zapewnić dostęp do danych EGiB dla celów informacyjnych dla działek znajdujących się w pasach drogowych, przecinających pasy drogowe oraz przyległych do pasów drogowych., w tym: d) dostęp do zintegrowanych danych ewidencji gruntów i budynków, e) możliwość wyszukiwania działek ewidencyjnych według ich atrybutów przedmiotowych i podmiotowych z filtrów przestrzennych (obszar na mapie), f) prezentację przekrojowych analiz w postaci map tematycznych:. mapa struktury własności (według grup rejestrowych), mapa użytkowania terenu (według rodzaju użytku gruntowego) g) generowanie wypisu i wyrysu, dla celów informacyjnych, zawierającego odpowiednią klauzulę, 2. System musi zapewniać automatyczne wykrywanie konfliktów pomiędzy pasem drogowym a działkami ewidencyjnymi w zakresie: a) działek przecinających pas drogowy, b) działek znajdujących się w pasie drogowym, które ze względu na stan własnościowy wymagają regulacji, c) użytków gruntowych, których oznaczenie jest niezgodne ze stanem faktycznym przebiegu pasa drogowego. 3. Dla wykrytych konfliktów działek z pasem drogowym, system musi zapewnić dostęp do zintegrowanych danych EGiB dotyczących tych działek. 4. Dla każdej drogi system musi pozwalać na rejestrację wykrytych konfliktów działek ewidencyjnych z drogą, z automatycznym określeniem: 50

51 a) identyfikatora działki ewidencyjnej, b) powierzchni konfliktu (przecięcia) c) szacunkowej wartości 1 m2 gruntu stanowiącego przedmiot ewentualnego wykupu d) obliczonej wartości wykupu gruntu będącego przedmiotem konfliktu z pasem drogowym. 5. Dla wykrytych konfliktów działek z pasem drogowym system musi posiadać narzędzia umożliwiające wsparcie procesu regulacji stanu prawnego, w tym: a) określenie trybu regulacji: I. art. 90 ustawy o gospodarce nieruchomościami, II. przenoszenie własności pomiędzy zasobami nieruchomości, III. regulacja stanów prawnych w ramach spec. ustawy, IV. regulacja stanów zastałych: art. 73 ustawy reformującej administrację publiczną V. wykup gruntów. b) określenie działek będących przedmiotem regulacji, wraz z powierzchniami regulacji działek oraz szacunkowym określeniem wartości wykupu działek, c) określanie działek będących wynikiem regulacji, z możliwością ich pobrania z bazy danych EGiB. 6. System musi pozwalać na rejestrację spraw, związanych z procesami regulacyjnymi, oraz odszkodowawczymi w tym: a) rejestrację numerów spraw, b) rejestrację interesantów, których sprawy dotyczą, c) dat rozpoczęcia sprawy i jej zakończenia, d) rejestrację poszczególnych etapów procesu regulacyjnego i odszkodowawczego, w tym: nazwa etapu, opis etapu, data rozpoczęcia etapu, data zakończenia etapu, rejestrację dowolnych załączników związanych z poszczególnymi etapami. 51

52 7. System musi zapewnić definiowanie etapów procesu regulacji oraz procesów odszkodowawczych. 8. System musi zapewniać przeglądanie historii procesu regulacyjnego i odszkodowawczego. 9. Dla procesów odszkodowawczych systemu musi pozwalać na rejestrację ceny wykupu gruntów. 10. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.5 MODUŁ ZARZĄDZANIA ORGANIZACJĄ RUCHU System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi umożliwić prowadzenie ewidencji oznakowania drogowego pionowego i poziomego ale również sygnalizacji, barier, ekranów oraz innych urządzeń bezpieczeństwa ruchu drogowego, zgodnie z obowiązującymi przepisami prawa, a w szczególności musi zapewnić prowadzenie organizacji ruchu oraz umożliwić generowanie raportów i statystyk. 2. System musi zapewniać gromadzenie i przetwarzanie danych w następującym zakresie: a) kod znaku, b) podgląd symbolu graficznego, c) treść znaku (tekst i grafika), d) położenie względem krawędzi jezdni e) lokalizacja w systemie referencyjnym (nr drogi, nr odcinka, węzeł początkowy, węzeł końcowy, pikietaż odcinka, kilometraż drogi, nazwa ulicy), f) lokalizacja na mapie (X,Y w przyjętym układzie współrzędnych), g) generacja znaku, h) stan znaku, i) technologia malowania (oznakowanie poziome), j) powierzchnia malowania (oznakowanie poziome), k) dokumentacja fotograficzna znaku, l) data wprowadzenia, 52

53 m) data wycofania. n) data usunięcia Wymagane jest rzeczywiste odzwierciedlenie oznakowania poziomego, tak aby było możliwe generowanie raportu o rzeczywistej powierzchni malowania. System musi umożliwiać edycję danych o oznakowaniu drogowym z wykorzystaniem przeglądarki internetowej. Podczas edycji musi być zapewniona następująca funkcjonalność: a) snapowanie do wybranych warstw infrastruktury drogowej lub innych stanowiących źródło pozyskania geometrii i lokalizacji znaków, b) możliwość nanoszenia znaków na podstawie źródeł (podkładów) w postaci: plików rastrowych posiadających georeferencję, c) współrzędnych X,Y punktów załamań linii, zasilanych w postaci plików txt d) wyników pomiarów bezpośrednich z terenu, wykonanych przy użyciu metody pomiarów ortogonalnych (bieżąca, domiar), e) ortofotomapy, f) mapy ewidencyjnej, g) map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego. System musi zapewnić lokalizację oznakowania w ramach systemu referencyjnego opartego na punktach referencyjnych i odcinkach międzywęzłowych. Określenie lokalizacji oznakowania w systemie referencyjnym musi zachodzić automatycznie, na podstawie relacji przestrzennej oznakowania w stosunku do systemu referencyjnego. System musi umożliwiać automatyczne rejestrowanie atrybutów lokalizacji oznakowania w stosunku do systemu referencyjnego, w tym: a) numer drogi, b) nazwa ulicy, c) kilometraż początkowy i końcowy zdarzenia drogowego, d) tzw. pikietaż tj. odległość zdarzenia drogowego od najbliższego punktu referencyjnego, wraz z numerem tego punktu i odcinka referencyjnego oraz długością zdarzenia, e) strona drogi (lewa, prawa). 53

54 System musi zapewnić możliwość rozbudowywania i edycji słowników znaków. System musi zapewnić możliwość wyświetlania na mapie oznakowania pionowego jako zdjęcia tego oznakowania wykonanego w terenie. System musi mieć możliwość podłączania załączników w postaci zdjęć (jpg), dokumentów (doc/pdf) oraz projektów organizacji ruchu w formie plików rastrowych z georeferencją lub plików wektorowych (dxf). System musi umożliwiać wyszukiwanie oznakowania, poprzez podanie: a) kilometraża początkowego i końcowego drogi wraz z możliwością wskazania na mapie, b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie, System musi umożliwiać wyszukiwanie oznakowania poprzez narysowanie obszaru wyszukiwania na mapie, a każda zmiana obszaru na mapie, powinna powodować automatyczne uaktualnienie tego raportu. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych zdarzeniach drogowych, takich jak: a) grupowanie według dowolnego atrybutu, b) sumowanie w grupach, c) filtrowanie według wymaganego atrybutu, d) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.6 MODUŁ ZAJĘCIA PASA DROGOWEGO System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi zapewnić lokalizację zajęć pasa drogowego w odniesieniu do systemu referencyjnego opartego na punktach referencyjnych i odcinkach międzywęzłowych. 54

55 2. Określenie lokalizacji zajęcia pasa drogowego w systemie referencyjnym musi zachodzić automatycznie, na podstawie relacji przestrzennej zajęcia pasa drogowego w stosunku do systemu referencyjnego. 3. System musi umożliwiać automatyczne rejestrowanie atrybutów lokalizacji zajęcia pasa drogowego w stosunku do systemu referencyjnego, w tym: a) numer drogi, b) nazwa ulicy, c) kilometraż początkowy i końcowy, d) tzw. pikietaż tj. odległość zdarzenia drogowego od najbliższego punktu referencyjnego, wraz z numerem tego punktu i odcinka referencyjnego oraz długością zdarzenia. 4. System musi zapewnić obsługę procesu wydawania decyzji o zajęciu pasa drogowego w następującym zakresie: a) Obsługa wniosków na zajęcie pasa drogowego: wniosek może zawierać kilka zajęć pasa drogowego, np. roboty drogowe prowadzone są w kilku miejscach na danej ulicy, wniosek może dotyczyć zajęcia celem prowadzenia robót lub w celu umieszczenia urządzenia w pasie drogowym. system musi pozwalać na odniesie przestrzenne zajęcia pasa drogowego do zdarzeń drogowych, system musi pozwalać na weryfikację i ewentualną automatyczną lub manualną poprawę danych ilościowych dotyczących deklarowanych we wniosku powierzchni i długości zajęć w poszczególnych rodzajach zdarzeń drogowych (jezdnie, chodniki, ścieżki rowerowe, pasy dzielące itp.) b) Obsługa spraw związanych z zajęciem pasa drogowego: dla jednego wniosku, system musi pozwalać na założenie kilku spraw, zgodnie z deklarowanym we wniosku celem zajęcia, system musi być zgodny z instrukcją kancelaryjną w zakresie numerowania wniosków, spraw i decyzji oraz pozwalać na ich automatyczną numerację. 55

56 system musi pozwalać na rejestrowanie statusów spraw: w toku, zakończona, zakończona nie rozpatrzona, wznowiona, system musi pozwolić na prezentację zakresu sprawy i jej statusu na mapie. c) Obsługa naliczania opłat związanych z zajęciem pasa drogowego: system musi pozwalać na automatyczne rozliczanie zajęcia pasa drogowego z wykorzystaniem obszaru zajęcia oraz rodzaju i powierzchni zdarzeń drogowych znajdujących się pod zajęciem pasa drogowego, system musi pozwalać na automatyczne naliczenie opłat na podstawie definiowalnych cenników. d) Obsługa decyzji na podstawie wprowadzonych wniosków: decyzje mogą być wydawane na podstawie kilku wniosków, o ile dotyczą one tego samego wnioskującego oraz tej samej kategorii drogi, możliwe jest wydawanie kilku decyzji do jednego wniosku, np. dla każdego zajęcia pasa we wniosku, celem prowadzenia robót, celem umieszczenia urządzenia nie związanego z infrastrukturą drogową, każda decyzja zawiera znak sprawy, nr i rok decyzji, kategorię drogi, datę wydania oraz geometrię (zakres przestrzenny) decyzji złożoną z wszystkich zaznaczonych na mapie zajęć pasa drogowego, system musi pozwalać na automatyczne generowanie dokumentów decyzji, system musi posiadać możliwość zdefiniowania szablonów generowanych decyzji o zajęciu pasa drogowego, system musi pozwolić na prezentację zakresu decyzji na mapie. 5. System musi pozwalać na obsługę zajęć pasa drogowego w zakresie minimum następujących informacji: wniosek, którego dotyczy, decyzja której dotyczy (jeżeli została wydana), sposób zajęcia pasa (stałe lub czasowe), cel zajęcia (pod reklamę, awaria, prowadzenie robót, umieszczenie w pasie drogowym infrastruktury technicznej niezwiązanej z drogą itd.), lokalizację w systemie referencyjnym i zakres przestrzenny na mapie, powierzchnię zajęcia, 56

57 rozliczenie powierzchni na poszczególne elementy pasa drogowego, datę rozpoczęcia i zakończenia zajęcia, termin gwarancji, załączników w formatach: tiff, jpg, doc, xls, dxf. 6. System musi posiadać edytowalne słowniki dotyczące: cen za poszczególne zajęcia, rodzajów zajęcia, celów zajęcia, rodzajów dokumentów stanowiących załączniki. 7. System musi zapewniać możliwość tworzenia zajęcia pasa drogowego na podstawie źródeł (podkładów) w postaci: a) plików rastrowych posiadających georeferencję, b) współrzędnych X,Y punktów załamań linii, zasilanych w postaci plików txt, c) wyników pomiarów bezpośrednich z terenu, wykonanych przy użyciu metody pomiarów ortogonalnych (bieżąca, domiar), d) ortofotomapy, e) mapy ewidencyjnej, f) map dostępnych w postaci usług np. ortofotomapa pochodząca z geoportalu krajowego. 8. System musi umożliwiać wyszukiwanie zajęć pasów drogowych, poprzez podanie: a) kilometraża początkowego i końcowego drogi wraz z możliwością wskazania na mapie, b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie. 9. System musi umożliwiać wyszukiwanie zajęć pasów drogowych poprzez podanie obszaru wyszukiwania na mapie, a każda zmiana parametrów wyszukiwania, powinna powodować automatyczne uaktualnienie tego raportu. 10. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych zajęciach pasów drogowych, takich jak: a) grupowanie według dowolnego atrybutu, 57

58 b) sumowanie z uwzględnieniem grupowania, c) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria. 11. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.7 MODUŁ ZARZĄDZANIA OBJAZDAMI DRÓG System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi składać się z następujących zintegrowanych modułów: a) planów objazdów, b) harmonogramów objazdów, c) dziennika objazdów. Plan objazdu musi zawierać definicje dotyczące objazdu dróg, w tym: a) nazwa objazdu b) wykaz odcinków referencyjnych dotyczących danego planu objazdu (plan objazdu może zawierać odcinki referencyjne pochodzące z różnych kategorii dróg). System musi pozwalać na tworzenie planu objazdu poprzez jego zdefiniowanie na mapie. Harmonogram objazdów musi zawierać dane dotyczące terminów wykonania objazdów, których definicja znajduje się w planie objazdu. Tworzenie harmonogramu objazdu musi polegać na: a) określeniu terminów wykonywania poszczególnych planów objazdów, b) określeniu częstości wykonania planu danego objazdu (np. raz w tygodniu w poniedziałek, lub konkretnej daty jego wykonania). System musi zapewnić automatyczną aktualizację harmonogramu objazdu (zmiana statusu w harmonogramie z planowany na wykonany), na podstawie wykonanego objazdu (zarejestrowanego śladu GPS). System musi zapewniać przeglądanie harmonogramu objazdów według: a) drogi, b) planowanych dat dokonania objazdów, 58

59 c) faktycznych dat dokonania objazdów, d) osoby dokonujące objazd. System musi zapewnić prowadzenie dziennika objazdów dróg, w tym: a) objazdów okresowych, zgodnie z wymaganiami książki drogi, b) objazdów interwencyjnych, c) objazdów bieżących, których wykonywanie związanie jest z bieżącym utrzymaniem dróg, a których wykonanie zostało zdefiniowane w harmonogramie objazdów. System musi przechowywać minimum następujące informacje dotyczące objazdu: a) nazwa objazdu (np. Objazd drogi wojewódzkiej nr 244) b) data rozpoczęcia i zakończenia objazdu, c) dane dotyczące osoby kontrolującej, d) numer dziennika objazdu w danym roku, e) status objazdu (dokonany, planowany), f) rodzaj objazdu (roczny, bieżący, interwencyjny) g) dane dotyczące drogi i odcinków referencyjnych, których dotyczył danych objazd, h) dane dotyczące zarejestrowanych na drodze awarii i usterek, których dotyczył dany objazd, i) dowolne załączniki związane z danym objazdem. System musi współpracować z systemem mobilnej pracy w terenie, umożliwiającym z jednej strony automatyczne dokonywanie wpisów do dziennika objazdów dróg na podstawie zarejestrowanego śladu GPS pojazdu, z drugiej strony pozwoli na automatyczną rejestrację wad i usterek zlokalizowanych w ramach dokonywanych objazdów. System musi dostarczyć zarówno dane jakościowe dotyczące lokalizacji poszczególnych wad i usterek zarejestrowanych w ramach objazdu na sieci referencyjnej (dane o kilometrażu i pikietażu, szczegółowe dane dotyczące rodzaju wady, usterki, jej natężenia, sposobu usunięcia itp.) jak i dane ilościowe dotyczące ilości wad i usterek na danym odcinku referencyjnym, drodze itp. System musi zapewnić przeglądanie dziennika wykonanych objazdów według: a) numeru drogi, 59

60 b) osoby kontrolującej, c) daty wykonania objazdu, d) rodzaju objazdu, e) rodzaju i ilości zarejestrowanych usterek. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 8.8 MODUŁ ZARZĄDZANIA UTRZYMANIEM BIEŻĄCYM DRÓG System zarządzania utrzymaniem bieżącym będzie spełniał następujące, minimalne wymagania funkcjonalne: 1. Zadaniem systemu musi być wspomaganie procesów związanych z zarządzaniem pracami bieżącymi, dotyczącymi: a) usunięcia zarejestrowanych w ramach objazdów awarii i usterek, b) usunięcia awarii i usterek, zgłaszanych z zewnątrz, c) zlecenia wykonania innych prac np. umieszczenie oznakowania pionowego, udrożnienie odwodnienia itp. 2. System musi zapewnić lokalizację prac w stosunku do systemu referencyjnego opartego na punktach referencyjnych i odcinkach międzywęzłowych oraz ich powiązanie z zarejestrowanymi awariami i usterkami. 3. System musi umożliwić prowadzenie rejestru zleceń prac, umożliwiającego precyzyjne zarządzanie tymi pracami, a w szczególności umożliwiającego określenie, kto, kiedy, gdzie oraz jakie prace ma wykonać. 4. Zlecenia prac mogą dotyczyć zleceń realizowanych przez pracowników wojewódzkiego zarządu dróg (zlecenia wewnętrzne), lub też jednostek zewnętrznych z którymi zarząd dróg wojewódzkich posiada odpowiednią umowę na wykonywanie tych prac (zlecenia zewnętrzne). 5. System będzie ściśle zintegrowany z systemem mobilnej pracy, w ramach którego pracownik, posiadając mobilny dostęp do systemu, będzie mógł poświadczyć wykonanie danej pracy (zlecenia) na miejscu jej wykonania. 60

61 6. System zapewni numerowanie zleceń w sposób ciągły, w danym roku. 7. System będzie ściśle zintegrowany z systemem mobilnej pracy, w zakresie: a) tworzenie zleceń usunięcie awarii i usterek, zarejestrowanych w ramach objazdów, b) potwierdzania przez pracownika wykonanie danej pracy (zlecenia) na miejscu jej wykonania. 8. W ramach zlecenia powinny być rejestrowane: a) informacje dotyczące wykonawcy robót, b) informacje dotyczące wystawiającego zlecenie, c) informacje opisowe, d) informacje dotyczące daty wystawienia zlecenia, e) informacje dotyczące planowanej daty realizacji zlecenia, f) informacje dotyczące daty wykonania robót, g) informacje dotyczące statusu zlecenia (przekazano, wykonano, anulowano), h) informacje dotyczące, poszczególnych awarii i asortymentu robót, i) załączniki np. zdjęcia dotyczące awarii, opis usterek do usunięcia. 9. System musi pozwalać na generowanie zleceń prac, w postaci dokumentów *.pdf lub word. 10. System musi umożliwiać wyszukiwanie zleceń prac, poprzez podanie jednego z niżej wymienionych parametrów: a) kilometrażu początkowego i końcowego drogi wraz z możliwością wskazania na mapie, b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie. c) poprzez narysowanie obszaru wyszukiwania na mapie, a każda zmiana obszaru na mapie, powinna powodować automatyczne uaktualnienie tego raportu. 11. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. 61

62 12. System będzie miał możliwość generowania raportów określonych obowiązującymi przepisami jak również będzie umożliwiał zdefiniowanie przez użytkownika własnych raportów i generowania ich w formatach: html, pdf, xls. 8.9 MODUŁ ZARZĄDZANIA ROBOTAMI BUDOWLANYMI System zarządzania robotami budowlanymi będzie spełniał następujące, minimalne wymagania funkcjonalne: System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi zapewniać prowadzenie rejestru prac budowlanych realizowanych w ramach inwestycji: a) Remontów dróg, b) Przebudowy dróg, c) Rozbudowy dróg. d) Budowy dróg, 2. System musi zapewnić lokalizację zadań inwestycyjnych w ramach systemu referencyjnego opartego na punktach referencyjnych i odcinkach międzywęzłowych. 3. System musi umożliwić prowadzenie ewidencji, zgodnie z obowiązującymi przepisami prawa, a w szczególności musi zapewnić możliwość dokumentacji procesu inwestycyjnego, począwszy od planowania, poprzez projektowanie, budowę aż do obsługi gwarancji. 4. System powinien gromadzić minimum następujące dane o robotach budowlanych: a) zakres przestrzenny inwestycji określony na mapie, b) opis inwestycji, technologia c) wykonawca/ wykonawcy robót, (umowa na roboty) d) podwykonawcy robót, e) osoba odpowiedzialna za nadzór, f) daty rozpoczęcia i zakończenia robót, g) przekazaniu placu budowy, h) zakres, rodzaj wykonanych robót oraz ich koszty, i) Odbiory częściowe, końcowe, ostateczne 62

63 j) dane dotyczące, gwarancji, w tym: I. zakres gwarancji (np. jezdnia, chodnik, oznakowanie) II. powierzchnia, III. lokalizacja, IV. data rozpoczęcia gwarancji, V. data zakończenia gwarancji, k) kontrole jednostek zewnętrznych (np. Nadzór BUD., UM, UKS, NIK itp.) 5. System musi umożliwiać wyszukiwanie inwestycji, poprzez podanie: a) kilometraża początkowego i końcowego drogi wraz z możliwością wskazania na mapie, b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie. 6. System musi umożliwiać wyszukiwanie inwestycji poprzez narysowanie obszaru wyszukiwania na mapie, a każda zmiana obszaru na mapie, powinna powodować automatyczne uaktualnienie tego raportu. 7. System musi zapewniać wykonywanie podstawowych operacji na wyszukanych inwestycjach, takich jak: a) grupowanie według dowolnego atrybutu, b) sumowanie z uwzględnieniem grupowania, c) generowanie wykresów liniowych i kołowych, prezentujących dane spełniające zadane kryteria. 6. System musi być zintegrowany z modułem zarządzania dokumentacją budowlaną, umożliwiając dokumentowane procesu budowlanego. 7. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego MODUŁ ZARZĄDZANIA NAWIERZCHNIĄ DROGOWĄ System musi spełniać następujące, minimalne wymagania funkcjonalne: 63

64 1. System wspomagający zarządzanie nawierzchnią drogową musi umożliwiać przetwarzanie, analizy i wizualizację na mapach, danych otrzymanych w wyniku punktowej oceny stanu nawierzchni dróg wykonywanej w ramach obowiązkowych kontroli okresowych. 2. Ocena stanu nawierzchni będzie wykonywana według metody BIKB - IBDM opracowanej przez Instytut Badawczy Dróg i Mostów w Warszawie. Założeniem metody jest przypisanie ocenianemu odcinkowi punktów karnych na podstawie których określana jest średnia ocena punktowa dla danego odcinka. 3. System musi umożliwiać archiwizowanie danych wynikowych, wykonanych metodą BIKB - IBDM i ich udostępnianie w taki sposób żeby było możliwe zestawienie i porównanie wyników z różnych okresów, a w rezultacie określenie stopnia dekapitalizacji dróg w żądanym okresie. 4. Oprócz stanu nawierzchni jezdni głównych system musi gromadzić informacje na temat stanu nawierzchni: a) chodników b) ścieżek rowerowych c) zatok autobusowych d) zatok postojowych e) torowisk tramwajowych f) skrzyżowań z koleją System musi pozwalać na gromadzenie informacji dotyczących stanu technicznego pozostałych elementów zagospodarowania i wyposażenia pasa drogowego, takich jak: a) oznakowanie pionowe b) oznakowanie poziome c) sygnalizacja d) bariery i ekrany e) pobocza utwardzone i nieutwardzone f) odwodnienie System musi pozwalać na prezentację danych o stanie nawierzchni elementów powierzchniowych w postaci map tematycznych, w postaci wypełnienia obiektu 64

65 odpowiednim kolorem, oznaczającym stan danego elementu. Wypełnienie powierzchni odpowiednim kolorem będzie odzwierciedlało rzeczywisty kształt i powierzchnie danego elementu, dzięki temu możliwe będzie przeprowadzanie analiz przestrzennych w podziale na stan nawierzchni. Elementy określające stan nawierzchni muszą posiadać również określoną lokalizację w ciągu drogi poprzez kilometraż i pikietaż lokalny, co umożliwi analizy stanu nawierzchni względem przebiegu drogi. 8. System musi posiadać funkcję przeglądania dokumentacji fotograficznej pasa drogowego, wykonanej w postaci zdjęć sferycznych z interwałem 5m, obejmujących przegląd sytuacji w płaszczyźnie poziomej w zakresie oraz w płaszczyźnie pionowej w minimalnym zakresie Zdjęcia sferyczne musza stanowić zespolony obraz wykonany z sześciu kamer jednocześnie o rozdzielczości minimalnej każdego zdjęcia 1600 x 1200 pikseli. 9. System musi zapewnić lokalizowanie poszczególnych zdjęć w systemie referencyjnym poprzez podanie: a) nr drogi na której zostało wykonane zdjęcie b) nr odcinka na którym zostało wykonane zdjęcie c) kilometraż oraz pikietaż zdjęcia 10. Ponadto funkcja przeglądania zdjęć musi zapewnić możliwość określanie współrzędnych elementów widocznych na zdjęciach w układzie współrzędnych zgodnym z systemem referencyjnym. System musi posiadać możliwość generowania raportów i wykazów zgodnych z obowiązującymi przepisami jak również będzie umożliwiał zdefiniowanie przez użytkownika własnych raportów i generowania ich w formatach: html, pdf, xls. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego MODUŁ ZARZĄDZANIA NATĘŻENIEM RUCHU DROGOWEGO System musi spełniać następujące, minimalne warunki integracji: 1. Wymagania ogólne dotyczące integracji rejestrów i ewidencji systemu. 65

66 2. Integrację z ewidencją gruntów i budynków (EGiB) w zakresie: a) określania danych przedmiotowych i podmiotowych gruntów stanowiących drogi, b) kontroli spójności przebiegu pasów drogowych z granicami działek ewidencyjnych. Integrację z systemem referencyjnym w zakresie określenia lokalizacji punktów badania natężenia ruchu oraz występowania wypadków drogowych. System musi spełniać następujące minimalne wymagania funkcjonalne: 1. System musi wspomagać analizowanie i zarządzanie natężeniem ruchu na drogach wojewódzkich Województwa Kujawsko-Pomorskiego. 2. System musi umożliwiać archiwizowanie wyników pomiarów wykonywanych w sesjach zarówno z pomiarów cyklicznych jak i celowych. 3. System musi zapewnić integrację danych napływających z istniejących stacji automatycznego monitoringu natężenia ruchu, spełniających minimalne wymagania dotyczące podziału na poszczególne rodzaje pojazdów: a) motocykle, b) osobowe, c) osobowe/dostawcze z przyczepą, d) dostawcze do 3,5 t, e) ciężarowe, f) ciężarowe z przyczepą, g) ciągniki siodłowe, h) autobusy, i) niesklasyfikowane. System musi zapewniać graficzną prezentację danych o natężeniu ruchu drogowego zarówno dla średniego natężenia dobowego dla ogółu pojazdów jak i w podziale na klasy pojazdów, czy też rodzaje i przyczyny wypadków. Dane muszą być wizualizowane na tle mapy sieci drogowej w postaci symboli, grafów, wykresów obrazujących zarówno stany natężenia danego zjawisk jak i trendy ich zmian. 66

67 Oprócz wizualizacji graficznej wymagane jest generowanie raportów, wykazów i wykresów obrazujących zarówno stany natężenia zjawisk jak i trendy ich zmian. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego MODUŁ ZARZĄDZANIA DOKUMENTACJĄ System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System umożliwi centralne zarządzanie dokumentacją drogową dotyczącą remontu, budowy, lub przebudowy dróg, na która składać się będą następujące rodzaje dokumentów: a) dokumenty graficzne dotyczące dokumentacji projektowej i powykonawczej (np. projekt przebudowy skrzyżowania, mapa do celów projektowych itp.) w postaci: 1. plików w formatach dxf, 2. plików rastrowych, 3. plików rastrowych z georeferencją, umożliwiające ich automatyczne wyświetlanie na mapach, b) dokumenty opisowe (np. decyzje o pozwoleniu na budowę) w postaci plików w formatach tiff, pdf lub word, c) dokumentacja fotograficzna. System musi zapewnić lokalizację dokumentacji w ramach systemu referencyjnego opartego na punktach referencyjnych i odcinkach międzywęzłowych a także możliwości jej wyszukiwania. Na centralne repozytorium składają się poszczególne zasoby dokumentów, dotyczące określonego zakresu rzeczowego i przestrzennego spraw związanych z przebudową, budową lub remontem np. dokumentacja projektowa przebudowy skrzyżowania, dokumentacja budowy chodnika, dokumentacja odbioru częściowego budowy drogi. W poszczególnych zasobach dokumentów system musi umożliwić tworzenie dowolnej ilości podgrup danego rodzaju dokumentów: np. 67

68 a) dla dokumentacji fotograficznej: dokumentacja prac ziemnych, dokumentacja wykonania konstrukcji nośnej nawierzchni, dokumentacja kanalizacji deszczowej, b) dla dokumentów opisowych: protokoły odbioru itp., c) dla dokumentów graficznych: projekt budowy drogi, projekt branżowy przebudowy kanalizacji, projekt organizacji ruchu itp. Słowniki opisujące poszczególne rodzaje dokumentów muszą być w pełni konfigurowalne przez administratora systemu. Centralne repozytorium dokumentacji zapewni tworzenie zasobów dokumentów oraz ich dołączanie z poziomu danego remontu, budowy lub przebudowy. System musi umożliwiać wyszukiwanie dokumentacji, poprzez podanie: a) kilometraża początkowego i końcowego drogi wraz z możliwością wskazania na mapie, b) piekatażu początkowego i końcowego odcinka referencyjnego wraz z możliwością wskazania na mapie. System musi umożliwiać wyszukiwanie dokumentacji poprzez narysowanie obszaru wyszukiwania na mapie, a każda zmiana obszaru na mapie, powinna powodować automatyczne uaktualnienie tego raportu. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego MODUŁ ZARZĄDZANIA TERMINAMI TERMINARZ DROGOWY Terminarz drogowy musi spełniać następujące, minimalne wymagania funkcjonalne: 1. Terminarz drogowy, będzie zbiorczym kalendarzem umożliwiającym prezentację kluczowych dla funkcjonowania wojewódzkiego zarządu dróg terminów pochodzących z poszczególnych modułów systemu: a) stanu prawnego ulic i dróg, b) dziennika objazdów, c) utrzymania bieżącego, d) robót budowlanych, 68

69 e) zajęcia pasa drogowego, f) organizacji ruchu drogowego. Terminarz drogowy będzie posiadał strukturę dziedzinową i hierarchiczną, w której określone moduły dziedzinowe będą posiadały dedykowane kalendarze, z jednoczesną możliwości integracji wielu kalendarzy zależnej od funkcji pełnionej przez danego pracownika w organizacji. System będzie udostępniał następujące rodzaje kalendarzy: a) kalendarz zajęcia pasa drogowego, prezentujący kluczowe terminy związane z zajęciem pasa drogowego, b) kalendarz regulacji stanów prawnych dróg, prezentujący kluczowe terminy związane z regulacją stanów prawnych oraz odszkodowań, c) kalendarz organizacji ruchu, prezentujący kluczowe terminy związane ze zmianą organizacji ruchu drogowego, d) kalendarz objazdów, prezentujący kluczowe terminy związane z planowanymi oraz wykonanymi objazdami, e) kalendarz prac bieżących, prezentujący kluczowe terminy związane z utrzymaniem bieżącym, f) kalendarz gwarancji prezentujący kluczowe terminy związane z udzielonymi gwarancjami. Każdy z ww. kalendarzy, będzie prezentować kluczowe terminy takie jak. np. terminy rozpoczęcia i zakończenia prac budowlanych, terminy zakończenia gwarancji, terminy przeglądów gwarancyjnych, terminy usunięcia wad i usterek itp. Z poziomu kalendarza użytkownik, będzie posiadał możliwość dotarcia do informacji związanej z danym terminem a znajdującej się w danym module dziedzinowym. System zapewni prezentacje danych w kalendarzu w postaci związanych z nim raportów z zapewnieniem możliwości ich przeszukiwania według parametrów, zdefiniowanych prze użytkownika np. wszystkie gwarancje wygasające w tym miesiącu, lub wszystkie usterki, które w tym tygodniu należy usunąć itp MODUŁ ZARZĄDZANIA MOBILNĄ PRACĄ W TERENIE System musi spełniać następujące, minimalne warunki integracji: 69

70 1. Wymagania ogólne dotyczące integracji rejestrów i ewidencji systemu. 2. Integrację z systemem referencyjnym w zakresie określania lokalizacji robót budowlanych. 3. Integrację z ewidencją gruntów i budynków (EGiB) w zakresie kontroli lokalizacji robót budowlanych względem ewidencji gruntów i budynków. 4. Integrację z ewidencją dróg w zakresie: a) pozyskania informacji o elementach powierzchniowych pasa drogowego, a w szczególności o ich rodzaju, nawierzchni, lokalizacji itp., b) pozyskania informacji o geometrii drogi jak i poszczególnych zdarzeń w celu wykorzystania do celów projektowych i kosztorysowych, c) przekazywania informacji o robotach budowlanych w celu prowadzenia Książki Drogi. Integrację z ewidencją zajęć pasa drogowego w zakresie lokalizacji, zakresu i terminu zajęcia w celu synchronizacji. Integrację z modułem dokumentacji technicznej w zakresie, powiązania z procesu budowlanego z odpowiednią dokumentacją, zarchiwizowaną w tym module. Integrację z bazą interesantów, w zakresie określania podmiotów (wykonawcy, inspektorzy nadzoru itp.) System musi spełniać następujące, minimalne wymagania funkcjonalne: System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi zapewnić wspomaganie prac terenowych w zakresie: a) prowadzenie dziennika objazdów, gdzie na podstawie zarejestrowanego śladu GPS system dokona automatycznego wpisu do dziennika objazdów b) rejestrację awarii i usterek, gdzie bezpośrednio w terenie lokalizowane i opisywane będą usterki zauważone podczas objazdu, określany będzie ich priorytet i dalszy sposób postępowania; od zabezpieczenia aż do zlecenia naprawy, c) rejestrację utrudnień na drodze, gdzie bezpośrednio w terenie lokalizowane i opisywane będą utrudnienia na drodze zauważone podczas objazdu, zgodnie z wymaganiami systemu zarządzania utrudnieniami drogowymi, 70

71 d) rejestrację stanu nawierzchni drogowych, gdzie bezpośrednio w terenie opisywane będą stany nawierzchni drogowych, zgodnie z wymaganiami systemu zarządzania utrudnieniami drogowymi, e) dokumentowania realizacji prac związanych z utrzymaniem bieżącym przez pracowników w terenie, w tym informacji związanych z usunięciem awarii i usterek oraz wykonania innych zleconych prac f) dokumentowanie stanu prac w postaci zdjęć cyfrowych, opatrzonych w georeferencję, dzięki czemu możliwe będzie ich lokalizowanie na tle mapy oraz jej powiązanie z systemem referencyjnym; g) wykonywanie pomiarów i pozyskiwanie informacji w związku z aktualizacją ewidencji dróg i obiektów mostowych - gdzie możliwe będzie wykonanie (z wymaganą dokładnością) pomiarów oraz naniesienie zmian bezpośrednio w terenie lub też zebranie niezbędnych informacji i wprowadzenie ich już na stanowisku stacjonarnym (np. w przypadku braku zasięgu GPRS/3G lub braku dostępu do satelit systemu GPS/GLONASS); 2. System musi współpracować z następującymi modułami: a) modułem zarządzania objazdami w zakresie dokonywania wpisów do dziennika objazdów, b) modułem zarządzania utrzymaniem bieżącym, w zakresie rejestracji awarii i usterek oraz odnotowywania wykonania zleconych prac, c) modułem zarządzania utrudnieniami drogowymi, w zakresie rejestracji utrudnień na drodze, d) modułem zarządzania stanem nawierzchni drogowej, w zakresie rejestracji stanu nawierzchni danej drogi/odcinka. 3. System musi umożliwić użytkownikowi dwutorowość postępowania z danymi dotyczącymi aktualizacji ewidencji dróg i obiektów mostowych. Oznacza to, że będzie mógł (do wyboru): a) pozyskać dane w terenie i bezpośrednio w terenie wpisać zmiany do bazy danych, b) pozyskać dane w terenie ale już edycję wykonać na jednostce stacjonarnej. 71

72 4. Wybór sposobu edycji danych będzie determinowany rodzajem i szczegółowością pozyskiwanych informacji. Bezpośredni dostęp do bazy realizowany będzie za pośrednictwem mobilnego Internetu GPRS/3G, a określenie pozycji zapewnione będzie przy pomocy odbiornika GPS/GLONASS, który w zależności od wymaganej dokładności lokalizacji będzie mógł pracować w dwóch trybach: a) pomiar DGPS z wykorzystaniem serwisów KODGIS i NAWGIS, gdzie dokładność pomiaru wynosi od 0,5-2,0 m b) pomiar RTK z wykorzystaniem serwisu NAWGEO, gdzie odbiornik korzysta z poprawek w czasie rzeczywistym, a dokładność pomiaru nie przekracza wówczas 0,1 m 5. Urządzenia pomiarowe muszą być przystosowane do pracy z anteną wewnętrzną i zewnętrzną (zwłaszcza przy pomiarach precyzyjnych RTK) MODUŁ MONITORINGU SIECI DRÓG WOJEWÓDZKICH WOJEWÓDZTWA KUJAWSKO-POMORSKIEGO I ITS W ramach projektu stworzony zostanie system monitoringu wizyjnego dróg. Będzie się składał z autonomicznych stacji monitoringu wizyjnego, stacji zintegrowanych z urządzeniami informującymi o warunkach atmosferycznych, stacji zintegrowanych z drogowymi tablicami informacyjnymi oraz ze specjalistycznych stacji monitoringu wizyjnego w ramach których (w newralgicznych miejscach) umieszczone zostaną kamery obrotowe, posiadające możliwość monitorowania pasa drogowego w promieniu 500 m. System monitoringu wizyjnego powiązany będzie z płaszczem ochrony meteorologicznej, realizowanym urządzeniami informującymi o warunkach atmosferycznych. Przed przystąpieniem do realizacji systemu monitoringu dróg Wykonawca wraz z Zamawiającym winni dokonać analizy miejsc w których umieszczone będą stacje monitoringu. W analizie należy uwzględnić fakt iż montaż urządzeń monitoringu należy dokonać wraz ze stacjami meteorologicznymi. W ramach system ITS umieszczone będą także tablice zmiennej treści i znaki VMS wobec powyższego należy przeanalizować możliwość integracji tych urządzeń ze stacjami monitoringu. Wynikiem przeprowadzonej analizy winien być projekt wykonawczy stworzony przez 72

73 Wykonawcę i zaakceptowany przez Zamawiającego. Akceptacja projektu wykonawczego będzie podstawą do rozpoczęcia budowy systemu monitoringu i systemu ITS bezpośrednio w terenie. Miejsca lokalizacji kamer IP: DW 240 w km w miejscowości Bramka, strona prawa 1 kamera DW 214 w km w miejscowości Płochocinek, strona lewa 2 kamery DW 254 w km w miejscowości Brzoza - Olimpin, strona lewa 2 kamery DW 254 w km w miejscowości Barcin, strona lewa 2 kamery DW 254 w km w miejscowości Dąbrowa, strona lewa 2 kamery DW 252 w km w miejscowości Ujma Duża, strona lewa 1 kamera DW 559 w km w miejscowości Kamień Kotowy, strona prawa 2 kamery DW 270 w km w miejscowości Izbica Kujawska, strona prawa 2 kamery DW 240 w km w miejscowości Żalno, strona lewa 2 kamery DW 246 w km w miejscowości Wieszki, strona prawa 2 kamery DW 247 w km w miejscowości Turzyn, strona lewa 2 kamery DW 551 w km w miejscowości Dąbrowa Chełmińska, strona lewa 2 kamery DW 551 w km w miejscowości Pluskowęsy, strona prawa 1 kamera DW 554 w km w miejscowości Kowalewo Pomorskie, strona lewa 2 kamery DW 569 w km w miejscowości Łążynek, strona lewa 2 kamery DW 560 w km w miejscowości Osiek, strona prawa 1 kamera DW 560 w km w miejscowości Urszulewo, strona lewa 1 kamera DW 543 w km w miejscowości Jabłonowo Pomorskie, strona lewa 2 kamery DW 544 w km w miejscowości Łaszewo, strona lewa 2 kamery DW 251 w km w miejscowości Ustaszewo, strona lewa 2 kamery DW 266 w km w miejscowości Ustaszewo, strona prawa 2 kamery DW 548 w km w miejscowości Stolno, strona prawa 1 kamera DW 244 w km w miejscowości Maksymilianowo, strona prawa 2 kamery 73

74 Miejsca lokalizacji kamer ANPR: DW 252 w km w miejscowości Ujma Duża, strona lewa 1 kamera DW 551 w km w miejscowości Dąbrowa Chełmińska, strona lewa 2 kamery DW 560 w km w miejscowości Osiek, strona prawa 1 kamera DW 560 w km w miejscowości Urszulewo, strona lewa 1 kamera Miejsca lokalizacji kamer obrotowych: DW 252 w km w miejscowości Zakrzewo, 1 kamera DW 240 w km w miejscowości Tuchola, 1 kamera Miejsca lokalizacji stacji meteorologicznych: DW 214 w km w miejscowości Płochocinek, DW 254 w km w miejscowości Dąbrowa, DW 240 w km w miejscowości Żalno, DW 551 w km w miejscowości Dąbrowa Chełmińska, DW 554 w km w miejscowości Kowalewo Pomorskie, DW 560 w km w miejscowości Urszulewo, DW 543 w km w miejscowości Jabłonowo Pomorskie, DW 544 w km w miejscowości Łaszewo, DW 266 w km w miejscowości Ustaszewo, Miejsca lokalizacji tablic i znaków zmiennej treści: DW 266 w km w miejscowości Służewo, strona prawa DW 266 w km w miejscowości Służewo, strona lewa DK 15 w km w miejscowości Cierpice, strona prawa DK 15 w km w miejscowości Cierpice, strona lewa STACJE MONITORINGU WIZYJNEGO. Urządzenia winny być fabrycznie nowe, wolne od wad oraz uszkodzeń mechanicznych. Wykonawca winien w projekcie wykonawczym określić parametry techniczne poszczególnych 74

75 kamer monitoringu, jednakże parametry techniczne kamer stałych jak i obrotowych nie powinny być gorsze aniżeli: Kamery stałe: przetwornik obrazu: CMOS 1/2.8 ze skanowaniem progresywnym liczba aktywnych pikseli: 1920 (H) x 1080 (V) kompresja obrazu: H.264, MJPEG, MPEG4 minimalne natężenie światła: 0,5 lux monochromatycznym przy włączonym reflektorze IR obiektyw z funkcjami motozoom i autofocus 75 w trybie kolorowym; 0 lux w trybie dostępna z poziomu oprogramowania możliwość regulacji ogniskowej i ostrości automatyczne sterowanie przesłoną i czasem ekspozycji automatyczny tryb dzień/noc automatyczna regulacja balansu bieli analogowe wyjście wideo detekcja ruchu Kamery obrotowe: konfiguracja stref prywatności cyfrowe wejście alarmowe, cyfrowe wyjście alarmowe możliwość zasilania: PoE IEEE802.3af lub 24 VAC lub 12 VDC standard interfejsu sieciowego: 100BASE-TX obudowa wandaloodporna o klasie szczelności IP66 reflektor podczerwieni slot na kartę SD lub micro SD możliwość pracy w zakresie temperatur od -25 st. C. do +50 st. C. lub szerszym zgodność ze standardem ONVIF przetwornik obrazu: CMOS formatu co najmniej 1/2.8 ze skanowaniem progresywnym liczba aktywnych pikseli nie mniej niż 1920 (H) x 1080 (V) obsługiwana kompresja obrazu: H.264 oraz MJPEG możliwość redukcji rozdzielczości kamery

76 tryby pracy dziennej i nocnej (filtr ICR) minimalne natężenie światła: 0,4 lux lub mniej w trybie kolorowym (dla F1.6) i 0,04 lux lub mniej w trybie monochromatycznym (dla F1.6) obiektyw zintegrowany o ogniskowej w zakresie f=4,7-94mm lub szerszym, funkcje motozoom i autofocus automatyczne sterowanie przesłoną i czasem ekspozycji automatyczna regulacja balansu bieli detekcja ruchu standard interfejsu sieciowego: 100BASE-TX wejścia / wyjścia alarmowe możliwość tworzenia stref prywatności możliwość zdefiniowania minimum 100 presetów i 10 tras patrolowych zasilanie 24VAC lub 24VDC lub Hi PoE obsługa standardu ONVIF możliwość pracy w zakresie temperatur od -25 st. C. do +50 st. C. lub szerszym Wykonawca wraz z kamerami monitoringu winien dostarczyć oprogramowanie do monitorowania, które: zapewni przy optymalnych parametrach transmisji danych oraz pojemności przestrzeni archiwizacji ciągłe nagrywanie obrazu z kamer z rozdzielczością maksymalną wykorzystanych kamer zapewni przy optymalnych parametrach transmisji danych ciągły podgląd obrazu z kamer z rozdzielczością maksymalną wykorzystanych kamer Rozwiązanie musi charakteryzować się co najmniej następującymi cechami funkcjonalnymi: 1. System musi być w całości oparty o technologię IP oraz architekturę klient-serwer pozwalającą na budowę otwartego, łatwo rozbudowywalnego systemu na obiekcie z możliwością dostępu do materiału wideo z wielu dowolnych lokalizacji w nielimitowanej ilości stacji oglądowych, w tym z wykorzystaniem urządzeń mobilnych, 76

77 2. Możliwość obsługi kamer IP, w tym mega pikselowych, wielu producentów gwarantująca możliwość wykorzystania różnego typu sprzętu w przypadku późniejszej rozbudowy, 3. Otwarty standard wykorzystania serwerów oraz stacji oglądowych pozwalający na całkowite uniezależnienie się użytkownika od jednego dostawcy, 4. Możliwość autorskiej konfiguracji wyświetlania i parametrów rejestracji obrazów z kamer podłączonych do systemu, ułatwiająca późniejszą pracę operatorów w centrum monitoringu, 5. System musi być wyposażony w zaawansowane moduły inteligentnej analizy wideo dla każdej stałej kamerze IP, pozwalające na zapewnienie najwyższej skuteczności detekcji i analizy różnego typu zdarzeń na terenie obiektu. Są to co najmniej: - detekcja ruchu, - zmiana tła pola widzenia kamer, - utrata jakości widzenia, - zliczanie obiektów, - pozostawienie obiektu w wyznaczonej strefie, - przekroczenie wirtualnych linii wraz z określeniem kierunku, - ruch/zatrzymanie obiektu w wyznaczonej strefie, - wałęsanie się obiektu w wyznaczonej strefie, - wejście/wyjście obiektu z wyznaczonej strefy. 6. Możliwość automatycznej reakcji systemu na zaistniałe zdarzenia (alarmy) np. w wyniku działania modułów analizy wideo. System może wykonać m. in.: wysłanie SMS, wysłanie , alarm dźwiękowy, wysłanie sygnału do urządzenia powiązanego z kamerą (np. szlaban, drzwi, itp.), skierowanie kamery obrotowej w miejsce zaistnienia zdarzenia. 7. Łatwość wyszukiwania różnego typu zdarzeń w nagranym materiale. 8. System musi zapewnić nielimitowaną, bezpłatną możliwość połączeń klienckich, w tym bezpłatne połączenia z urządzeń mobilnych, 9. System musi zapewnić nielimitowaną (jedynie sprzętowo) ilość kamer IP na serwer oraz serwerów w systemie. 77

78 10. System musi zapewnić bezpłatną, co najmniej 3 letnią aktualizację o nowe wersje oprogramowania, 11. System musi zapewnić bezpłatny pakiet SDK do ewentualnych integracji z systemami trzecimi. Poniżej przedstawione są szczegółowe funkcjonalności, które co najmniej muszą być zapewnione przez system: 1. Dane wejściowe wideo: Rozwiązanie w pełni hybrydowe, obsługujące zarówno kamery analogowe jak i IP w tym multimegapikselowe, Możliwość przechwytu i obsługi sygnałów wideo z szerokiej palety kamer IP, enkoderów wideo, wideo serwerów i sprzętu DVR, Wsparcie dla kamer multimegapikselowych, Obsługa formatów MJPEG, MPEG4, H.264, Wsparcie dla technologii IR, Wsparcie dla technologii wielostrumieniowej dwa strumienie wideo, Niezależne ustawianie rozdzielczości oraz ilości klatek dla potrzeb oglądu, nagrywania i analizy wideo dla każdej kamery, Optymalizacja przesyłu wideo w celu minimalizacji użycia pasma, Elastyczna architektura w celu szybkiej integracji kamer, Funkcja auto wyszukiwania kamer IP w systemie, Automatyczne przywracanie połączenia z daną kamerą wideo na skutek przerwy w zasilaniu lub transmisji, Pełne wsparcie dla kamer stacjonarnych i PTZ. 2. Współpraca z systemami trzecimi: Możliwość współpracy i integracji z systemami trzecimi np. kontrola dostępu, systemy alarmowe, systemy p.poż. Elastyczna i rozszerzalna architektura dla szybkiej integracji nowych urządzeń i technologii bezpieczeństwa 3. Nagrywanie: 78

79 Konfigurowalna z poziomu użytkownika rozdzielczość i ilość klatek dla każdego kanału wideo Możliwość wyboru trybu nagrywania: ciągłe, w oparciu o harmonogram, na alarm. Nagrywanie w trybie pre i post alarm Możliwość zmiany ilości klatek na skutek wystąpienia alarmu Możliwość aktywacji natychmiastowego nagrywania przez operatora Możliwość wyświetlania dostępnego do zapisu miejsca na dysku oraz czasu nagrywania Wskaźnik historii nagrywania Możliwość zaimplementowania znaku wodnego dla materiału wideo Wsparcie dla synchronizacji czasowej na podstawie serwera czasu Możliwość wskazania różnych miejsc zapisu z kamer Wsparcie dla technologii RAID, DAS i NAS Możliwość redundancji nagrywania Nagrywanie w trybie redundancji z pełną synchronizacją danych 4. Alarmy Wbudowane, serwerowe wsparcie dla detekcji wideo Alarmy w oparciu o analizę wideo Alarm w parciu o sabotaż i zmianę scenerii kamery Informowanie o: awarii sieci, awarii kamery, niskiego poziomu miejsca na dysku, informacje z kamery i wideo serwerów, stanach zintegrowanych urządzeń i rozwiązań Wsparcie dla zewnętrznych wejść wideo 5. Zarządzanie alarmami Dedykowane okno dla sygnałów alarmowych Możliwość kreowania niezależnych reguł postępowania i reakcji urządzeń na dany alarm Gama reakcji na zdarzenia alarmowe musi zawierać co najmniej następujące scenariusze reakcji: wizualizacja na mapie, alarm audio, rozpoczęcie nagrywania przez predefiniowaną grupę urządzeń, jednoczesne presety kilku kamer PTZ, 79

80 aktywacja wyjścia alarmowego w urządzeniu, okna pop-up do zatwierdzania, predefiniowane okna pop-up z obrazem w trybie live, powiadamianie , Manualne lub automatyczne zatwierdzanie alarmów Zaawansowane okno zatwierdzania alarmów z wyświetlaniem kolejki alarmów wraz z przyporządkowanym każdemu zdarzeniu materiałem wideo 6. Tryb Na żywo i Ogląd Drzewo podglądu kamer Aktywacja oglądu w oparciu o przenieś i upuść Tryb patrolowania i sekwencyjny Możliwość tworzenia widoków w połączeniu z trybem patrolowania Interaktywny, cyfrowy PTZ Funkcja: Szkło powiększające najeżdżanie myszą na dowolne pole widzenia kamery i otrzymywanie powiększonego obrazu z tego miejsca skala powiększenia (rozmiar powiększanego fragmentu) musi być definiowana w systemie Wskazanie wykorzystania pasma Niezależne ustawianie wyglądu każdego z ekranów Funkcja natychmiastowego Replay Pasek szybkiego dostępu dla każdego okna wideo Funkcja ukrywania interfejsu użytkownika ogląd tylko wideo Funkcja snapshot w trybie na żywo 7. Zarządzanie kamerami Wsparcie dla kontroli kamer PT i PTZ Wsparcie dla funkcji preset i tras patrolowych Wsparcie dla kontrolerów USB Wsparcie dla klawiatur CCTV 8. Mapy i Wizualizacja Zdarzeń Dedykowany ekran dla wizualizacji mapy Wsparcie dla map w formacie JPEG i BMP Wizualizacja kamer i urządzeń na mapie Wsparcie dla wizualizacji zdarzeń alarmowych na mapie 80

81 Wyświetlanie obrazu z kamery lub wielu kamer na mapie realizowane obok ikonek kamer Wsparcie dla cyfrowego PTZ dla mapy Wsparcie dla interaktywnego, cyfrowego PTZ 9. Analiza wideo Wsparcie dla analizy na kamerach wyposażonych w IR Analiza wideo zaszyta, realizowana z poziomu oprogramowania serwerowego Interfejs konfiguracji analizy wideo zaszyty w oprogramowaniu klienckim Wbudowana dostępność wraz z możliwością natychmiastowego wykorzystania szerokiej palety algorytmów wideo, co najmniej: detekcja intruzów, kontrola kierunku ruchu, przekraczanie wirtualnych murów, detekcja sabotażu kamery i zmiany pola widzenia, detekcja tłumu, detekcja pozostawionego przedmiotu, detekcja długości kolejki, detekcja wałęsania się, detekcja tailgetting, detekcja zatrzymującego się obiektu, zliczania obiektów, śledzenie ścieżki poruszania się obiektów, kalkulacja szybkości poruszania się obiektu, Otwartość systemu pozwalająca na wykorzystanie modułów analizy producentów trzecich poprzez pakiet deweloperski SDK 10. Odtwarzanie i eksport materiału wideo Synchroniczne odtwarzanie obrazu z każdej ilości podłączonych kamer Nawigacja wideo odtwarzanie w przód i do tyłu z prędkością do 16x Wolne odtwarzanie i cofanie nagranego materiału z prędkością do 0,25x Eksport materiału w oparciu o jego specyficzną długość lub alarm, Możliwość dodania tekstu na eksportowanym materiale wideo, Możliwość eksportu materiału wideo na dowolnym komputerze i dowolnym odtwarzaczu wideo, Możliwość eksportu w formacie natywnym wraz z aplikacją do odtwarzania, 11. Raporty i informacje o aktywności Możliwość wyświetlania logów sesji użytkowników oraz alarmów w danej sesji, Szczegółowe informacje o aktywności użytkowników, Wyszukiwanie logów w celu generowania raportów, 81

82 Raporty muszą zawierać informacje o wykonywanych przez operatora czynnościach oraz źródło adresu IP Wyszukiwanie alarmów oparte o typ alarmu, kanał oraz czas trwania wraz z możliwością generowania raportów na tej podstawie, Szybki dostęp do odtwarzania z wielu kamer oraz eksport wideo skorelowany z rezultatami wyszukiwania, Możliwość zapisu logów i raportów w formacie TXT, CSV, i PDF Możliwość wydruku logów i raportów, Możliwość codziennego generowania raportów wraz z ich wysyłaniem np. poprzez 12. Użytkownicy Skalowalne poziomy uprawnień użytkowników, Wbudowane standardowe uprawnienia, Możliwość kreowania dedykowanych uprawnień, Możliwość generowania nieograniczonej liczby użytkowników, Możliwość dodawania i usuwania użytkowników Dane o użytkowniku jak nazwa, dane kontaktowe itp. 13. Interfejs użytkownika Wsparcie dla pracy wielomonitorowej i ścian wideo Możliwość wyświetlania pełnoekranowego dla każdej kamery Możliwość dowolnego kreowania wielkości i rozmiarów okien z widokami z kamer Urządzenia winny być zlokalizowane w miejscach określonych w projekcie wykonawczym. Powyższe winno być potwierdzone protokołem montażu poszczególnych urządzeń sporządzonym w miejscu zamontowania urządzenia. Protokół winien być podpisany przez Wykonawcę, Zamawiającego oraz w przypadku, kiedy urządzenie montowane będzie w pasie drogowym innych dróg a niżeli drogi wojewódzkie protokół montażu winien być podpisany także przez przedstawiciela zarządcy drogi. 82

83 INTELIGENTNY SYSTEM TRANSPORTOWY (ITS) Projekt zakłada budowę systemu ITS, składającego się z sieci specjalistycznych urządzeń takich jak: stacje monitorowania natężenia ruchu klasy ANPR, stacje ostrzegania monitorujące warunki atmosferyczne (w ograniczonym zakresie), stacje monitoringu wizyjnego, a także tablice informacji drogowej i znaki zmiennej treści VMS. Wymienione urządzenia będą połączone ze sobą na oddzielnym serwerze. Pełnić będą również funkcje dystrybutora danych dla portalu internetowego, który należy stworzyć w ramach systemu. W ramach systemu ITS zakłada się, iż zbudowany zostanie system wielomodułowy otwarty tzn. umożliwiający podłączanie do systemu kolejnych modułów oraz rozbudowę systemu bez konieczności dokonywania zmian w strukturze stworzonego systemu. Poprzez moduł należy rozumieć kolejną grupę urządzeń ITS lub/oraz nową funkcjonalność systemu informatycznego. System w głównej mierze oparty będzie na podsystemie ANPR odpowiedzialnym za dostarczanie informacji dotyczących natężenia ruchu panującego na drogach w sposób charakterystyczny i określony zasadami działania urządzeń ANPR, działający w oparciu o identyfikację tablic rejestracyjnych. Takie rozwiązanie pozwoli na dostarczenie danych organom odpowiedzialnym za bezpieczeństwo wewnętrzne i zewnętrzne kraju. W wytypowanych przez Zamawiającego miejscach zlokalizowane zostaną stacje meteorologiczne o parametrach dedykowanych dla określonej lokalizacji. Pozwoli to na racjonalizację kosztów projektu. Stacje meteorologiczne realizowały będą pomiar takich parametrów jak: temperatura powietrza, siła i kierunek wiatru, temperatura nawierzchni, występowanie opadu, jego intensywność oraz przejrzystość powietrza. Stacje, na podstawie realizowanych pomiarów, generowały będą alarmy np. o możliwości występowania oblodzenia jezdni, intensywnych opadach atmosferycznych czy też o niebezpiecznie małej widoczności powietrza. W ramach projektu na sieci dróg zlokalizowane będą tablice zmiennej treści oraz znaki VMS. Zakłada się model informacji tekstowej realizowany przez tablice zmiennej treści. Znaki zmiennej treści VMS zlokalizowane będą w miejscach, gdzie zasadnym będzie informowanie kierujących o sytuacji na drodze. System działał będzie w trybie manualnym. 83

84 WYMAGANIA FUNKCJONALNE DOTYCZĄCE SYSTEMU INFORMATYCZNEGO ZARZĄDZANIA SYSTEMEM ITS System informatyczny zarządzający systemem ITS winien posiadać otwartą modułową budowę. Niniejszy opis dotyczy architektury, wymaganych minimalnych funkcjonalności oraz oprogramowania systemu. Wykonawca jest zobowiązany do stosowania materiałów, urządzeń i rozwiązań nie gorszych niż określone w OPZ. Zamawiający wymaga, aby zamówienie było wykonane z należytą starannością, w oparciu o sprawdzone, nowoczesne technologie, z wykorzystaniem współczesnej wiedzy z zakresu związanego z przedmiotem zamówienia, z poszanowaniem wszelkich obowiązujących przepisów prawa i zapewniało: realizację wszystkich wymaganych w niniejszym OPZ funkcji systemu ITS, spełnienie wymaganych kryteriów funkcjonalnych, kryteriów integracji i efektów wdrożenia systemu oczekiwanych przez Zamawiającego. Intuicyjność i łatwość w zarządzaniu systemem, w tym możliwość realizacji dowolnych zadań dostępnych w systemie, wysoką niezawodność pracy systemu, w tym także wysoką jakość dostarczanych do systemu danych dotyczących ruchu i pracy systemu, przyjazne warunki eksploatacji i konserwacji systemu, możliwość rozbudowy systemu zarówno pod względem zwiększania obszaru i liczby urządzeń wchodzących w skład systemu, nowych odcinków dróg, nowych obiektów i obszarów działania systemu i innych elementów ITS jaki dodawania nowych funkcji systemu bez konieczności angażowania do tych prac Wykonawcy lub firm z nim powiązanych. Zamawiający oczekuje zapewnienia jak największej otwartości Systemu i łatwości przyszłej integracji z innymi systemami, poprzez umożliwienie wymiany danych, zapewnienie otwartości poziomu aplikacji serwerowych na zasilanie dodatkowymi informacjami, pochodzącymi z innych systemów wdrażanych przez Województwo Kujawsko - Pomorskie oraz zapewnienia udostępniania dla innych systemów wszelkich danych gromadzonych w bazach danych oraz poprzez możliwość konfigurowania lub uzupełniania oprogramowania w celu dodawania nowych funkcji i podłączania nowych systemów z zakresu Inteligentnych Systemów Transportu z 84

85 możliwością wykorzystania infrastruktury i oprogramowania dostarczonego i zainstalowanego przez Wykonawcę. Tworzony w ramach projektu system powinien być otwarty na możliwość potencjalnej wymiany komponentów systemu na komponenty nowszej generacji, o lepszych parametrach technicznych i innych producentów. Zamawiający planuje rozbudowę systemu poprzez zwiększanie ilości urządzeń wchodzących w skład systemu oraz rozbudowę modułów systemu. Wykonawca winien stworzyć system niezawodny, działający w sposób ciągły poprzez utrzymanie komunikacji pomiędzy urządzeniami umieszczonymi w terenie a serwerami systemu. Wykonawca zobowiązany jest dokonać kompletnej analizy pod kątem komunikacji urządzeń uwzględniając technologię komunikacji GSM. Na miesiąc przed oddaniem modułu (zgodnie z harmonogramem realizacji pkt. 5.3 ppkt. 10) Zamawiający przekaże należące do niego karty SIM, Wykonawcy, które ten w ramach projektu zamontuje w urządzeniach (dotyczy to kamer IP, ANPR, obrotowych, tablic i znaków zmiennej treści i stacji meteo). Opłaty za przesył danych Zamawiający opłaci w oparciu o własną umowę z operatorem, który zostanie wybrany w odrębnym postępowaniu przetargowym. Wykonawca nie będzie ponosił odpowiedzialności za brak danych w systemie wynikający z nieprawidłowości działania sieci GSM. Wykonawca musi uwzględnić fakt, iż tworzony system będzie rozbudowywany przez Zamawiającego poprzez; Zwiększanie ilości urządzeń ANPR w okresie realizacji projektu, administrowania systemem oraz w okresie późniejszym Zwiększania ilości tablic zmiennej treści i znaków VMS w okresie administrowania systemem oraz w okresie późniejszym Dodawanie nowych urządzeń innego rodzaju a niżeli umieszczane przez Wykonawcę w ramach projektu takich jak; wagi preselekcyjne, urządzenia radarowe Integrację systemu np. z parkingami typu park & ride, stacjami ważenia pojazdów itp. Rozbudowę systemu o kolejne urządzenia radarowe służące do pomiaru natężenia ruchu SZCZEGÓŁOWE WYMAGANIA DOTYCZĄCE SYSTEM INFORMATYCZNEGO ITS W ramach systemu należy stosować otwarte udokumentowane protokoły komunikacyjne. 85

86 Poprzez otwartą modułową budowę należy rozumieć, iż Wykonawca winien stworzyć system w sposób umożliwiający jego rozbudowę bez konieczności rozbudowy systemu w przyszłości po zakończeniu okresu administrowania - przez Wykonawcę. Wszystkie pliki źródłowe należy dostarczyć i dostarczać w okresie administrowania systemem w postaci skompilowanej oraz przed kompilacją. Wykonawca winien dostarczyć i dostarczać także pełną dokumentację opisową, w której zawarty będzie opis kodu języka programowania, w którym Wykonawca opracował system. Wykonawca zobowiązany jest do tworzenia opisu w języku polskim. Wykonawcę obowiązuje tajemnica, co do zawartości opisu oraz Wykonawca nie może w żaden sposób upowszechniać ani systemu jego postaci przed i po kompilacji jak i opisu systemu. System informatyczny winien zarządzać całym system ITS tworzonym przez urządzenia w nim obecne oraz przez urządzenia, które w przyszłości będą do systemu dołączane. Wykonawca winien opracować system w taki sposób, aby Zamawiający mógł w przyszłości podłączyć do systemu nieograniczoną ilość urządzeń tego samego typu i rodzaju jak w zakresie projektu. Wykonawca winien także opracować system w taki sposób, aby Zamawiający w przyszłości mógł do systemu podłączyć urządzenia innego typu i rodzaju a niżeli te, które są w zakresie projektu wobec powyższego system winien być tak utworzony, aby nie ograniczał swojej funkcjonalności w zakresie urządzeń tylko takiego typu jak w systemie w chwili tworzenia. System winien funkcjonować na dedykowanym dla systemu serwerze dostarczonym przez Wykonawcę. Urządzenia umieszczone w terenie, funkcjonujące w ramach systemu winny komunikować się z systemem informatycznym poprzez prywatny punkt dostępu typu APN (w przypadku urządzeń skomunikowanych z systemem za pomocą sieci GSM) lub w przypadku połączenia bezpośredniego pomiędzy urządzeniami a serwerem za pomocą bezpiecznego połączenia typu VPN lub w inny sposób opracowany przez Wykonawcę i zaakceptowany przez Zamawiającego. Serwerowa część systemu winna posiadać następujące właściwości: - Dane pochodzące z urządzeń winny być gromadzone w sposób usystematyzowany w dedykowanych folderach danych przeznaczonych dla danych określonego; typu, rodzaju, pochodzenia, miejsca i czasu. 86

87 - Dostęp do folderów, w których gromadzone są dane winien być możliwy także w sposób bezpośredni za pomocą narzędzi systemu operacyjnego serwerów. - Foldery, w których gromadzone są dane winny być zabezpieczone przed usunięciem danych, dostęp do folderów winien być ograniczony przeglądanie zawartości folderów winno być możliwe tylko i wyłącznie po wprowadzeniu hasła dostępu. - Zabezpieczenie folderów przed usuwaniem danych w nich dostępnych należy opracować i wykonać po uzyskaniu akceptacji opracowanego sposobu przez Zamawiającego. Opracowany sposób winien zapewnić bezpieczeństwo danych gromadzonych w folderach także przy założeniu, że użytkownik posiadający możliwość eksploracji folderów będzie mógł w przypadkowy sposób usunąć dane. System informatyczny zarządzający systemem w części serwerowej winien posiadać własne narzędzia kontrolujące takie jak: - kontrola poprawności gromadzenia danych - kontrola działania poszczególnych urządzeń działających w systemie - kontrola działania systemu SZCZEGÓŁOWE UWARUNKOWANIA TECHNICZNE DLA URZĄDZEŃ UMIESZCZANYCH W PASIE DROGOWYM W RAMACH PROJEKTU. Tablice i znaki zmiennej treści wymagania ogólne. Wykonawca winien zastosować w systemie tablice i znaki zmiennej treści fabrycznie nowe wolne od wad fabrycznych oraz uszkodzeń mechanicznych, posiadające badania typu oraz spełniające wymagania obowiązującej normy PN-EN :2005+A1:2009 w zdefiniowanych niżej zakresie i parametrach niniejszego dokumentu. Ze względu na istotną funkcję jaką urządzenia pełnią w przedmiotowym systemie wymagane jest, aby trwałość opisanych niżej typów urządzeń zarówno pod względem zachowania parametrów fotometrycznych jak i odporności na agresywne środowisko korozyjne wynosiła co najmniej 10 lat. Dostawca tablic i znaków o zmiennej treści ma obowiązek zapewnić takie rozwiązanie techniczne, aby wartości zdefiniowanych niżej parametrów fotometrycznych dla poszczególnych 87

88 klas charakterystyki optycznej urządzeń pozostawały w okresie minimum 10 lat na odpowiadającym im poziomie, zgodnie z przedmiotowa normą wyrobu. Wykonawca dołączy do oferty kompletny certyfikat CE świadczący o dopuszczeniu typu wyrobu do obrotu zgodnie z procedurą opisaną w rozdz. 9 PN-EN :2005+A1:2009. Ponadto, w certyfikacie CE przedstawionym przez Wykonawcę jednostka badawcza powinna w jednoznaczny sposób podać informację, której dotyczą procedury wykonywania badań w kolejności, jaka została podana w przedmiotowej normie (punkt ). wszystkich wymaganych normą parametrów w tym m.in. parametrów środowiskowych, mechanicznych i optycznych. Biorąc jednak pod uwagę możliwie jak największe zminimalizowanie efektu starzenia diod LED użytych w opisanych niżej tablicach i znakach o zmiennej treści oraz prawidłowe działanie urządzeń w możliwie jak najdłuższym okresie czasu, czyli znacznie powyżej 10lat eksploatacji Zamawiający wymaga ograniczenia prądu zasilania każdej z diod LED do poziomu poniżej 25% prądu nominalnego dla każdej z wyświetlanych barw drogowych: białej, żółtej, czerwonej, niebieskiej i zielonej. O spełnieniu tego wymagania powinno świadczyć wstępne badanie typu modułu testowego, odpowiadającego parametrami charakterystyce optycznej urządzenia, zdefiniowanej przez Zamawiającego, i z którego będzie wynikać, przy jakim prądzie zasilania zostały osiągnięte wartości poszczególnych klas charakterystyki optycznej. Informacja ta powinna być zawarta w deklaracji zgodności oraz w certyfikacie CE, którą przedstawi Wykonawca np.: na etapie składania ofert. Tablice i znaki winny charakteryzować się następującymi parametrami technicznymi; Zasilanie 230V Obudowa wykonana z tworzyw typu; aluminium, poliwęglan, dibond, Kąt rozsyłu światła klasa B6 zgodnie z normą PN-EN :2005+A1:2009 Barwa C2 zgodnie z normą PN-EN :2005+A1:2009 Współczynnik luminacji R3 zgodny z normą PN-EN :2005+A1:2009 Luminancja L3 zgodnie z normą PN-EN :2005+A1:2009 Sterowanie za pomocą RS-232, RS-485, Ethernet, GPRS oraz światłowód Temperatura pracy T1 do T3 zgodnie z normą PN-EN :2005+A1:2009 Stopień ochrony obudowy IP54 88

89 Stopień ochrony płyty czołowej IP65 1. Znaki o zmiennej treści wymagania szczegółowe Wykonawca dostarczy, zainstaluje i uruchomi z poziomu operatora systemu jeden rodzaj znaków o zmiennej treści, w ilości 4 sztuki, do wyświetlania na matrycy dowolnych piktogramów znaków drogowych w zakresie wynikającym z jej wymiarów, podanych poniżej. Matryca znaku o zmiennej treści wymagania szczegółowe - Znaki winny posiadać matrycę ortogonalną, wykonaną w technologii LED RGB matryca typu FULL-LED pełna matryca RGB całkowicie programowalna z poziomu systemu informatycznego. - Wymiary matrycy typu B: 1000x1000 mm, 40 x 40 pikseli, pp=25mm - Matryca winna posiadać funkcję automatycznego dostosowania jasności świecenia matrycy w zależności od oświetlenia zewnętrznego. - Matryca winna umożliwiać wyświetlenie treści w trybie pulsacyjnym i z zachowaniem warunków synchronizacji czasowej wszystkich elementów, a także dynamiczną prezentacją treści polegającą na sekwencyjnym wyświetlaniu znaków i komunikatów, - Matryca winna posiadać zintegrowany w obudowie znaku moduł zarządzania matrycą. Zarządzanie znakiem winno być zbieżne z opisaną w OPZ funkcjonalnością systemu informatycznego w zakresie programowania znaku o zmiennej treści. Moduł winien umożliwić pełną programowalność matrycy z poziomu systemu informatycznego. Komunikacja pomiędzy matrycą a systemem informatycznym za pomocą GSM lub/i poprzez bezpośrednie połączenie stacji roboczej mobilne z znakiem. 2. Tablice o zmiennej treści wymagania szczegółowe Wykonawca dostarczy, zainstaluje i uruchomi z poziomu operatora systemu jeden rodzaj tablic o zmiennej treści, w ilości 4 sztuki, do wyświetlania na matrycy dowolnie programowalnych znaków alfanumerycznych (komunikatów tekstowych) barwy białej, w zakresie wynikającym z jej wymiarów, podanych poniżej. 89

90 Matryca tablicy o zmiennej treści wymagania szczegółowe - Tablice winny posiadać po dwa pola (linie tekstowe) wykonane w technologii LED W matryca monochromatyczna, całkowicie programowalna z poziomu systemu informatycznego, - Wymiary pojedynczej linii tekstowej typu B: 3200x 240 mm, 160 x 12 pikseli, pp=20mm - Matryca winna posiadać funkcję automatycznego dostosowania jasności świecenia matrycy w zależności od oświetlenia zewnętrznego. - Matryca winna umożliwiać wyświetlenie treści w trybie pulsacyjnym i z zachowaniem warunków synchronizacji czasowej wszystkich elementów, a także dynamiczną prezentacją treści polegającą na sekwencyjnym wyświetlaniu znaków i komunikatów, - Matryca winna posiadać zintegrowany w obudowie tablicy moduł zarządzania matrycą. Zarządzanie tablicą winno być zbieżne z opisaną w OPZ funkcjonalnością systemu informatycznego w zakresie programowania znaku o zmiennej treści. Moduł winien umożliwić pełną programowalność matrycy z poziomu systemu informatycznego. Komunikacja pomiędzy matrycą a systemem informatycznym za pomocą GSM lub/i poprzez bezpośrednie połączenie stacji roboczej mobilne z znakiem. Sposób umieszczenia tablic i znaków o zmiennej treści na drodze Zamawiający oczekuje, że Wykonawca instalując znaki i tablice na konstrukcjach wsporczych wykona zgodnie z obowiązującymi przepisami w odniesieniu do skrajni poziomej i pionowej w każdej z wymaganych lokalizacji. Ponadto, Wykonawca przed przystąpieniem do prac w terenie, przedstawi Zamawiającemu koncepcję w której określi typ i rodzaj konstrukcji wsporczych, a następnie wykona projekty budowlano-wykonawcze i pozyska stosowne zezwolenia. Zamawiający nie definiuje w jaki sposób tablice i znaki zmiennej treści maja być zamontowane w stosunku do drogi. Natomiast wymaga, by wyświetlane komunikaty na powierzchni obrazowej były czytelne i widzialne dla kierujących pojazdami z odległości co najmniej 200m w warunkach silnego oddziaływania oświetlenia słonecznego a jednocześnie nie powodowały w warunkach nocnych oślepiania kierujących. Zmiany natężenia oświetlenia strumienia świetlnego generowanego przez urządzenia mają odbywać się w sposób 90

91 automatyczny i dostosowany do zmian luminancji zewnętrznej. W polu widzenia kierujących pojazdami nie mogą znajdować się żadne przeszkody, które mogłyby ograniczać ich percepcję w odniesieniu do wyświetlanego komunikatu. Konstrukcje wsporcze mają być wyposażone w podesty do obsługi serwisowej, a dostęp do urządzeń powinien ograniczać ingerencję niepożądanych osób. Urządzenia ANPR. Wykonawca winien zastosować w systemie najnowocześniejsze urządzenia ANPR wyposażone w podzespoły najnowszej generacji zapewniające efektywną pracę urządzenia, szybkość przetwarzana danych oraz zapewniające odpowiednią przestrzeń pamięci na przechowywanie danych wewnątrz urządzenia. Urządzania winny być przystosowane do montażu na istniejących konstrukcjach wsporczych oraz posiadać parametry wagi i rozmiaru umożliwiające ich montaż na istniejących konstrukcjach np. wysięgniki sygnalizacji świetlnej, słupy oświetlenia ulicznego itp. System ANPR winien posiadać minimum następujące parametry techniczne: Moduł pozwala na wykrycie i automatyczny odczyt tablic rejestracyjnych pojazdów w czasie rzeczywistym. Funkcja wyszukiwania odczytanych numerów rejestracyjnych (License Plate Search); Funkcja ręcznego i półautomatycznego tworzenia listy numerów specjalnego znaczenia (Watch List) ręczne dodawanie numerów do listy lub import listy z zewnętrznego pliku; Funkcja dopasowania numerów (License Plate Match) automatyczne dopasowanie odczytywanych numerów do numerów z listy i ewentualne wykonanie akcji zdefiniowanej w module reguł; Eksport listy do zewnętrznego pliku. Jednostka centralna; procesor nie gorszy niż 1.6Ghz, pamięć RAM nie mniej niż 1GB, system operacyjny Microsoft Windows 7 Pro lub nowszy, pamięć na przechowywanie danych nie mniej niż 4GB, 91

92 Moduł rozpoznawania tablic rejestracyjnych Moduł pozwala na wykrycie i automatyczny odczyt tablic rejestracyjnych pojazdów w czasie rzeczywistym. Funkcja wyszukiwania odczytanych numerów rejestracyjnych (License Plate Search); Funkcja ręcznego i półautomatycznego tworzenia listy numerów specjalnego znaczenia (Watch List) ręczne dodawanie numerów do listy lub import listy z zewnętrznego pliku; Funkcja dopasowania numerów (License Plate Match) automatyczne dopasowanie odczytywanych numerów do numerów z listy i ewentualne wykonanie akcji zdefiniowanej w module reguł; Eksport listy do zewnętrznego pliku. Urządzenia ANPR winny być skonfigurowane z dostarczonymi kamerami IP, dzięki czemu w systemie widoczny będzie nie tylko obraz tablicy rejestracyjnej, ale także obraz całego pojazdu. Urządzenia monitoringu wizyjnego. Urządzenia winny być fabrycznie nowe, wolne od wad oraz uszkodzeń mechanicznych. Wykonawca winien w projekcie wykonawczym określić parametry techniczne poszczególnych kamer monitoringu, jednakże parametry techniczne kamer nie powinny być gorsze a niżeli; przetwornik obrazu: CMOS 1/2.8 ze skanowaniem progresywnym liczba aktywnych pikseli: 1920 (H) x 1080 (V) kompresja obrazu: H.264, MJPEG, MPEG4 minimalne natężenie światła: 0,5 lux w trybie kolorowym; 0 lux w trybie monochromatycznym przy włączonym reflektorze IR obiektyw z funkcjami motozoom i autofocus dostępna z poziomu oprogramowania możliwość regulacji ogniskowej i ostrości automatyczne sterowanie przesłoną i czasem ekspozycji automatyczny tryb dzień/noc 92

93 automatyczna regulacja balansu bieli analogowe wyjście wideo detekcja ruchu konfiguracja stref prywatności cyfrowe wejście alarmowe, cyfrowe wyjście alarmowe możliwość zasilania: PoE IEEE802.3af lub 24 VAC lub 12 VDC standard interfejsu sieciowego: 100BASE-TX obudowa wandaloodporna o klasie szczelności IP66 reflektor podczerwieni slot na kartę SD lub micro SD możliwość pracy w zakresie temperatur od -40 st. C. do +50 st. C. lub szerszym zgodność ze standardem ONVIF Urządzenia monitoringu warunków atmosferycznych Urządzenia winny być fabrycznie nowe, wolne od wad oraz uszkodzeń mechanicznych tworzyć stację monitoringu warunków atmosferycznych. Stacje pomiarów meteorologicznych winny być zaprojektowane i wykonane z urządzeń, charakteryzujących się następującymi właściwościami: Pomiar prędkości i kierunku wiatru na wysokości 6 m Pomiar temperatury i wilgotności powietrza na wysokości 3 m Pomiar temperatury nawierzchni, punkt zamarzania Monitoring stanu nawierzchni - sucha, wilgotna, mokra, śnieg, zamarzająca wilgoć, lód, zasolenie Monitoring opadu - występowanie, intensywność Detektor widoczności Stacja winna realizować bezpośrednio w terenie wykrycie, wstępne przetwarzanie i generowanie ostrzeżenia/alarmu w przypadku mrozu, opadów, silnych podmuchów wiatru. Generowane ostrzeżenia i alarmy: Ostrzeżenie przed oblodzeniem (mokra nawierzchnia spowoduje oblodzenie za 1-2 godziny); 93

94 Ostrzeżenie o zmrożeniu (temperatura nawierzchni jest poniżej temperatury zamarzania i temperatura punktu rosy przekracza temperaturę nawierzchni); Ostrzeżenie przy występujących opadach przy temperaturze nawierzchni około 0º C; Alarm o gołoledzi na drogach (oblodzenie) Ostrzeżenie dla widoczności < 60m; Stacje winny być zlokalizowane w miejscach określonych w projekcie wykonawczym. Powyższe winno być potwierdzone protokołem montażu poszczególnych urządzeń sporządzonym w miejscu zamontowania urządzenia. Protokół winien być podpisany przez Wykonawcę, Zamawiającego oraz w przypadku, kiedy urządzenie montowane będzie w pasie drogowym innych dróg a niżeli drogi wojewódzkie protokół montażu winien być podpisany także przez przedstawiciela zarządcy drogi. Z uwagi na fakt, iż stacje meteorologiczne są urządzeniami, które wymagały będą wykonania przyłącza energetycznego Wykonawca winien we własnym zakresie przeprowadzić wszelkie procesy związane z umieszczeniem urządzeń w terenie wraz z uzyskaniem uzgodnienia przyłącza energetycznego dla każdej ze stacji MODUŁ ZARZĄDZANIA GPS I UTRUDNIENIAMI DROGOWYMI SYSTEM ZARZĄDZANIA GPS W ZIMOWYM UTRZYMANIU DRÓG Zarząd Dróg Wojewódzkich w Bydgoszczy posiada wdrożony system utrzymania dróg wykorzystywany do wspomagania działań związanych z Zimowym Utrzymaniem Dróg za pomocą technologii GPS. W ramach systemu wdrożono strukturę informatyczną oraz sprzętową skomunikowaną ze sobą poprzez wykorzystanie sieci GSM w oparciu o prywatny punkt dostępu do usług APN. Wykonawca dokona demontażu obecnie używanych przez Zamawiającego sterowników GPS. Na miesiąc przed oddaniem modułu (zgodnie z harmonogramem realizacji pkt. 5.3 ppkt. 9) Zamawiający przekaże Wykonawcy karty SIM, które ten w ramach projektu zamontuje w 94

95 urządzeniach GPS. Zamawiający wybierze operatora odpowiedzialnego za przesył danych, odrębnym postępowaniem przetargowym. Realizacja projektu ma na celu rozwój wdrożonego systemu GPS w zimowym utrzymaniu dróg poprzez: a) rozbudowę modułów systemowych odpowiedzialnych za raportowanie aplikacji typu klient, informującej o warunkach panujących na drogach, b) rozszerzenie funkcjonalności, poprzez wdrożenie stosowania czujników optycznych wykrywających pracę urządzeń mechanicznych [odśnieżanie/posypywanie], c) stworzenie dodatkowej architektury systemu w oparciu o szynę transmisji danych CANBUS stosowaną do komunikacji z komputerami pokładowymi sterującymi pracą urządzeń takich jak pług oraz posypywarka, d) wdrożenie nowych sterowników GPS, e) wdrożenie cyfrowych rejestratorów obrazu, f) Instalacja najnowszej wersji oprogramowania wykorzystywanego obecnie przez Zamawiającego przy systemie GPS w Zimowym Utrzymaniu Dróg Stan istniejący. W chwili obecnej Zamawiający posiada system wspomagania utrzymania dróg wojewódzkich o funkcjonalności jak poniżej; System o architekturze klient serwer Aplikacje typu desktop skomunikowane z serwerem za pomocą łącza internetowego Pojazdy skomunikowane z serwerem systemu za pomocą GPRS-a z uwzględnieniem bazowej stacji GSM stanowiącej integralną część serwera Serwer systemu jest jednocześnie serwerem telekomunikacyjnym W chwili obecnej system monitoruje pozycje pojazdów wykonujących czynności związane z utrzymaniem zimowym dróg. System posiada dwie główne składowe: Aplikacja monitorująca 95

96 Aplikacja analityczna Dostawa wraz z montażem specjalistycznych czujników Wykonawca winien dostarczyć i zamontować na pojazdach wskazanych przez Zamawiającego komplet fabrycznie nowych czujników położenia pługa oraz czujników posypu. Zamawiający winien określić w SIWZ ilość czujników jakie Wykonawca Winien dostarczyć. Czujniki winny współpracować z urządzeniami pojazdowymi Zamawiającego. Czujniki winny być przystosowane do pracy w warunkach zimowych. Czujniki posypu winny rejestrować stan urządzenia posypującego w zakresie pracuje/ nie pracuje, Czujniki pługa winny rejestrować stan pługa w zakresie opuszczony/poniesiony, Czujniki winny być przystosowane do montażu na urządzeniach, których prace będą monitorowały, Wykonawca winien dostarczyć wraz czujnikami oprzyrządowanie niezbędne do ich montażu na urządzeniach, których prace czujniki będą monitorować, Wykonawca winien dostarczyć wraz czujnikami oprzyrządowanie niezbędne do podłączenia czujników do urządzeń pojazdowych Zamawiającego, Dostawa wraz z montażem cyfrowych rejestratorów obrazu. Wykonawca winien dostarczyć i zamontować na pojazdach wskazanych przez Zamawiającego fabrycznie nowe cyfrowe rejestratory obrazu w ilości 12 (dwanaście) sztuk, wraz kartami pamięci o pojemności 32 GB. Wykonawca winien dostarczyć także niezbędne oprzyrządowanie służące do zamocowania rejestratora lub jego kamery w pojeździe, tak by rejestrowany był obraz przed pojazdem (przez przednią szybę) oraz podłączenia rejestratora do urządzenia pojazdowego. Rejestratory winny współpracować z urządzeniami pojazdowymi (GPS) Zamawiającego. Dostęp do kart pamięci winien być swobodny, tzn. karta nie powinna być w sposób stały zabudowana. Każde wyjęcie oraz włożenie karty pamięci do rejestratora winno być rejestrowane przez urządzenie pojazdowe jako zdarzenie. 96

97 Dostęp do danych znajdujących się na karcie pamięci winien być autoryzowany. Wykonawca winien uwzględnić konieczność dostępu do danych znajdujących się na katach pamięci tylko osobom upoważnionym i tylko za pomocą aplikacji systemu. Cyfrowe rejestratory obrazu winny posiadać parametry nie gorsze a niżeli; Możliwość zapisu obrazu w interwale czasowym zdefiniowanym w aplikacji serwerowej systemu utrzymania, nie rzadszym niż 1 obraz co 2 sekundy. Zapis do pliku JPG, Plik JPG o rozdzielczości 640x480px, Możliwość wyboru zapisu pliku w trybie; odcienie szarości, kolor, Dostarczone przez Wykonawcę cyfrowe rejestratory obrazu winny posiadać podświetlenie rejestrowanego obrazu za pomocą diod IR SYSTEM ZARZĄDZANIA GPS WE FLOCIE SAMOCHODOWEJ Projekt wykonawczy Systemu zarządzania GPS we flocie samochodowej zostanie stworzony przez Wykonawcę i przedstawiony do akceptacji przez Zamawiającego. Na miesiąc przed oddaniem modułu (zgodnie z harmonogramem realizacji pkt. 5.3 ppkt. 10). Zamawiający przekaże Wykonawcy karty SIM, które ten w ramach projektu zamontuje w urządzeniach GPS. Zamawiający wybierze operatora odpowiedzialnego za przesył danych, odrębnym postępowaniem przetargowym. Zakres zamówienia 1. Wykonawca dostarczy i zamontuje urządzenia systemu, który umożliwia lokalizację i monitoring GPS przy użyciu technologii transmisji danych GSM-GPRS floty pojazdów. 2. System powinien pozwolić na dokładne określenie pozycji danego samochodu na drogach Województwa Kujawsko - Pomorskiego. System powinien pozwalać na dostęp do aktualnej pozycji samochodu, weryfikacji czasu pracy pojazdów, czasu i miejsc postojów, odtworzenia tras przejazdów, określenie aktualnej prędkości poruszania się danego pojazdu. 3. System powinien odświeżać, uaktualniać dane lokalizacyjne pojazdu nie rzadziej niż co 60 sekund. 4. Zamawiający, użytkownik systemu powinien mieć dostęp do danych generowanych przez system tj. raportów dziennych, tygodniowy i miesięcznych oraz odzwierciedlenie trasy przejazdu na mapie drogowej. Dostęp powinien być zapewniony z każdego komputera 97

98 korzystającego z sieci Internet. Generowanie oraz przeglądanie raportów powinno następować bez instalacji żadnego dodatkowego oprogramowania. Powinna istnieć możliwość importowania raportów do wybranych formatów: Microsoft Word, Microsoft Excel. a) Raport powinien zawierać godzinę rozpoczęcia przejazdu w danym dniu, godzinę i łatwo identyfikowane (współrzędne geograficzne lub nazwę najbliższej miejscowości i kod pocztowy lub nr i kilometraż drogi) miejsce postoju, czas postoju, dzienną prędkość średnią przejazdu, łączny czas jazd i postojów. b) Dostęp do raportów i map powinien być zapewniony przez minimum 6 miesięcy po zakończeniu danego miesiąca oraz do danych archiwalnych. 7. Zamawiający ze względów organizacyjnych dzieli pojazdy na 7 grup wg jednostek organizacyjnych Rejonów i samego Zarządu Dróg Wojewódzkich. Do danych uzyskanych z monitoringu powinien być zapewniony następujące konta dostępu: a) Jedno konto do całej floty pojazdów. b) Po jednym koncie dla danej grupy pojazdów. c) Konto z dostępem do danej grupy nie może mieć dostępu do innych grup pojazdów. d) Powinna być zapewniona swobodna możliwość przypisywania, po wdrożeniu systemu, dowolnego pojazdu do dowolnej grupy. 8. Urządzenia lokalizatory montowane w pojazdach: a) Zamawiający wymaga by Wykonawca swoim staraniem i w koszcie usługi zamontował urządzenia lokalizatorów w pojazdach objętych monitoringiem. Urządzenia powinny posiadać wymagane prawem homologacje i atesty a ich montaż przez Wykonawcę lub warsztat przez niego wskazany, nie powinien powodować utraty gwarancji producenta udzielonej Zamawiającemu na dany pojazd przez sprzedawcę pojazdu. b) Montaż urządzeń może się odbyć w miejscu użytkowania pojazdów lub w warsztacie specjalistycznym Wykonawcy lub wskazanym przez Wykonawcę serwisie danej marki samochodu, jednak nie położonym dalej niż 60 km od miejsca jednostki organizacyjnej Zamawiającego użytkującej pojazd. W takim przypadku Zamawiający w uzgodnionym terminie dostarczy pojazd do wskazanego warsztatu/ serwisu na własny koszt. c) Urządzenia powinny być zamontowane w pojazdach w miejscu niewidocznym, uniemożliwiającym ingerencję kierowcy. d) O nieuprawnionym odłączeniu urządzenia, jego awarii lub elektronicznym zagłuszaniu sygnału, system lub operator systemu Wykonawca, powinien niezwłocznie informować Zamawiającego. 98

99 9. Szkolenia i raporty. e) Urządzenia muszą działać bezawaryjnie przez cały okres trwania umowy, jeżeli zachodzi konieczność ich okresowej konserwacji, w tym np. wymiany baterii, Wykonawca powinien ten serwis wliczyć w oferowana cenę usługi. a) Wykonawca przeprowadzi w siedzibie Zamawiającego szkolenie z obsługi systemu po podpisaniu umowy, jednak nie później niż w terminie do r. Koszt szkolenia powinien zostać uwzględniony w cenie usługi. b) Wykonawca będzie przesyłał Zamawiającemu drogą elektroniczną, miesięczne raporty dla grup pojazdów i jeden raport zbiorczy dla całej floty pojazdów. Zawartość raportów zostanie ustalona, po podpisaniu umowy przez przedstawicieli stron wymienionych w umowie. c) Koszty Wykonawcy sporządzenia wysyłanych miesięcznych raportów. w okresie trwania umowy, powinny być przez Wykonawcę wliczone w cenę usługi. Urządzenie GPS zawierające odbiornik GPS oraz modem GSM/GPRS umożliwiający montaż karty SIM zainstalowany w monitorowanym obiekcie spełniający następujące parametry: 1. Dokładność GPS do 5 m. 2. Wyposażenie: antena magnetyczna GPS, antena klejona GSM. 3. Zasilany z instalacji elektrycznej pojazdu, posiadający zasilanie awaryjne na wypadek utraty zasilania z instalacji elektrycznej pojazdu 4. Praca z napięciami 12/24 V 5. Pozycjonowanie (odświeżanie pozycji) pojazdów, co 1 minutę, oraz przy zmianie pozycji o 200 metrów lub przy zmianie kierunku poruszania o 45 stopni. 6. Rejestrowanie danych w wewnętrznej wbudowanej pamięci, co 5 sekund lub przy zmianie pozycji o 100 metrów 7. Zdalna kalibracja/programowanie urządzenia. 8. Bufor pamięci zdarzeń SYSTEM ZARZĄDZANIA UTRUDNIENIAMI DROGOWYMI Zakres prac obejmuje, zaprojektowanie i wdrożenie systemu zarządzania utrudnieniami drogowymi, w tym: 1. Opracowanie i uruchomienie Mapy Multimedialnej Dróg i Utrudnień Drogowych 2. Uruchomienie systemu do prowadzenia Akcji Zima 99

100 W ramach zamówienia wykonawca zobowiązany jest wykonać projekt wykonawczy systemu zarządzania utrudnieniami drogowymi, który zostanie przedstawiony do akceptacji przez Zamawiającego. System musi spełniać następujące, minimalne wymagania funkcjonalne: 1. System musi pozwalać na rejestrację utrudnień drogowych, przynajmniej w w zakresie: a) katastrof, w tym danych dotyczących: 1. daty wystąpienia katastrofy, 2. daty i nr protokołu, 3. zakresu uszkodzeń, 4. przyczyn katastrofy, 5. daty usunięcia uszkodzeń, b) wypadków, w tym: 1. rodzaj wypadku, 2. przyczyny, 3. ilości ofiar, w tym ilość ofiar śmiertelnych, rannych, c) robót drogowych, d) zamknięć dróg, e) zajęcia pasa drogowego, f) awarii mostu, g) sygnalizacji, h) ruchu wahadłowego, i) nośności, j) nacisku na oś, k) szerokości, l) prędkości, m) skrajni pionowej, n) skrajni poziomej, o) innych utrudnień, 2. Dla poszczególnych rodzajów utrudnień systemu musi pozwalać na: 100

101 a) rejestrację danych opisowych dotyczących danego utrudnienia, b) rejestrację daty rozpoczęcia i zakończenia danego utrudnienia, c) rejestrację, danego utrudnienia w stosunku do sieci referencyjnej, z możliwością ścisłego określenia drogi, odcinka referencyjnego oraz kilometrażu pikietażu którego danego graniczenie dotyczy, 3. Lokalizacja utrudnień musi być możliwa z poziomu mapy. W takim przypadku system musi automatycznie wyliczyć lokalizacje zdarzenia drogowego w stosunku do sieci referencyjnej. 4. System musi pozwalać na wprowadzenie utrudnień przez użytkowników poszczególnych rejony ZDW (RDW) oraz ich edycji i akceptacji przez użytkownika ZDW. 5. System musi współpracować z modułami: a) zajęcia pasa drogowego, b) utrzymania bieżącego, c) robót budowlanych, w zakresie zapewniania ich powiązania z odpowiednimi utrudnieniami na drodze. 6. Wszystkie dane zgromadzone w systemie i posiadające odniesienie przestrzenne muszą być prezentowane na mapie w postaci odpowiednich map tematycznych z możliwością wyszukiwania tych danych z poziomu mapy poprzez precyzyjne określenie atrybutów wyszukiwanych obiektów lub podanie filtra przestrzennego. W szczególności system musi prezentować odpowiednie dane tematyczne na: a) Geoportalu Intranetowym b) Geoportalu Internetowym 7. System zarządzania utrudnieniami drogowymi musi być wykonany, tak by mapa utrudnień wraz z jej wszystkimi komponentami była widoczna podczas przeglądania na urządzeniach mobilnych np. Smartfon, działających pod systemami operacyjnymi takimi jak: Android, Windows mobile. System przeznaczony do wprowadzania dziennych raportów dotyczących stanu dróg w każdym z Rejonów Dróg Wojewódzkich. 101

102 Codziennie na podstawie 4 raportów 6 rejonów, ZDW generuje raport zbiorczy. Wygenerowany raport zbiorczy przesyłany jest poprzez specjalnie zdefiniowany Newsletter na podane adresy . Raport zbiorczy dostępny jest również poprzez kanał RSS. System zintegrowany jest z modułem zarządzania mapą i wykorzystuje możliwie wiele elementów które są już zdefiniowane w mapie. Raporty godzinowe raporty godzinowe generowane są przez użytkowników w ośrodkach RDW lub przez użytkownika ZDW w wyjątkowych przypadkach raport generowany codziennie jest na godz.: 6.00, 10.00, 15.00, (w 90% przypadku występują dwa pierwsze, w sytuacjach krytycznych występuje raport na godz. 15 i 18), godziny dostępne są ze słownika raport na godz. 10 dodatkowo zawiera informacje o przeprawach promowych raport godzinowy generowany jest wg wzoru z pliku Sposób generowania raportu godzinowego raport generowany jest przez użytkownika z poszczególnych rejonów lub użytkownika ZDW użytkownik RDW po zalogowaniu się ma dostęp wyłącznie do modułu zarządzania raportami (lub inne uprawnienia jeśli ten sam użytkownik wykorzystuje inne funkcje systemu zarządzania mapą lub e-cms) użytkownik RDW może dodać nowy raport użytkownik RDW może zapisać zdefiniowany raport i później edytować edycja raportu możliwa jest wyłącznie jeśli raport nie został zaakceptowany edycja raportu możliwa jest jeśli godzina edycji nie przekroczyła godziny raportu użytkownik RDW może zaakceptować raport raport zaakceptowany jest dostępny dla użytkownika RDW bez możliwości edycji na potrzeby raportu użytkownik RDW może wybrać drogi z listy dróg należących do danego RDW do którego należy użytkownik istnieje mechanizm przeglądania raportów np. Filtrowania wg daty, godziny, zalogowanego użytkownika (loginu = imię i nazwisko) lista raportów posiada mechanizmy sortowania rosnąco malejąco dla poszczególnych kolumn 102

103 każdy raport posiada dodatkowe informacje: data utworzenia data ostatniej zmiany (historia zmian raportu) data akceptacji nazwa użytkownika który utworzył raport nazwa użytkownika który zmienił raport każdy raport można wydrukować każdy raport przesyłany jest po akceptacji w formacie PDF na zdefiniowane adresy (słownik) raport otrzymuje status archiwalny jeśli data jego wygenerowania będzie starsza niż 7 dni od dnia dzisiejszego użytkownik RDW ma dostęp do zatwierdzonych raportów zbiorczych w trybie do odczytu Sposób generowania raportu zbiorczego raport zbiorczy generowany jest przez użytkownika ZDW użytkownik ZDW ma dostęp do wszystkich raportów godzinowych generowanych przez RDW z podziałem na zaakceptowane, w realizacji, archiwalne użytkownik ZDW ma możliwość edycji raportów godzinowych pod warunkiem ze nie został dla niego wygenerowany i zatwierdzony raport zbiorczy użytkownik ZDW ma możliwość dodania raportu godzinowego w imieniu użytkownika RDW (w tym przypadku jako generującego raport godzinowy zapisywane są dane użytkownika ZDW) wygenerowany raport zbiorczy może być zapisany do bazy bez akceptacji użytkownik ZDW zatwierdza raport zbiorczy po wykonaniu zatwierdzenia nie ma możliwości poprawy raportu zbiorczego zatwierdzony raport zbiorczy jest dostępny dla użytkowników RDW w trybie do odczytu zatwierdzony raport zbiorczy: można wysłać jako załącznik na zdefiniowane adresy (operacja wykonywana ręcznie przez użytkownika ZDW) udostępnić poprzez kanał RSS wysłać do zainteresowanych użytkowników poprzez newsletter 103

104 Raport godzinowy Raport zawiera dane stałe oraz pola zmienne data raportu godzina raportu (zdefiniowane do wyboru z listy (6,10,15,18) RDW do którego należy raport Blok I zestawienie stanu dróg Zestawienie tabelaryczne dróg z zachowaniem podziału na standardy dróg (III, IV, V): numer drogi (dane słownikowe) relacja drogi stan drogi (dane słownikowe) stan pogodowy Blok II zestawienie warunków pogodowych zestawienie tabelaryczne zawierające stan pogody na daną godzinę sprzęt nazwę obwodu drogowego stan pogody pługi temperatura (pole liczbowe) opady (pole słownikowe) wiatry (pole słownikowe) na stanie praca piaskarki, solarki, posypywarki unimogi na stanie praca na stanie praca zatrudnieniu pracownicy 104

105 podsumowanie dla poszczególnych kolumn sprzętu i pracowników Uwagi Blok III zamknięcia dróg zestawienie tabelaryczne zawierające Nr drogi standard drogi przebieg drogi długość odcinka (pole liczbowe) Blok IV informacje uzupełniające wg stanu na dzień poprzedni zestawienie tabelaryczne zawierające dane Dyżur Praca Podsumowanie Podpis dyżurnego (imię i nazwisko) Raport zbiorczy Raport zbiorczy zdefiniowany jest wg wzoru i zawiera datę raportu (automat) godzinę raportu (automat) do raportu brane są zestawienia godzinowe z RDW, które maja tą sama datę oraz tą samą godzinę) raport zbiorczy obejmuje zestawienie dróg wyłącznie w trzecim standardzie utrzymania zestawienie tabelaryczne dróg zawiera: numer drogi przebieg drogi stan drogi Przeprawy promowe występuje wyłącznie w raporcie na godz. 10 zawiera zestawienie 4 dróg na których występują promy: numer drogi miejscowość status 105

106 kursuje nie kursuje zestawienie tabelaryczne stanu pogodowego zawiera zestawienie stanu pogodowego w poszczególnych RDW nazwa RDW Stan pogody Sprzęt Temperatura Opady Wiatry pługi na stanie praca piaskarki, solarki, posypywarki na stanie praca unimogi na stanie praca Zatrudnieniu pracownicy Zamknięte drogi zestawienie tabelaryczne tworzone automatycznie na podstawie raportów godzinowych RDW i zawiera numer drogi standard drogi lokalizacja (rozumiem ze mowa o trasie przebiegu) długość odcinka informacje uzupełniające zestawienie tabelaryczne tworzone automatycznie na podstawie raportów godzinowych RDW i zawiera dane Ładowacze Dyżur 106

107 Praca Nośniki Dyżur Praca Łączna długość jednocześnie posypanych dróg Imię i nazwisko generującego raport Koszty Moduł przeznaczony jest do codziennego raportowania w zakresie kosztów bieżącego utrzymania dróg. Podstawowe możliwości modułu definiowanie grup sprzętu oraz urządzeń (wspólny dla modułu koszty i Akcji Zima) definiowanie stawek dla poszczególnych urządzeń, indywidualnie dla każdego z RDW definiowanie materiałów oraz stawek użycia dla każdego z rejonów inne koszty zachowanie podziału kosztów z uwzględnieniem kosztów odśnieżania oraz kosztów zwalczania śliskości definiowanie codziennych meldunków kosztowych przez rejony definiowanie meldunku zbiorczego przez ZDW (automatyczna agregacja danych z meldunków rejonowych) generowanie raportu w formacie PDF i eksport danych kosztowych do formatu CSV raporty koszty za dzień koszty za okres 107

108 9 SZCZEGÓŁOWE WYMAGANIA FUNKCJONALNE PODSYSTEMU ZARZĄDZANIA INFORMACJĄ 9.1 SERWER MAP 1. Serwer usług danych przestrzennych zapewni prezentację danych zapisanych w następujących formatach: a) Microsoft SQL Server, b) Oracle, c) PostgreSQL (PostGIS), d) Shapefile, e) WFS (połączenie do innego serwera WFS), f) WMS (połączenie do innego serwera WMS), g) GeoTiff: a) mozaika, b) piramida, c) pojedynczy plik. 2. Aplikacja serwera danych przestrzennych musi mieć możliwość: a) działania na platformie Linux (32 oraz 64 bity), b) działania na platformie Windows Server (32 oraz 64 bity), c) działając na platformie 64 bitowej, aplikacja powinna mieć możliwość, d) działania w trybie 64bitowym oraz 32 bitowym. 3. Serwer map musi umożliwiać transformację współrzędnych w czasie rzeczywistym, dla WMS i WFS, dla układów współrzędnych określonych kodem EPSG, na podstawie wbudowanej bazy układów współrzędnych zwierającej, co najmniej układy: a) 1965 (wszystkie strefy), b) 2000 (wszystkie strefy), c) 1992, d) UTM, e) Google Mercator (EPSG:900913), f) WGS 84 (EPSG:4326). 4. Serwer usług danych przestrzennych zapewni obsługę standardów OGC: 108

109 a) WFS 1.0, 1.1, 2.0 b) WMS 1.1.1, 1.3, c) WMTS 1.0.0, d) WCS 1.0.0, e) TMS f) WMS-C g) SLD 1.0, h) Filter Encoding Implementation Specification w wersji Serwer map musi umożliwiać generowanie map poprzez standard WMS co najmniej w formatach: a) JPEG, b) GIF, c) PNG, d) PDF, e) SVG, f) KML, g) GeoRSS. h) Serwer map musi serwować dane przez WFS co najmniej w następujących formatach: i) GML (2.1.2 i 3.1.1), j) GeoJSON, k) Shapefiles. 6. Serwer map musi mieć możliwość stosowania w wygenerowanych przez WMS mapach anti-aliasingu. 7. Serwer map musi umożliwiać zdefiniowanie szablonu treści danych opisowych obiektów uzyskiwanych metodą GetFeatureInfo zgodną ze standardem WMS. Szablony treści atrybutów powinny być definiowane dla wszystkich warstw lub dla jednej warstwy. 8. Serwer zapewni narzędzia do tworzenia kafelek dla dowolnych skal i układów odniesienia. Narzędzia z poziomu interfejsu graficznego będą umożliwiały: 109

110 a) tworzenie kafelek dla nowego poziomu skalowego dodanego do istniejących poziomów, b) aktualizacją kafelek dla zadanego obszaru (w tym nieregularnego poligonu). 9.2 KOMPONENT MAPOWY WYMAGANIA KOMPONENTU MAPOWEGO PO STRONIE KLIENTA 1. Komponent mapowy jest aplikacją klienta do wyświetlania map, działającym z poziomu przeglądarki internetowej, który jest uruchamiany z poziomu: a) rejestrów i ewidencji poszczególnych systemów dziedzinowych, b) Geoportalu Intranet, c) Geoportalu Internet 2. Komponent mapowy musi posiadać możliwość wyświetlania danych przestrzennych, udostępnianych przez serwer map. 3. Komponent mapowy musi działać, co najmniej na następujących przeglądarkach internetowych: a) Internet Explorer 8+ b) Mozilla Firefox 4+ c) Opera 11+ d) Chrome Komponent mapowy nie może wymagać instalowania żadnego dodatkowego oprogramowania po stronie klienta oraz obecności w systemie przeglądarek. 5. Komponent mapowy musi składać się z następujących elementów: 110 dodatków (plugin) do a) okna mapy, wraz z informacją o prezentowanej skali mapy, wskazanych współrzędnych x,y, z możliwością jego dopasowania do pełnego zasięgu przeglądarki internetowej. b) okna zarządzania wyświetlaną treścią (legendą), c) paska narzędzi umożliwiającego wykonywanie podstawowych operacji na mapie. 6. Legenda musi umożliwiać prezentację warstw oraz kategorii, map tematycznych (według atrybutów obiektów) wraz z prezentacją stylistyki obiektów w legendzie. 7. Pasek narzędziowy musi umożliwiać:

111 a) przesuwanie, b) powiększanie/pomniejszanie (przyciski i kółko myszy), c) powiększanie prostokątem (funkcjonalność możliwa również przy użyciu klawiatury np. poprzez wciśnięcie klawisza shift i narysowaniu na mapie prostokąta), d) maksymalne oddalenie, e) pomiar odległości, f) pomiar powierzchni, g) informacje o obiekcie, h) wyszukiwanie działek ewidencyjnych, adresów, współrzędnych, i) podgląd atrybutów obiektów prezentowanych na mapie j) poprzedni widok, kolejny widok k) dodanie pliku GeoTiff do przeglądania, z automatycznym jego wyświetleniem na mapie, l) odczytanie wykazu współrzędnych z plik tekstowego (pikiet) z automatycznym ich wyświetleniem na mapie, m) możliwość identyfikacji obiektów na mapie przeglądania atrybutów obiektów wskazanych kursorem; n) płynne (podczas ruchu myszą nad mapą) wyświetlenie współrzędnych na które wskazuje kursor 8. Komponent mapowy musi umożliwiać prezentację atrybutów obiektów zlokalizowanych po wyborze obiektu na mapie, z wykorzystaniem metody GetFeatureInfo opisanej w standardzie WMS. 9. W powyższym przypadku, gdy użytkownik posiada uprawnienia dostępu do danego rejestru lub ewidencji, musi on posiadać możliwość podglądu szczegółowych informacji zgromadzonych w danym rejestrze lub ewidencji. 10. Komponent mapowy musi umożliwiać tworzenie punktowych, liniowych i obszarowych obiektów przestrzennych, jak również ich usuwanie, jeśli jest to wymagane przez rejestr lub ewidencję. 111

112 11. Komponent mapowy musi dawać możliwość edycji geometrii istniejących obiektów przestrzennych w zakresie przesuwania, dodawania i usuwania werteksów, jeśli jest to wymagane przez rejestr lub ewidencję. 12. Komponent mapowy musi posiadać możliwość wyświetlania podkładów mapowych dla map, pochodzących z zewnętrznych, dostępnych źródeł w postaci usług WMS (np. geoportal.gov.pl) lub też innych (np. openstreetmap.org, maps.google.pl itp.). Wymagane jest zapewnienie możliwości płynnego (dynamicznego) zmiany podkładu mapowego dla danej mapy. 13. Komponent mapowy musi zapewniać możliwość dostępu do szczegółowych danych znajdujących się w rejestrach i ewidencjach po kliknięciu na obiekt system przekierowuje użytkownika do odpowiedniej informacji (formularza) zawartej w rejestrze lub ewidencji WYMAGANIA DOTYCZĄCE KOMPONENTU MAPOWEGO PO STRONIE SERWERA 1. Komponent mapowy musi posiadać moduł administracyjny, umożliwiający jego konfigurację. 2. Funkcje administracyjne związane z konfiguracją komponentu mapowego muszą być dostępne z poziomu interfejsu użytkownika, działającego w przeglądarce internetowej. 3. Funkcje administracyjne związane z konfiguracją komponentu mapowego muszą polegać na definiowaniu map wyświetlanych przez ten komponent, co najmniej w zakresie konfiguracji: legendy, kategorii, warstw z kolejnością ich wyświetlania, użytej stylistyki oraz widoczności. 4. Administrator komponentu mapowego musi posiadać możliwość definiowania uprawnień dostępu użytkowników do zdefiniowanych map. 5. Moduł administracyjny komponentu mapowego musi być zintegrowany z modułem administracyjnym, systemu a dane konfiguracyjne muszą być przechowywane w bazie danych. 9.3 GEOPORTAL INTRANET Geoportal Intranetowy będzie wewnętrznym portalem informacyjnym, który zapewni integrację danych zawartych w poszczególnych modułach dziedzinowych systemu w postaci map 112

113 tematycznych, dostępnych dla użytkowników posiadających stosowne uprawnienia. W ten sposób możliwa będzie integracja danych pochodzących z różnych rejestrów i ewidencji, których zakresy informacyjne, nie są powiązane wzajemnymi relacjami obiektów (są rozdzielne), a ich wzajemne powiązanie jest możliwe tylko pod warunkiem posiadania przez dane indeksu przestrzennego. Geoportal Intranetowy, będzie pełnić funkcje najprostszego interfejsu dostępu do szczegółowych danych zawartych w rejestrach i ewidencjach systemu, gdzie użytkownik z poziomu danej mapy tematycznej, będzie posiadał dostęp do odpowiedniej informacji zawartej w danym rejestrze lub ewidencji, zgodnie z uprawnieniami, jakie posiada użytkownik danego rejestru lub ewidencji. Z poziomu mapy, system zapewni przekierowanie użytkownika do szczegółowej informacji zawartej w danym rejestrze lub ewidencji. 9.4 GEOPORTAL INTERNET Geoportal Internetowy zapewni dostęp do danych publicznych zawartych w rejestrach i ewidencjach systemu, dotyczących istotnych danych dla obywateli i przedsiębiorców, użytkowników dróg takich jak organizacja ruchu drogowego, planowane remonty i inwestycje itp. Geoportal zapewni także wizualizację danych, pochodzących z innych systemów dziedzinowych takich jak system ITS, system utrzymania zimowego itp. Geoportal stanowić będzie węzeł infrastruktury informacji przestrzennej kraju, zgodnie z wymaganiami ustawy o infrastrukturze informacjami prawnej. System zapewni udostępnienie usług WMS z jednej strony (np. map z organizacją ruchu drogowego dla wojewódzkiego systemu informacji przestrzennej), z drugiej zaś zapewni komunikację z usługami udostępnionymi przez inne węzły infrastruktury informacji przestrzennej (np. umożliwi wyświetlanie map topograficznych, map ewidencyjnych czy ortofotomapy). W ten sposób wdrożenie systemu zarządzania infrastrukturą drogową wpisze się w wojewódzką strategię budowy systemu informacji przestrzennej, a w szczególności zapewni współpracę z powiatowymi węzłami infrastruktury przestrzennej naszego województwa. Geoportal publiczny musi prezentować minimum następujące dane: 1. System referencyjny. 2. Preselekcja, w tym: a) stacje meteorologiczne, b) stacje monitorowania ruchu, c) punkty akwizycji obrazu, wraz z podglądem obrazu video. 113

114 3. Utrudnienia ruchu, w tym następujące informacje: a) remonty, budowy i przebudowy: rozpoczęte, planowane, zakończone, b) roboty budowlane inne (prace bieżące), c) katastrofy, d) wypadki, e) ograniczenia szerokości, f) skrajnie pionowe i poziome, g) ograniczenia szerokości, h) dopuszczalne naciski, i) awarie obiektów inżynierskich, j) sygnalizacja świetlna, k) ruch wahadłowy, l) drogi zamknięte, m) ograniczenia prędkości. 4. Utrzymanie zimowe, w tym następujące informacje w tym szczegółowe informacje dotyczące stanu nawierzchni dróg. 5. Natężenie ruchu drogowego 114

115 10 SZCZEGÓLOWE WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA NARZĘDZIOWEGO OPROGRAMOWANIE BAZODANOWE 1. Oprogramowania musi być dostępne dla systemów operacyjnych co najmniej: Linux 32-bit i 64-bit, MS Windows 32-bit i 64-bit oraz zaoferowanego systemu operacyjnego dla serwera baz danych. Identyczna funkcjonalność serwera bazy danych na w/w platformach. 2. Wykonawca zobligowany jest dostarczyć bezterminową licencje oprogramowania bazodanowego na procesor do serwerów dostarczanych w ramach projektu. 3. W systemie musi być zachowana niezależność platformy systemowej dla oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych. Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego. 4. Przetwarzanie z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych. 5. Możliwość zagnieżdżania transakcji powinna istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. Przykładowo powinien być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana. 6. Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode). 7. Możliwość migracji zestawu znaków bazy danych do Unicode. 8. Możliwość redefiniowania przez klienta ustawień narodowych symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych. 9. 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 115

116 10. Możliwość otworzenia wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych 11. Wsparcie protokołu XA 12. Wsparcie standardu JDBC Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym. 14. Motor bazy danych powinien umożliwiać wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz dla wybranych zapytań. Powinna istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL. 15. Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy). 16. 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 powinien być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu. 17. Procedury i funkcje składowane powinny mieć możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje powinny 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 powinny 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). 18. Możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej) 19. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego 116

117 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 powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views). 20. W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek. 21. Powinna istnieć możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych 22. Baza danych powinna umożliwiać 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ń. 23. Przywileje użytkowników bazy danych powinny 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). Baza danych powinna umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W każdej chwili by wykonać jakąkolwiek czynność w zakresie systemu zarządzania bazami danych użytkownik musi posiadać odpowiednią rolę bądź podzbiór ról ze zbioru ról dostępnych w systemie zarządzania bazami danych. 24. 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, ArcServe itd). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online. 117

118 25. Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup). 26. Odtwarzanie powinno 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. 27. W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych. 28. Możliwość pracy na maszynie wyposażonej maksymalnie w 2 gniazda procesorowe (ang. sockets) STANOWISKO ANALITYCZNE 1. Moduł musi umożliwić powiązanie przestrzennych i opisowych baz danych stanowiących podstawę z następujących dziedzin: kataster, geodezja, urbanistyka, architektura, gospodarka nieruchomościami, gospodarka komunalna, zarządzanie drogami, ochrona środowiska, zarządzanie kryzysowe. 2. Moduł musi zapewnić współpracę on-line z innymi aplikacjami (np. programy finansowoksięgowe, ewidencja ludności, ewidencja działalności gospodarczej, komunikacja, obieg dokumentów) pracującymi w urzędzie miejskim. 3. Dzięki pracy w sieci moduł musi umożliwiać korzystanie z danych GIS dostępnych w sieciach lokalnych i zewnętrznych. 4. Moduł musi umożliwiać bezpośredni wgląd do danych (on-line) pochodzących z różnych źródeł, którymi mogą być projekty wykonane na platformach: Oracle, MSSQL, Access, ESRI (ARC/INFO, ARC/VIEW), AutoCAD, MicroStation, Map Info, GeoMedia, lub poprzez ich konwersję. Moduł musi pozwalać na generowanie wielokryteriowych analiz na tych danych, generowanie map tematycznych, zestawień i wydruków. 5. Moduł musi zapewnić możliwość wykorzystania wielu formatów rastrowych oraz pozwalać na odczyt georeferencji dla plików rastrowych zapisanych w następujących formatach: TIF, BMP, GEOTIFF, JPEG, GIF, PNG. 118

119 6. Moduł musi zapewniać możliwość utworzenia wspólnej przestrzeni geograficznej w celu wyświetlania i analizowania danych pochodzących z różnych projektów tak, aby istniała możliwość pracy na oryginalnych projektach oraz na zaimportowanych danych. 7. Moduł musi umożliwić wyświetlanie danych w różnych układach współrzędnych, niezależnych od odwzorowania danych źródłowych. Zapewnić także możliwość zmiany odwzorowania podczas pracy z projektem, tzn., gdy wszystkie dane z podłączonych projektów są przeliczane do nowego układu odniesienia on-the-fly, tak, aby użytkownika nie interesowało faktyczne odwzorowanie każdego z projektów będzie ono bowiem automatycznie rozpoznane, a dane geometryczne zostaną przeliczone do zdefiniowanego układu współrzędnych. 8. Moduł musi umożliwiać analizy danych poprzez dostarczenie profesjonalnych narzędzi do analiz danych geograficznych. Pozwalać na wykonywanie skomplikowanych analiz przestrzennych, a także na filtrowanie danych względem atrybutów i zadanych parametrów. 9. Moduł musi zapewnić możliwość tworzenia interaktywnej mapy tematycznej. Mapy takie generowane powinny być na podstawie wybranych pól rekordów z bazy danych. Umożliwienie zastosowania funkcji wyświetlania klas obiektów w zależności od skali mapy ma zapewnić możliwość uzyskania płynnego przechodzenia pomiędzy poziomami informacji o różnych dokładnościach, nie zajmując dzięki temu pamięci danymi, które nie muszą być wyświetlane. 10. Praca z projektem musi odbywać się na wielu oknach jednocześnie, w tym: a) Na oknach mapy (prezentacja graficzna danych), b) Na oknach danych (prezentacja opisowa danych), c) Na oknach wydruku (prezentacja kartograficzna danych). 11. Wgląd w dane przestrzenne przechowywane w relacyjnej bazie danych musi być realizowany bez konieczności generowania jakiejkolwiek warstwy pośredniej (np. rysunku wektorowego). Innymi słowy, aktualny stan bazy danych przestrzennych jest widoczny na ekranie komputera w postaci mapy. Każda aktualizacja bazy danych musi powodować automatyczne uaktualnienie tego rysunku. W takim podejściu, mapa numeryczna jest 119

120 projekcją (raportem) zawartości bazy danych według przyjętego schematu wyświetlania obiektów. 12. Moduł musi umożliwiać wykonywanie wielokryteriowych analiz w oparciu o atrybuty opisowe i relacje przestrzenne obiektów znajdujących się w różnych standardowych bazach danych, zlokalizowanych w różnych miejscach sieci komputerowej. Moduł musi umożliwiać parametryzację tych analiz oraz przekazywanie parametrów wynikowych z jednych analiz, jako danych wejściowych do kolejnych analiz. 13. Wszelkie etykiety obiektów na mapie muszą być wyświetlane on-line z atrybutów obiektów przestrzennych, a system musi przechowywać jedynie dane dotyczące współrzędnych etykiety, ich stylu, kąta obrotu itp. Zmiana atrybutu obiektu musi powodować automatyczne uaktualnienie etykiety tego obiektu na mapie. 14. Moduł musi umożliwiać definiowania szablonów legend map, zawierających obiekty pochodzące z różnych baz danych. Tak więc użytkownik musi posiadać możliwość zdefiniowania legendy zawierającej np. obiekty pochodzące z systemu Ewidencji Gruntów i Budynków - EGIB (np. MSSQL), dane pochodzące z mapy zasadniczej (np. *.dxf), dane dotyczące miejscowych planów zagospodarowania przestrzennego zapisane w formacie MapInfo oraz dane graficzne pochodzące z systemu drogowego (np. Oralce). 15. Moduł musi umożliwiać łatwe tworzenie nowych baz danych przestrzennych o dowolnej tematyce (np. zieleń miejska, oświetlenie, infrastruktura podziemna) w formacie Access, MSSQL, Oracle. 16. Moduł musi zapewnić dostęp do danych i usług za pomocą standardów WMS, WFS oraz WCS. 17. Moduł musi posiadać moduł konfiguracyjny umożliwiający definiowanie wglądu w dane przestrzenne w sposób przyjazny dla określonej grupy użytkowników, w tym: a) Konfigurację klas obiektów, b) Konfigurację atrybutów obiektów (nazwy atrybutów, kolejność atrybutów, słowniki), c) Konfigurację stylistyki obiektów, d) Konfigurację etykiet obiektów, e) Konfigurację legend, 120

121 f) Konfigurację zapytań w oparciu o relacje przestrzenne i opisowe obiektów, g) Konfigurację wydruków. 18. Konfiguracja, o której mowa w powyższym punkcie, musi być wspólna zarówno dla dostępu w architekturze klient serwer jak i Intranet/Internet. System ponadto musi posiadać możliwość tworzenia konfiguracji oddzielnych dla architektury klient oraz Intranet/Internet. 19. Każdorazowa zmiana konfiguracji, o której mowa powyżej musi powodować automatyczną aktualizację sposobu wglądu w dane przestrzenne. 20. Moduł musi umożliwiać tworzenie własnych funkcji, komend, makroinstrukcji i aplikacji na podstawie dostarczonych standardowo obiektów programistycznych. Programowanie powinno odbywać się za pomocą ogólnie znanych języków programowania takich jak: PowerBuilder, Microsoft Visual Basic, Microsoft Visual C++, Microsoft Visual C#. Wykorzystanie technologii OLE i gotowych obiektów powinno ułatwiać programowanie i przyspieszać powstawanie potrzebnych funkcji. 21. Moduł musi zapewniać integrację danych poprzez współpracę z ODBC. 121

122 11 POZYSKANIE DANYCH DO SYSTEMU ZARZĄDZANIA INFRASTRUKTURĄ DROGOWĄ SYSTEM REFERENCYJNY 1. Wdrożenie systemu referencyjnego należy poprzedzić wykonaniem jego projektu uwzględniającego drogi wojewódzkie oraz krzyżujące się z nimi drogi powiatowe i krajowe. Projekt należy przedstawić do zaakceptowania Zarządcy. 2. Podstawowe założenia systemu referencyjnego: a) przebiegi dróg zdefiniowane jako ciągu następujących po sobie węzłów sieciowych i odcinków międzywęzłowych (droga zostanie podzielona na odcinki ograniczone punktami węzłowymi zlokalizowanymi w miejscach charakterystycznych tj. przecięcie osi dróg, przecięcie osi drogi z granicą administracyjną, przecięcie osi drogi z początkiem obiektu mostowego, inne miejsca charakterystyczne w ciągu drogi) b) unikalności numeracji punktów węzłowych należy zapewnić poprzez zastosowanie numeracji w formacie gdzie: c) 1111 to niepowtarzalny w skali kraju 4-cyfrowy numer sektora d) 222 to niepowtarzalny w sektorze 3-cyfrowy numer punktu węzłowego e) numeracja kolejnych odcinków w formacie 010, 020, tak aby móc zapewnić dalszy podział odcinka na 011,012,013...bez naruszania numeracji pozostałych odcinków. 3. Wyniesienie projektu w teren i dokumentacja punktów węzłowych nastąpi po jego zaakceptowaniu przez ZDW, a obejmować będzie: a) stabilizację punktu za pomocą bolca stalowego z napisem znak pomiarowy lub przyjęcie stabilizacji istniejącej (łata na drogach krajowych) b) wykonanie opisu topograficznego oraz pomiar współrzędnych punktu c) wykonanie dokumentacji fotograficznej wlotów na skrzyżowanie d) stabilizację świadka w postaci słupa betonowego z tabliczką oznaczającą numer drogi oraz numer punktu węzłowego 4. Po zastabilizowaniu punktów referencyjnych należy przeprowadzić pomiar wzorcowy odcinków dróg przy użyciu odometru oraz odbiornika GPS. Wymagane jest wykonanie 122

123 pomiarów nadliczbowych (min. 2) aby wyeliminować błędy grube i systematyczne. Wykaz ostatecznych długości i dzienniki poszczególnych pomiarów należy przekazać Zarządcy. 5. Szacuje się, że ilość punktów referencyjnych wyniesie ok. 800 szt STAN PRAWNY ULIC I DRÓG Dane o pasach drogowych należy pozyskać w oparciu o zaakceptowany system referencyjny, który będzie stanowił podstawę określenia przebiegu odcinków dróg. W ramach pozyskania danych należy wprowadzić na podstawie map ewidencyjnych, mapa zasadniczych, ortofotomapy z uwzględnieniem faktycznego przebiegu infrastruktury drogowej. Pasy drogowe należy pozyskać dla całej sieci dróg wojewódzkich o długości: 1732,404 km INFRASTRUKTURA DROGOWA I MOSTOWA 1. Zakres rzeczowy pozyskania danych o infrastrukturze drogowej i mostowej obejmuje: a) inwentaryzacja parametrów technicznych drogi: 1. parametry elementów korytarza drogi (lokalizacja, szerokość, długość, powierzchnia i rodzaj nawierzchni), 2. informacje o skrzyżowaniach (lokalizacja, rodzaj, długość, zabezpieczenie/droga), 3. informacje o obiektach mostowych (lokalizacja, rodzaj obiektu, parametry techniczne), 4. informacje o skrajniach (lokalizacja, rodzaj obiektu, szerokość, wysokość), b) inwentaryzacja zagospodarowania dróg: 1. informacje o zjazdach (lokalizacja, rodzaj, nawierzchnia, szerokość), 2. informacje o obiektach przydrożnych (lokalizacja, rodzaj obiektu), c) inwentaryzacja wyposażenia dróg: 1. informacje o oznakowaniu poziomym, 2. informacje o oznakowaniu pionowym, 3. informacje o barierach i ekranach, 4. informacje o oświetleniu, 5. informacje o sygnalizacji, 123

124 2. Dodatkowo należy wykonać dokumentację fotograficzną elementów pasa drogowego wykonaną w dowiązaniu do systemu referencyjnego, w formie cyfrowych zdjęć wykonanych z interwałem wynoszącym nie więcej niż 5 m. 3. Zdjęcia należy wykonać z sześciu kamer tworzących pojedynczy obraz sferyczny o pokryciu minimum 80% sfery znajdującej się nad miejscem wykonania zdjęcia. Ponadto pojedyncze zdjęcie sferyczne musi zapewnić przegląd sytuacji w płaszczyźnie poziomej 360 stopni i w płaszczyźnie pionowej minimum 290 stopni. 4. Kierunek wykonywania zdjęć musi być zgodny z kierunkiem przebiegu drogi. Wyjątek mogą stanowić drogi jednokierunkowe na których obowiązuje wymuszony kierunek jazdy. a) minimalna rozdzielczość pojedynczego zdjęcia wyrażona w pixelach musi wynosić co najmniej 1600 x 1200, b) każde zdjęcie musi mieć określoną lokalizacje poprzez podanie: 1. współrzędnych X,Y w układzie współrzędnych długości i szerokości geograficznej 3. numeru i kilometraża drogi na której zostało wykonane. 5. Pozyskanie obejmuje następujący zakres ilościowy: a) długość dróg: 1732,404 km b) obiekty mostowe 92 szt PRZEGLĄD OKRESOWY (5 LETNI) Przegląd dróg należy wykonać w oparciu o wizualną metodę oceny stanu nawierzchni BIKB- IBDM opracowana przez Instytut Badawczy Dróg i Mostów w Warszawie, według której uszkodzenia klasyfikowane są wg oceny punktowej i określony zostaje stan nawierzchni (bardzo dobry, dobry, ostrzegawczy, zły,bardzo zły). Zakres rzeczowy kontroli obejmuje: 1. Ocenę stanu technicznego i przydatności do użytkowania jezdni głównych w następującym zakresie: a) uszkodzenia powierzchniowe: 1. ubytki powierzchniowe, 2. wyboje, w tym zapadnięte studzienki i włazy, 3. łaty, 124

125 4. wgniecenia w warstwie ścieralnej, b) odkształcenia nawierzchni: 1. koleiny, 2. garby i przemieszczenia, 3. sfalowania (tarki), 4. zapadnięcia i osiadanie nawierzchni, c) spękania: 1. połączenia technologiczne, 2. spękania liniowe, 3. spękania krawędziowe, 4. spękania poprzeczne, 5. spękania w śladach kół, 6. spękania siatkowe. 2. Ocenę stanu technicznego i przydatności do użytkowania oraz poprawności montażu oznakowania 3. Ocenę stanu technicznego i przydatności do użytkowania poboczy utwardzonych i nieutwardzonych 4. Ocenę stanu technicznego i przydatności do użytkowania chodników i ścieżek rowerowych 5. Ocenę stanu technicznego i przydatności do użytkowania skrzyżowań z koleją i liniami tramwajowymi 6. Ocenę stanu technicznego i przydatności do użytkowania urządzeń bezpieczeństwa ruchu(np. garby) 7. Ocenę odwodnienia ulic. Zakres ilościowy przeglądu obejmuje sieć drogową o długości: 1732,404 km 125

126 12 SZCZEGÓŁOWE WYMAGANIA SPRZĘTU KOMPUTEROWEGO I OPROGRAMOWANIA SYSTEMOWEGO SPRZĘT KOMPUTEROWY I OPROGRAMOWANIE SYSTEMOWE 1. Mobilna stacja robocza (laptop) 12 szt. Lp. Nazwa komponentu 1 Procesor Wymagane minimalne parametry techniczne Procesor x86 czterordzeniowy o częstotliwości taktowania 2,7 GHz, klasy i7 lub równoważny 2 Pamięć RAM 4GB (1x4GB) 1600MHz DDR3 Memory 3 Twardy dysk 250GB SSD 4 Ekran Przekątna 15,6 cala, rozdzielczość 1300x900 5 Zasilanie Bateria typ Li-Ion 9 komorowa, czas pracy na baterii min. 210 min. 6 System operacyjny Microsoft Windows 7 Professional 64 bit PL OEM 7 Oprogramowanie dodatkowe Microsoft Office 2013 Home & Business 32-bit/x64 PL 8 Łączność bezprzewodowa Wireless b/g/n, Bluetooth 9 Klawiatura (QWERTY) międzynarodowa 10 Wyposażenie dodatkowe Wraz z komputerem należy dostarczyć; Stacja dokująca replikator portów dedykowana, wyprodukowana przez producenta komputera, Wielofunkcyjna torba dedykowana dla komputera, wyprodukowana przez producenta komputera, Zewnętrzny dysk twardy 320GB 5400PRM, bufor 8MB, interfejs USB Tablet RTK z anteną 15 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor 1,6 GHz 2 Pamięć RAM 2 GB RAM DDR2 3 Temperatura pracy -20 C do +50 C 4 Dysk twardy 64 GB, SSD 5 Wyświetlacz panoramiczny 5,7'' TFT, rozdzielczość 1024x600, czytelny na słońcu ekran dotykowy rezystancyjny 126

127 6 System operacyjny Microsoft Windows 7 Profesional 64 bit PL 7 Antena Zgodna z Real Time (RTK) 3. Smartfon 15 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor OMAP 4430 Dual Core 1 Ghz 2 Pamięć RAM 1 GB MDDR 16 GB inand 3 Temperatura pracy -20 C do +50 C 4 Wyświetlacz 7,0 TFT LCD WSVGA (1024x600) 5 System operacyjny Android 4 6 Interfejs komunikacyjny Optional 3.5G WWAN (HSPA+/UMTS/EDGE/GPRS/GSM) b/g/n Bluetooth (v2.1+edr class 2) SiRFstarIV GPS (with internal antenna) 4. Laptop do administracji systemu 1 szt. Urządzenie musi być fabrycznie nowe i spełniać niżej podane parametry techniczne. Lp. Nazwa komponentu 1 Procesor Wymagane minimalne parametry techniczne Procesor x86 czterordzeniowy o częstotliwości taktowania 2,7 GHz, klasy i7 lub równoważny 2 Pamięć RAM 8GB (2x4GB) 1600MHz DDR3 3 Twardy dysk 512GB SSD 4 Ekran Przekątna 17 cala, rozdzielczość 1300x900 5 Karta graficzna Zintegrowana karta graficzna HD 6 Zasilanie Bateria typ Li-Ion 9 komorowa, czas pracy na baterii min. 210 min. 7 System operacyjny Microsoft Windows 7 Professional 64 bit PL OEM 8 Oprogramowanie dodatkowe Microsoft Office 2013 Home & Business 32-bit/x64 PL 9 Napęd optyczny Nagrywarka DVD 10 Łączność bezprzewodowa Wireless b/g/n, Bluetooth 11 Klawiatura Podświetlana klawiatura międzynarodowa (QWERTY) 127

128 12 Wyposażenie dodatkowe Wraz z komputerem należy dostarczyć; Zasilacz do podłączenia komputera do standardowego gniazda zapalniczki samochodowej lub przetwornica 230V, Stacja dokująca replikator portów dedykowana, wyprodukowana przez producenta komputera, Wielofunkcyjna torba dedykowana dla komputera, wyprodukowana przez producenta komputera, Zewnętrzny dysk twardy 320GB 5400PRM, bufor 8MB, interfejs USB Rozgałęźnik zasilania zapalniczki samochodowej 42 szt. Lp. Wymagane minimalne parametry techniczne 1 napięcie wejściowe 11-16VDC 2 prąd maksymalny 8A na całe rozgałęzienie 3 gniazda zapalniczki 3 szt 4 gniazdo USB 5VDC/500mA 5 moc maksymalna 120W 6 bezpiecznik 8A 6. Zewnętrzny moduł GPS 14 szt. Lp. Nazwa komponentu 1 Opis ogólny Wymagane minimalne parametry techniczne Zewnętrzny moduł GPS komunikujący się z laptopem/tabletem za pomocą Bluetooth-a 2 Układ GPS Sirf Star III 3 Ilość kanałów odbiornika 20 kanałów 4 Antena GPS Wbudowana antena GPS wewnętrzna, urządzenie winno posiadać złącze anteny zewnętrznej typu MMCX 7. Zestaw komputerowy (stacja robocza) z oprogramowaniem 25 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor Procesor x86 czterordzeniowy o częstotliwość taktowania minimum 3,4 GHz pamięć cache 8MB 2 Pamięć RAM 4GB (1 x 4GB) 1600 MHz DDR3 Non-ECC 3 Twardy dysk SATA 2 x 500 GB 7200 rpm 4 System operacyjny Microsoft Windows 7 Professional 64 bit PL OEM 128

129 5 Oprogramowanie dodatkowe 6 Grafika Zintegrowana HD Napęd optyczny 16 X DVD+/-RW Drive Microsoft Office 2013 Home & Business 32-bit/x64 PL 8 Klawiatura USB Keyboard (QWERTY) 9 Mysz USB Optical (3 buttons scroll) 10 Dysk zewnętrzny Zewnętrzny dysk twardy 320GB 5400PRM, bufor 8MB, interfejs USB Monitory 24cali do zestawów komputerowych 25 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Opis ogólny Monitor LCD o przekątnej 24 cali format 16:9 2 Rozdzielczość nominalna 1920x Rodzaj podświetlenia LED matrycy 4 Złącza VGA,DVI-D, kable do podłączenia zestawu komputerowego 9. Serwer plików (główny) (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 6 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,20 GHz 2 Pamięć RAM 48 GB DDR3, 1333MHz 3 Twardy dysk 8 dysków twardych hot Plug (każdy minimum 146 GB, SAS, NLSAS, SATA), 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 6 Oprogramowanie dodatkowe 7 Zdalna administracja Windows Exchange Standard 2013 OLP GOV Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 8 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera, 129

130 9 Zasilacz 350 Wat + drugi nadmiarowy 10. Serwer plików (zapasowy) (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 6 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,20 GHz 2 Pamięć RAM 48GB DDR3, 1333MHz 3 Twardy dysk 8 dysków twardych hot Plug (każdy minimum 146 GB, SAS, NLSAS, SATA) 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 6 Oprogramowanie dodatkowe 7 Zdalna administracja Windows Exchange Standard 2013 OLP GOV Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 8 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera, 9 Zasilacz 350 Wat + drugi nadmiarowy 11. Lokalny kontroler domeny (obudowa typu Tower z możliwością konwersji do obudowy Rack) 6 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 4 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,4 GHz 2 Pamięć RAM 8 GB DDR3, 1333MHz 3 Twardy dysk 4 dyski twarde (każdy minimum 146 GB, SAS, NLSAS, SATA), możliwość rozbudowy do 8 dysków 4 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 5 Zdalna administracja Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 6 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera, 7 Zasilacz 750 Wat + drugi nadmiarowy 130

131 12. Serwer do obsługi GPS i ZUD (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 6 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,20 GHz 2 Pamięć RAM 24GB DDR3, 1333MHz 3 Twardy dysk 4 dyski twarde hot Plug 2,5 cala (każdy minimum 300 GB, SAS, NLSAS, SATA), 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 6 Zdalna administracja Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 7 Diagnostyka Panel LCD umożliwiający wyświetlanie informacji o stanie serwera, wraz z adresami kart sieciowych 8 Zasilacz 350 Wat + drugi nadmiarowy 13. serwer do obsługi monitoringu i ITS (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor 2 x procesor 10 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 3 GHz 2 Pamięć RAM 96 GB DDR3, min. 1333MHz 3 Twardy dysk 4 dyski twarde hot Plug 2,5 cala (każdy minimum 300 GB, SAS, NLSAS, SATA), 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 6 Zdalna administracja Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 7 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera, 8 Zasilacz 750 Wat + drugi nadmiarowy 9 Karta SAS Dodatkowe karty SAS do podłączenie macierzy 131

132 14. Serwer danych georeferencyjnych (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 6 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,20 GHz 2 Pamięć RAM 48 GB DDR3, 1333MHz 3 Twardy dysk 8 dysków twardych hot Plug 2,5 cala (każdy minimum 300 GB, SAS, NLSAS, SATA) 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 5 Karta iscsi Dodatkowe karty iscsi do podłączenie macierzy 6 Zdalna administracja Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 7 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera, 8 Zasilacz 350 Wat + drugi nadmiarowy 15. Serwer telekomunikacyjny (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Procesor procesor 6 rdzeniowy, 64 bity, minimalna częstotliwość taktowania 2,20 GHz 2 Pamięć RAM 48 GB DDR3, 1333MHz 3 Twardy dysk 8 dysków twardych hot Plug 2,5 cala (każdy minimum 300 GB, SAS, NLSAS, SATA) 4 kontroler umożliwiający konfigurację zainstalowanych dysków w macierzowy SAS macierzach RAID 6 5 System operacyjny Microsoft Windows Server Standard 2012 OLP GOV + 12 CAL Win&Exc 6 Zdalna administracja Karta do zdalnej administracji pozwalająca na zarządzanie serwerem w trybie graficznym 7 Diagnostyka Panel umożliwiający wyświetlanie informacji o stanie serwera 8 Zasilacz 350 Wat + drugi nadmiarowy 9 Web Application Firewall Ochrona aplikacji web 2.0, obudowa Standard Rack lub Virtual Appliance 132

133 16. Serwer kopii zapasowej (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Opis Biblioteka taśmowa LTO-6 2 Pojemność 2.5 TB (nieskompresowana ) / 6.25 TB (skompresowana) 3 Szybkość przesyłu 160 MBps ( 576 GB/godz.) (nieskompresowana) / 400 MBps danych ( 1.44 TB/godz.) (skompresowana) 4 Typ Interfejsu Serial Attached SCSI 2 lub SAS HBA 5 Karta 6Gbps SAS HBA + kabel 6 Wyposażenie dodatkowe 7 Oprogramowanie Taśmy LTO-6 10 szt. Oprogramowanie umożliwiające zainstalowanie do 5 klientów na systemach Windows Server 2008/2012, Redhat Linux Ent 4,5,6 17. Macierz dyskowa (do umieszczenia w szafie RACK) 1 szt. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne Rack wraz z szynami oraz dodatkowym przednim panelem 1 Obudowa zamykanym na klucz chroniącym dyski twarde przed nieuprawnionym wyjęciem z macierzy 2 Interfejsy Minimum 4 3 Kontrolery 2 kontrolery pracujące w trybie active-active, posiadające łącznie min. 4 Gb pamięci cache 4 Ilość slotów Minimum 12 5 Pojemność Łącznie 70 TB w dyskach o prędkości min. 7.2k RPM 18. Szafa Rack U Urządzenie musi być fabrycznie nowe i spełniać niżej podane parametry techniczne (minimalne). Zamawiający dopuszcza zaoferowanie sprzętu o parametrach lepszych od wymagań minimalnych. L Nazwa Wymagane minimalne parametry techniczne p. komponentu 1 Obudowa 42U standardowa stojąca szafa serwerowa 2 Funkcje dostępu Wyjmowane tylne wsporniki ułatwiające prowadzenie okablowania Podwójne tylne drzwiczki z pojedynczym zatrzaskiem Odwracane przednie drzwiczki Wyjmowane drzwiczki z przodu i z tyłu Panel krosowy 24 port kat. 5e - 2 szt. Obrotowe tylne kółka 133

134 19. Konsola KVM Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Ilość portów IP 16 2 zarządzanie LAN/WAN, Internet 3 podgląd Możliwość podglądu 16 serwerów na jednym ekranie 20. Przełącznik sieciowy Urządzenie musi być fabrycznie nowe i spełniać niżej podane parametry techniczne (minimalne). Zamawiający dopuszcza zaoferowanie sprzętu o parametrach lepszych od wymagań minimalnych. L Nazwa Wymagane minimalne parametry techniczne p. komponentu 1 Porty 48 Gigabit Ethernet, 4 porty 1Gbit SFP 2 Obudowa Standard Rack 1U, możliwość połączenia w stos do 12 urządzeń tego samego typu 3 Zarządzanie LAN/WAN, Internet 4 Montaż Uchwyty do szafy rack 1U 21. Zasilacz UPS Urządzenie musi być fabrycznie nowe i spełniać niżej podane parametry techniczne (minimalne). Zamawiający dopuszcza zaoferowanie sprzętu o parametrach lepszych od wymagań minimalnych. L Nazwa Wymagane minimalne parametry techniczne p. komponentu 1 Moc Minimum 5600 Watt z możliwością rozbudowy o dodatkowy moduł bateryjny wydłużający czas pracy zasilacza 2 Obudowa Obudowa o wysokości maksymalnie 4U dedykowana do zamontowania w szafie rack Monitor 50 Urządzenia muszą być fabrycznie nowe i spełniać niżej podane parametry techniczne. Lp. Nazwa komponentu Wymagane minimalne parametry techniczne 1 Częstotliwość odświeżania 200 Hz 2 Jasność 400 cd/m2 3 Format obrazu 16/9 5 Przekątna ekranu

135 12.2 SCHEMAT POŁACZEŃ SERWERÓW 12.3 KOLOKACJA SERWERÓW SYSTEMOWYCH Zamawiający zakłada możliwość kolokacji serwerów odpowiadających za działanie systemu, z uwagi na niewystarczające możliwości własnej serwerowni. Zamawiający wymagać będzie od Wykonawcy wskazania miejsca kolokacji serwerów zgodnie z minimalnymi wymaganiami podanymi w OPZ. Wymagania minimalne : - serwerownia w zasięgu 100 km od siedziby zamawiającego - infrastruktura spełniająca normy TIER III - połączenie z serwerem wirtualnym przy pomocy tunelu VPN - monitoring - klimatyzacja z free-coolingiem - systemy zabezpieczeń z przypadku awarii zasilania UPS i agregat prądotwórczy - fizyczny i logiczny firewall 135