Siwz rsip wersja do zatwierdzenia


System ma umożliwiać indywidualne przenoszenie wybranych zapisów z tabel systemowych do tabel archiwalnych



Pobieranie 3.6 Mb.
Strona9/22
Data27.10.2017
Rozmiar3.6 Mb.
1   ...   5   6   7   8   9   10   11   12   ...   22


System ma umożliwiać indywidualne przenoszenie wybranych zapisów z tabel systemowych do tabel archiwalnych. Wymóg ten dotyczy zarówno tabel logów jak i danych historycznych z pozostałych podsystemów (np. dane historyczne z podsystemu danych fakultatywnych).
Takie same narzędzia i mechanizmy administracyjne mają być stosowane do zarządzania zasobami intranetowymi, ekstranetowymi i internetowymi RSIP.
Interfejs obsługi podsystemu administracji ma mieć postać graficzną, być przyjazny i intuicyjny dla użytkownika w postaci strony WWW obsługiwanej przez popularne przeglądarki internetowe.
System musi spełniać wymogi Ustawy o osobowych i Rozporządzenia Ministra Spraw Wewnętrznych i Administracji 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, Załącznik nr 1 „Środki bezpieczeństwa”, w tym:

- ustalana długość hasła;

- weryfikacja złożoności hasła;

- czas obowiązywania hasła;

- identyfikacja transakcji krytycznych (kto, kiedy, co zmodyfikował/do czego miał dostęp, na jakiej podstawie)

- materiały do aktualizacji wniosków GIODO;

- odpowiednie zasady zarządzania użytkownikami, zasobami;

- odpowiednio skonfigurowane tabele logów itd.


System nie może kasować nieaktywnych użytkowników i danych mapowych/opisowych – należy zmienić im status na nieaktywny oraz zapewnić możliwość przenoszenia starszych danych do tabel archiwalnych.
Obowiązkiem Wykonawcy jest zachowanie należytej staranności i zastosowanie odpowiednich technik, aby w maksymalnie możliwym stopniu zapewnić bezpieczeństwo danych oraz prawidłową i bezpieczną pracę systemu/użytkowników.
Wskazane przez administratora informacje/komunikaty systemowe mają być dodatkowo automatycznie wysyłane do logów serwera Windows (np. błędy w dostępie do warstwy X).

Wskazane przez administratora informacje/komunikaty systemowe mają być dodatkowo automatycznie wysyłane na wskazane adresy mailowe (np. błędy w dostępie do warstwy X mają być wysłane mailem


do administratora systemowego, informacja o zablokowaniu konta użytkownika Y ma być wysłana mailem
do administratora systemowego i lokalnego, informacja o wstawieniu przez Wydział Dróg nowego zlecenia
w module obsługi danych fakultatywnych ma być przesłana mailem do RSK).

Wysyłanie w/w informacji przez system nie może nakładać na Zamawiającego konieczności instalowania dodatkowych systemów wspomagających typu serwer lub klient poczty.

Powyższe zapisy są niezależne od wymogu dotyczącego zapisywania działania systemu/użytkowników
w tabelach logów.
Zamawiający posiada dedykowaną aplikację Centralny Słownik Konwersji (RSIP-CSK) do wiązania danych z różnych systemów.

Program zawiera poniższe tabele konfiguracyjne:

- IMP_PRG_X – dane słownikowe X z systemu PRG (np. IMP_DGD_ULC - nazwy ulic z systemu dgDialog, IMP_PSL_ULC – nazwy ulic z systemu PESEL);

- UNQ_X – tabela zawierające unikalne pozycje słownikowe ze wszystkich systemów (np. UNQ_ULC – zawiera unikalne nazwy ulic z informacją o pochodzeniu);

- DCT_X – ustalony słownik RSIP (np. DCT_ULC zawiera „oficjalne” nawy ulic w systemie RSIP);

- LNK_X – zawiera powiązania pomiędzy UNQ_X a DCT_X.

Na dzień dzisiejszy Zamawiający posiada zdefiniowane powiązania dla nazw ulic oraz numerów adresowych (dla danych z systemów dgDialog i PESEL).
Praca w programie RSIP-CSK składa się z kilku kroków:

- zdefiniowanie/zasilenie słowników RSP (DCT_X);

- zdefiniowanie/zasilenie tabel IMP_PRG_X (ładowanie wykonuje się poza programem);

- uruchomienie w programie procedury aktualizacji słowników, podczas której program porównuje zapisy


w tabelach IMP_PRG_X, UNQ_X i odpowiednio aktualizuje tą ostatnią;

- uruchomienie w programie ręcznego dopasowania danych niepowiązanych do zdefiniowanego słownika DCT_X wraz z Ew. dopisaniem nowych pozycji do słownika.


Wykonawca może wykorzystać RSIP-CSK do definiowania powiązań pomiędzy danymi poszczególnych systemów lub dostarczyć własne rozwiązanie.
Zamawiający posiada symbole mapowe dla zdefiniowanych już w systemie warstw punktowych (nie dotyczy warstw pochodzących z zasadniczej mapy numerycznej). Symbole te są opracowane w formacie CDR
i wyeksportowane do BMP. Symbole te powinny być nadal używane w oferowanym systemie, a jeżeli nie jest to możliwe ze względu na format zapisu, Wykonawca ma je przekonwertować zgodnie z potrzebami.

Wykonawca ma dodatkowo opracować symbole dla nowych warstw punktowych, które powstaną w trakcie realizacji zadania.


Szczegółowe ustalenia zostaną przeprowadzone na etapie Projektu technicznego wdrożenia.

1.3.4. Podsystem dedykowanych aplikacji


Dedykowane aplikacje specjalistyczne mają być uruchamiane i użytkowane poprzez standardową przeglądarkę WWW z wykorzystaniem zaimplementowanego w niej interfejsu dostępu użytkownika.
Wymaga się, aby prawa dostępu do tych aplikacji mogły być nadawane poszczególnym użytkownikom niezależnie, w zakresie zgodnym z występującymi potrzebami oraz zasadami ochrony dostępu do danych.
W szczególności dla pewnej grupy użytkowników (np. wewnętrznych) dostępna może być pełna funkcjonalność aplikacji, a dla pozostałych tylko wybrane jej narzędzia. Reglamentacja dostępu do aplikacji (lub różnego jej zakresu funkcjonalnego) ma być możliwa również poprzez fakt autoryzacji dostępu użytkownika do systemu
(np. w procesie logowania).
Aplikacja obsługi danych fakultatywnych
Aplikacja ta przeznaczona będzie przede wszystkim do wprowadzania i edycji (także usuwania) danych specyficznych, charakterystycznych dla danej grupy użytkowników wprost do bazy danych RSIP jako dedykowanej warstwy tematycznej. Ma ona potrafić obsługiwać dowolne dane fakultatywne zapisane
w centralnej bazie danych Oracle Spatial oraz zawierać w sobie funkcjonalność obecnego modułu "RSIP-DMT", rozszerzoną o specyficzne potrzeby włączanych do systemu nowych użytkowników (JM i SP).
Wymagane jest, aby opisywana aplikacja potrafiła łączyć tabele danych opisowych z warstwą tematyczną obiektów przestrzennych zarówno w relacji „jeden do jeden”, „jeden do wielu” oraz „jeden do wielu
do wielu”
.
Do jednego typu obiektu geometrycznego ma być możliwość niezależnego podłączenia kilku tabel opisowych (np. do obiektu geometrycznego typu punkt adresowy można podłączyć tabele opisowe rejestru adresów, rejestru lokali wyborczych, rejestru instytucji kultury itd.).
Ma być także możliwość podpięcia do jednej tabeli opisowej następnej (np. do obiektu geometrycznego typu punkt adresowy podłączamy rejestr zespołów szkolnych, gdzie jednym z pól jest rejestr poszczególnych szkół).
Aplikacja ma zapewnić możliwość obsługi obiektów geometrycznych bez danych opisowych
(np. dołączanych w terminie późniejszym).
Aplikacja ma zapewnić obsługę danych opisowych bez odniesienia graficznego. Przestrzenna lokalizacja danego obiektu będzie mogła być dołożona w przyszłości – w zależności od potrzeb użytkownika.
Aplikacja ma zapewnić pełną obsługę danych we wszystkich w/w opisanych sytuacjach.
Zamawiający dopuszcza tworzonie/edytowanie słowników systemowych przez tą aplikację.
W opisywanej aplikacji wprowadzanie i edycja danych opisowych ma być realizowane na dedykowanych formularzach (format XML/XSL, XForms lub równoważny).

Ma być możliwość przechodzenia użytkownika pomiędzy powyższymi formatkami a prostą postacią tabelaryczną.


Ma być możliwość przypisywania danych do geometrii (powierzchniowej, liniowej, punktowej) pozyskiwanej z innych warstw tematycznych, znajdujących się w systemie lub wykreślonej samodzielnie przez użytkownika (także z użyciem snapowania - dociągania do końców linii i wierzchołków wielokątów) oraz
z wykorzystaniem symboliki obiektów, ustalonej przez administratora.
Wymagana jest możliwość automatycznego tworzenia standardowych formatek wprowadzania/edycji danych dla wszystkich warstw tematycznych oraz indywidualnych dla wybranych warstw.

Aplikacja ma umożliwiać pracę na wszystkich zdefiniowanych w systemie warstwach tematycznych (dotyczy tylko danych fakultatywnych), oczywiście w zależności od posiadanych uprawnień.


System ma umożliwiać dowolne formatowanie okienek narzędzi wprowadzania/edycji danych w zakresie rozmieszczenia pól i ich opisów, typu używanych czcionek, itp. za pomocą dostarczonego generatora graficznego.

Sposób zapisu wszystkich warstw przeznaczonych do edycji za pomocą tej aplikacji ma być jednolity.



Za pomocą modułu danych fakultatywnych użytkownicy mają mieć możliwość tworzenia/edycji bezpośrednio w RSIP-ie nowych/wydziałowych zasobów danych.
W zakresie tworzenia i edycji obiektów wymagana jest następująca funkcjonalność:

  • tworzenie geometrii:

    • kreślenie ręczne poprzez wskazywanie myszką kolejnych wierzchołków obiektu (digitalizacja),

    • kreślenie poprzez podawanie współrzędnych kolejnych wierzchołków obiektu,

    • kopiowanie geometrii z wybranych obiektów z dowolnych zdefiniowanych w całej bazie a udostępnionych do tego celu przez administratora warstw,

    • dociąganie do istniejących wierzchołków innych obiektów z wybranych wcześniej przez administratora warstw,

    • rysowanie nie tylko w obszarze okna (widoku mapy), ale także z możliwością przesuwania obszaru okna bez utraty trybu edycji i ciągłości rysowanych obiektów,

    • możliwość tworzenia obiektów geometrycznych, ale bez atrybutów opisowych,

    • obsługa obiektów mapowych typu multi-point, multi-polyline, multi-polygon;

    • możliwość dodatkowego kreślenia obiektów linią swobodną (analogicznie do narzędzia "ołówek"
      w aplikacji PaintBrush),

  • edycja geometrii:

    • kasowanie obiektu i wykreślenie go od nowa narzędziami tworzenia geometrii,

    • dodanie nowych wierzchołków do istniejącej geometrii obiektu we wskazanych miejscach,

    • edycję położenia istniejących wierzchołków obiektu,

    • snapowanie do istniejących punktów ze wskazanych warstw podkładowych,

  • wprowadzanie/edycja danych opisowych:

    • wybrane do edycji dane mają się pojawić w zdefiniowanej do wprowadzenia danych formatce,

    • definiowanie formatki do wprowadzania/edycji danych w XML/XSL, XForms lub równoważnie,

    • ma istnieć możliwość definiowania pól formatek do wprowadzania danych opisowych w zakresie np.: układu pól i ich opisów, czcionek, itp.,

    • edycja ma być realizowana z zastosowaniem wszystkich zdefiniowanych wcześniej w systemie zasad (np.: pola wyboru, słowniki, listy rozwijalne, maski w polach edycji, itp.),

    • możliwość tworzenia/edycji obiektów posiadających dane opisowe, ale bez geometrii (może być uzupełniana później w trybie edycji);

  • edycja danych pochodzących „spoza” aplikacji do obsługi danych fakultatywnych:

    • poprzez jednorazowe kopiowanie tych danych do struktur aplikacji fakultatywnej;

    • lub przez dostosowanie struktury tych tabel do wymogów aplikacji fakultatywnej (dodanie pól);

    • lub poprzez zdefiniowanie tabel pośrednich.

Zamawiający dopuszcza wykorzystywanie „w tle” na potrzeby edycji/modyfikacji geometrii innych warstw roboczych/tymczasowych.
Aplikacja ma zapewnić unikanie bądź rozwiązywanie konfliktów przy jednoczesnej edycji tych samych danych przez różnych użytkowników.
Po zatwierdzeniu wprowadzania/modyfikacji dany obiekt ma być wyświetlany na mapie w zbliżeniu, podświetlany oraz ma być załączana warstwa, z której pochodzi obiekt (jeżeli nie była wcześniej załączona).
Aplikacja obsługi danych fakultatywnych ma także umożliwiać podłączanie (linkowanie) do obiektów jednego / wielu plików zewnętrznych / plików z wybranego katalogu (zdjęć, zeskanowanych dokumentacji technicznych, dokumentów Office, itp.). Pliki te mogą być zapisywane bezpośrednio w bazie danych systemu RSIP lub w wydzielonych lokalizacjach na dysku serwera. System ma także nadzorować prawa dostępu do nich przez poszczególnych użytkowników.

Pliki te muszą być dostępne dla użytkownika spoza narzędzia edycji (np. przy wyszukiwaniu po nazwie, jako domyślny link dla danego typu obiektu, wyświetlane w raportach).


Zaprojektowana przez Wykonawcę struktura danych fakultatywnych ma obejmować poniższe informacje:

  • w zakresie geometrii:

    • id obiektu graficznego,

    • id obiektu źródłowego/przed modyfikacją,

    • status,

    • data stworzenia,

    • data modyfikacji,

    • id użytkownika tworzącego,

    • id użytkownika modyfikującego,

    • opis geometrii obiektu,

    • inne wynikające z charakteru danych przeznaczonych do obsługi w systemie,

  • w zakresie opisu:

    • id opisu,

    • id obiektu źródłowego/przed modyfikacją,

    • id obiektu graficznego,

    • status,

    • data stworzenia,

    • data modyfikacji,

    • id użytkownika tworzącego,

    • id użytkownika modyfikującego,

    • dane opisowe (ilość pól zależna od rodzaju warstwy),

    • inne wynikające z charakteru danych przeznaczonych do obsługi w systemie.

Wykonawca może zaproponować inną strukturę danych, jednak pod warunkiem zachowania powyższych informacji i równoważnej funkcjonalności.
Przydział uprawnień ma obejmować:

  • nadawanie użytkownikom praw (na ogólnych zasadach) z dokładnością do warstwy tematycznej,

  • możliwość przypisania praw edycji wielu użytkownikom do jednej warstwy tematycznej,

  • możliwość przydziału praw w ramach jednej warstwy tematycznej dla wielu użytkowników, ale z dokładnością do poszczególnych pól tabeli (rozdzielnych i/lub wspólnych uprawnień do tych samych pól),

  • możliwość równoległej pracy kilku użytkowników na jednej warstwie tematycznej z dostępem do różnych pól opisowych (np.: Wydział Dróg wprowadza obiekty do warstwy “znaki do ustawienia na drodze”, natomiast RSK ma dostęp do warstwy i po realizacji zadania uzupełnia wybrane pola danego obiektu).


Obsługa zdarzeń historycznych ma obejmować :

  • odnotowywanie w systemie każdej zmiany o charakterze dodanie/edycja danych (dotyczy to informacji
    o położeniu obiektu, jego geometrii jak i danych opisowych),

  • możliwość odtworzenia/prześledzenia historii każdego obiektu (od momentu jego powstania, w zakresie zmian geometrii i danych opisowych, kiedy i przez kogo zostały zrealizowane zmiany – np. w formie raportu opisującego poszczególne stany obiektu wraz ze zmianami lub przez dostęp do map i danych opisowych wg stanu na dany dzień/godzinę),

  • obsługę mechanizmu przeglądania zmian oraz wyświetlenia danych wg stanu na dany dzień, poprzez odpowiednie zapisy w bazie gwarantujące zachowanie stanu poprzedniego i możliwość prostego odtworzenia historii zmian obiektu (zarówno geometrii jak i danych opisowych) po dowolnej wykonanej zmianie,

  • przechowywanie pełnej historii obiektów np. przez każdorazowe kopiowanie całej geometrii i opisu, a nie tylko danych zmienionych;

  • brak limitu przechowywanej historii obiektów.

Grupę użytkowników korzystającą z jednej warstwy tematycznej (mającą prawa do jej edycji) będą tworzyć najczęściej przedstawiciele jednego, konkretnego Wydziału UMR, JM lub SP. Należy zrealizować jednak również możliwość stworzenia grupy użytkowników mającej prawo do danej warstwy tematycznej składającej się z przedstawicieli dwóch lub więcej powyższych instytucji (np. wspólne bazy tematyczne dla Wydziału Dróg oraz RSK, SM i KMP, czy dla Wydziału Zarządzania Kryzysowego i Ochrony Ludności


i PCZK). Dzięki temu będzie mógł być stworzony mechanizm swoistego "obiegu informacji przestrzennej" pomiędzy tymi użytkownikami.
Wykorzystując w/w możliwości aplikacja obsługi danych fakultatywnych ma zostać również wyposażona w mechanizmy systemu dyspozytorskiego (oferującego aktywną wymianę danych pomiędzy użytkownikami), polegające na wykorzystaniu jej jako miejsca składania zleceń na realizację różnorodnych zadań przez współpracujące ze sobą Wydziały UMR, JM i SP. Przykładem mogą być zlecenia remontów dróg składane przez Wydział Dróg do RSK wraz z zaznaczaniem lokalizacji uszkodzenia nawierzchni na tle ortofotomapy lub mapy zasadniczej.
W szczególności aplikacja obsługi danych fakultatywnych ma umożliwiać:

  • wprowadzanie danych mapowych/opisowych do danej warstwy przez dysponenta (właściciela warstwy tematycznej) i operatora innej instytucji (np. pracownika w PCZK przeglądającego zgłoszenie przyjęte przez pracownika KM PSP lub WSS),

  • obsługę zleceń, gdzie w dedykowanym formularzu danej warstwy tematycznej każda ze stron (zleceniodawca
    i zleceniobiorca) ma posiadać własne pola edycyjne, tak by umożliwić pełną obsługę danej procedury (np.: wystawienie zlecenia, określenie jego parametrów, przyjęcie zlecenia, wprowadzenie informacji o przebiegu realizacji, zamknięcie zlecenia),

  • obsługę alertów (komunikaty tekstowe na ekranie/maile) u dysponenta/operatora w przypadku wprowadzenia określonego zastawu danych przez operatora/dysponenta (np. Wydział Dróg wprowadza zlecenia na ustawienie znaku, RSK otrzymuje maila z odpowiednią informacją, po realizacji zadania aktualizuje dane w RSIP-ie, Wydział Dróg dostaje mailem potwierdzenie realizacji),

  • automatyczne wyświetlanie na mapie obiektu po wprowadzeniu dla niego danych,

  • wprowadzanie danych punktowych (z opisem) na instancji internetowej (zgłoszenia internautów),

  • wysyłanie mailem powiadomień (np. wysłanie maila do RSK z informacją o wstawieniu przez Wydział Dróg nowego zlecenia).

W celu zwiększenia efektywności wykorzystania aplikacji, ma ona zostać zintegrowana z system obiegu dokumentów DDM poprzez:



- pobieranie na żywo (transfer) z bazy DDM wybranych atrybutów z rejestrów prowadzonych w DDM-ie
i podłączanie ich do obiektów geometrycznych zdefiniowanych w rozbudowanym RSIP-ie;

- replikowanie danych z prowadzonych w UMR spraw i rejestrów do dedykowanego schematu bazy danych RSIP.


Rozwój i dostosowanie systemu DDM, w szczególności o funkcjonalności umożliwiające wprowadzanie informacji geokodujących prowadzone sprawy (np. numer działki ewidencyjnej, czy adres nieruchomości) realizowany będzie samodzielnie przez Zamawiającego w trybie i terminach umożliwiających Wykonawcy realizowanie wymaganych prac wdrożeniowych.
Poza dostarczeniem aplikacji do obsługi danych fakultatywnych Wykonawca ma zdefiniować
i uruchomić formularze wprowadzania wszystkich danych i warstwy fakultatywne zgodnie z opisem
w Załączniku IV do SIWZ, Tabela IV-A i Tabela IV-B
.

Szczególną uwagę należy zwrócić na warstwy fakultatywne tworzone na potrzeby:

- PCZK i SP (gromadzenie na żywo danych o zdarzeniach wymagających interwencji SP, w tym zgłaszanych na numery 112, 997, 998, 999),

- ZZM (ewidencja terenów zielonych wraz z obsługą trawników, małej architektury, drzewostanu, krzewów itp.),

- Wydziału Dróg, Wydziału Komunikacji i RSK (zlecanie prac w pasie drogi, opiniowanie tych prac, potwierdzenie ich wykonania).

Aplikacja lokalizacji pojazdów i patroli
Aplikacja ta przeznaczona będzie przede wszystkim do wspierania użytkowników w posługiwaniu się informacjami pochodzącymi z systemu lokalizacji GPS. Dotyczy to zarówno wyświetlania danych dotyczących lokalizacji oraz statusów i innych parametrów dla poszczególnych pojazdów lub patroli, ale również całej obsługi zgromadzonego zasobu informacyjnego, np.:


  • regulacja częstotliwości odświeżania danych lokalizacyjnych na mapie RSIP indywidualnie dla każdego wizualizowanego urządzenia (pokazywanie na mapie pomiaru lokalizacji z określonym krokiem) oraz dla każdego użytkownika systemu (np. odświerzanie z rzeczywistą częstotliwością pozyskiwania danych lokalizacyjnych tylko dla przedstawicieli PCZK i SP),

  • prezentowanie na mapie lokalizacji pojazdów i patroli w dowolnych układach: wszystkie obiekty lokalizowane, wszystkie obiekty z danej JM/SP, wszystkie obiekty według wskazanego atrybutu lub atrybutów (np. będące aktualnie w akcji lub mające awarię),

  • wyszukiwanie pojazdów/patroli według różnych parametrów (np.: autobusów w wybranym przedziale czasowym i o danej godzinie, pojazdów przyporządkowanych do jednego zadania, patroli oddalonych
    o zadaną odległość od miejsca zdarzenia),

  • generowanie raportów zbiorczych dla wszystkich lub wyselekcjonowanych lokalizowanych obiektów
    z uwzględnieniem wybranych parametrów,

  • analiza danych archiwanych i wykonywanie statystyk zbiorczych lub map tematycznych (np.: wyświetl lokalizację/trasę pojazdu o podanym typie i numerze w zadanym dniu oraz przedziale czasowym),

  • tworzenie raportów detalicznych odnoszących się do pojedyńczych zleceń lub akcji,

  • innych w zależności od potrzeby,

  • tworzenie mapek z historyczną lokalizacją wybranych pojazdów i ich stanami,

  • wyświetlanie na bieżących mapkach lokalizacyjnych dynamicznych etykiet (zawierających np.: współrzędne i status pojazdu).

Wśród parametrów branych pod uwagę w powyższych raportach mają być uwzględnione zarówno dane mierzone bezpośrednio (m.in.: współrzędne położenia, punkty w czasie, wartości statusów), jak i powstałe na ich bazie parametry wtórne (m.in.: obliczone odległości pomiędzy punktami przejazdu, sumaryczne długości tras, czasy realizacji zleceń, sumaryczne ilości pojazdów i patroli biorących udział w danej akcji, inne). Aplikacja ma zawierać w sobie istniejącą już obecnie funkcjonalność związaną z prezentacją danych


o pojazdach ZTZ, rozszerzoną o specyficzne potrzeby włączanych do systemu nowych użytkowników (JM i SP).
Aplikacja ma równoważnie obsługiwać zarówno dane z lokalizacji własnej (dostarczonej w ramach przetargu), jak i dane z systemów obcych (ZTZ – lokalizacja firmy Taran, RSK/ZZM – lokalizacja firmy Aksel, KMP – lokalizacja wykonana w ramach projektu SCH/06.01.01.02 realizowanego w ramach Instrumentu Finansowego Schengen).
Ze względu na dużą ilość danych lokalizacyjnych, które będą gromadzone w bazie, tabele/widoki
z lokalizacją należy odpowiednio zoptymalizować
(np. przez partycjonowanie tabeli, stosowanie tabel archiwalnych).
Aplikacja obsługi metadanych
Opisywana aplikacja ma umożliwiać kompleksową obsługę metadanych w zakresie ich tworzenia, edycji oraz publikacji. W zakresie tworzenia i edycji metadanych ma ona posiadać charakter edytora metadanych, tzn. narzędzia pozwalającego na przygotowanie zbioru metadanych w określonym, przyjętym w systemie RSIP standardzie. Zastosowany edytor metadanych ma zapewniać zgodność z obowiązującymi standardami geoinformacyjnymi, w tym publikowanymi przez OGC, odpowiednimi normami międzynarodowymi ISO (ich odpowiednikami CEN i PN) oraz zgodność z wymaganiami Dyrektywy EU INSPIRE oraz związanymi z nią odpowiednimi przepisami implementacyjnymi – Zasadami Wdrażania INSPIRE (IR – Implementing Rules). Ponadto konieczne jest zapewnienie zgodności z Ustawą o krajowej infrastrukturze informacji przestrzennej oraz związanymi z nią odpowiednimi Rozporządzeniami i Wytycznymi Technicznymi (które niebawem wejdą w życie).
Do szczegółowych wymagań wobec edytora metadanych należą między innymi:

  • pełna obsługa języka polskiego,

  • obsługa metadanych zgodnie z profilami metadanych: INSPIRE oraz polskim krajowym profilem metadanych w zakresie geoinformacji,

  • tworzenie i aktualizacja metadanych w określonej hierarchii oraz możliwości dziedziczenia elementów metadanych,

  • automatyczne generowanie identyfikatora pliku metadanych, zgodnie ze standardem UUID (Universal Unique Identifier), który jest specyfikowany przez IETF (http://www.ietf.org) oraz RFC 4122,

  • generowanie plików metadanych w języku XML zgodnie ze schematem implementacyjnym (XML Schema) określonym w standardzie ISO/TS19139:2007,

  • automatyczna konwersja wartości określających punkty w czasie (data, czas) do standardu GML (lub jego aplikacji), opisanego w dokumencie ISO/TS 19139:2007,

  • ułatwienie definiowania zasięgu przestrzennego opisywanych zasobów; w przypadku zdefiniowania informacji o zasięgu przestrzennym zasobu jako poligonu zapisanego w formie współrzędnych (x, y) wieloboku – automatyczną konwersję wartości określających te elementy (wieloboki) do standardu GML, opisanego w dokumencie ISO/TS 19139:2007.

Ze względu na znaczną różnorodność użytkowników systemu RSIP oczekujących dostępu do metadanych, w zakresie publikacji metadanych geoinformacyjnych zamiast katalogu metadanych od Wykonawcy wymaga się opracowania i implementacji dedykowanego interfejsu WWW. Interfejs ten współpracować powinien z repozytorium metadanych, które ma być umieszczone na serwerze RSIP, a dostęp do repozytorium odbywać się ma w technologii klient-serwer.

Interfejs dostępu do metadanych uwzględniać ma dwie zasadnicze grupy użytkowników:


  • użytkowników zarejestrowanych - posiadających dostęp pełnego zbioru metadanych, jednak dopiero po poprawnym zalogowaniu i zawierający m.in. następujące funkcjonalności:

    • wyszukiwanie metadanych po dowolnym ciągu znaków alfanumerycznych w ramach całej bazy metadanych,

    • możliwość wygenerowania mapy z wyszukanymi za pomocą metadanych danymi przestrzennymi - integracja z podsystemem publikacji danych (uwzględniając jednak obowiązujące użytkowników
      i zdefiniowane w systemie prawa dostępu),

    • opcjonalnie tworzenie i edycję metadanych (chyba, że w tym celu zastosowany będzie oddzielny interfejs obsługi),

  • użytkowników niezarejestrowanych (publicznych) - mających swobodny dostęp do metadanych, ale
    w ograniczonym zakresie i zawierający m.in. następujące funkcjonalności:

    • przeglądaniem dostępnych metadanych dla poszczególnych warstw tematycznych w określonym profilu metadanych,

    • wyświetlanie w oknie mapy danych przestrzennych (podgląd jednej warstwy tematycznej) wyszukanych za pomocą metadanych - integracja z podsystemem publikacji danych,

    • składaniem zapytania o metadane do administratora RSIP, na przykład poprzez wysłanie e-maila.

Interfejs dostępu do metadanych, w szczególności dla użytkowników publicznych, powinien być zintegrowany


z podsystemem publikacji danych, na przykład poprzez możliwość przechodzenia pomiędzy tymi komponentami systemu. W systemie powinna także istnieć możliwość stałego monitorowania zakresu i częstotliwości korzystania z metadanych przez poszczególnych użytkowników (np. w postaci logów zapisywanych w bazie RSIP).
Aplikacja analiz przestrzennych i sieciowych
Opisywana aplikacja będzie miała za zadanie przede wszystkim wspierać użytkowników w wykonywaniu analiz dotyczących obiektów przestrzennych, to znaczy posiadających geometrię lub dane, które można powiązać z geometrią (np. dane PESEL można powiązać z geometrią przez adres). Ze względu na poziom złożoności wykonywanych operacji oraz rodzaj i zakres stosowanych kryteriów, opisywana aplikacja ma realizować dwa rodzaje analiz:

  • proste analizy o charakterze wyszukiwania i wyboru obiektów przestrzennych, w tym:

    • mechanizmy łatwej i różnorodnej selekcji obiektów jednej lub wielu warstw tematycznych jednocześnie (ręcznie, pod wskazanym obszarem oraz za pomocą narzędzi analitycznych - przez nakładanie kryteriów na atrybuty opisowe),

    • selekcja wielu obiektów poprzez wskazywanie myszką, selecja prostokątem/okręgiem/wielobokiem,

    • możliwość ponownego, zawężającego wyboru obiektów spośród wyników poprzedniej selekcji,
      w tym także przy ograniczeniu do jednej, wybranej warstwy tematycznej,

    • mechanizm odwrócenia wyniku selekcji (wybierz wszystkie te obiekty, które nie zostały wybrane podczas ostatniej selekcji), w tym także przy ograniczeniu do jednej, wybranej warstwy tematycznej,

    • możliwość szybkiego uzyskiwania informacji na temat wyszukanych obiektów (ich parametrów geometrycznych i atrybutów opisowych oraz dostęp do podglądu dodatkowych załączników związanych
      z obiektem, na przykład zeskanowanych aktów notarialnych, zdjęć nieruchomości, etc.),

    • narzędzia wykonywania różnorodnych pomiarów na mapie (odległości, długości, powierzchni danego obiektu, powierzchnię wyznaczoną przez użytkownika, możliwość dociągania pomiarów do istniejących punktów/linii),

    • możliwość łatwego wykonywania podstawowych analiz przestrzennych opartych na operatorach logicznych (np.: równy, mniejszy, większy, nierówny, ich kombinacje) na jednej lub wielu warstwach tematycznych jednocześnie, w tym także poprzez zastosowanie kryteriów geometrycznych obiektów (powierzchni, długości),

    • wyszukiwanie obiektu spełniającego określone kryteria i znajdującego się najbliżej wskazanego punktu (także poprzez określenie współrzędnych jego położenia),

    • mechanizm wyszukiwania obszarów dopasowanych do wyniku analizy/selekcji (np.: prostokąta, wielokąta, okręgu); przykład - znajdź działkę, na której zmieści się wskazany budynek),

  • zaawansowane analizy przestrzenne i sieciowe, w tym np.:

    • mechanizm realizacji analiz dostępnych w Oracle Spatial (realizacja na poziomie bazy danych lub przez serwer mapowy):

  • wybierz obiekty spełniające relacje: "A jest w obszarze B", "A styka się krawędzią z B", "A zawiera B", "A i B mają część wspólną", "A i B stykają się" (brak zawierania się w sobie), "A jest równe B" (powierzchniowo i geometrycznie, nie pod kątem lokalizacji), "zachodzi dowolna interakcja pomiędzy A i B", "brak interakcji pomiędzy A i B" (np. zaznacz budynki, które nie zawierają adresów, pokaż działki, przez które przechodzi projektowana kanalizacja),

  • zaznacz obszary/obiekty spełniające warunki: "A przecina B", "część wspólna A i B", "różnica A
    i B", "suma A i B" (np. zaznacz obszary m.p.z.p. nachodzące na siebie),

  • zaznacz bufor w odległości X od obiektu,

  • obiekty zawarte wewnątrz wybranych (np.: wybierz punkty adresowe zawarte w zaznaczonych budynkach),

  • obiekty zawierające obiekty wybrane (np.: wybierz działki zawierające wskazaną linię uzbrojenia technicznego),

  • obiekty w danej odległości (np.: zaznacz wszystkie budynki w odległości 1000 m od miejsca wypadku),

  • stwórz prostokąt zawierający wszystkie wybrane obiekty,

  • stwórz „dopasowaną” powierzchnię zawierającą wszystkie wybrane obiekty,

  • wyznacz centroidę wybranego obiektu/obszaru,

    • mechanizm budowania i wykorzystywania buforów do wykonywania analiz przestrzennych (w tym także możliwość wykorzystania wyselekcjonowanych w ten sposób obiektów do dalszej analizy, dotyczy obiektów punktowych, liniowych i powierzchniowych),

    • możliwość realizacji zaawansowanych i specyficznych analiz przestrzennych na wielu rodzajach danych jednocześnie (przestrzennych i opisowych) oraz pochodzących z różnych źródeł (np.: wyszukaj wszystkie wydane pozwolenia na zajęcie pasa drogowego przy ulicach, które mają długość powyżej
      1 km, albo wybierz wszystkie działki posiadające powierzchnię większą niż powierzchnia wskazanego obiektu), także dzięki wspieraniu procesów integracji danych według różnorodnych kluczy (np.: nazwa ulicy, adres, numer działki ewidencyjnej),

    • mechanizm stosowania relacji przestrzennych do wykonywania analiz i wyszukiwania obiektów (np.: zawierania, przecinania, części wspólnej, stykania się krawędzią, równości/podobieństwa geometrycznego, inne),

    • mechanizm odwrócenia wyniku analizy opartej na relacjach przestrzennych (np.: wyszukaj działki przecięte przez kanalizację, a następnie pokaż działki bez kanalizacji - zaneguj wynik),

    • mechanizm stosowania do analiz przestrzennych topologii obiektów oraz zależności sieciowych (np.: wyszukiwanie optymalnych tras przejazdu lub najkrótszej drogi pomiędzy punktami na obszarze miasta, wykorzystując wszystkie dostępne w systemie informacje - sieć ulic, komunikacja zbiorowa, ograniczenia w ruchu, drogi jednokierunkowe),

    • możliwość ponowienia analizy sieciowej przy wykluczeniu uzyskanego uprzednio wyniku (np.: znajdź następną - drugą w kolejności - najkrótszą drogę, inną niż ostatnio wyszukana),

    • mechanizm wyliczania kilometrażu w oparciu o wyselekcjonowane obiekty lub zapisane dane lokalizacyjne (np.: policz łączną długość wyszukanych sieci, czy oblicz sumaryczną długość trasy pokonanej przez wóz strażacki podczas realizacji konkretnej akcji ratowniczej),

    • zalecana możliwość prezentacji danych lokalizacyjnych zarówno w postaci wykazów współrzędnych (punktów pozyskanych z systemu lokalizacji GPS), jak i odcinków tras (kilometrażu),

    • generowanie na żywo map tematycznych na podstawie analiz (także statystycznych) atrybutów opisowych obiektów przestrzennych (np.: rozkład gęstości zaludnienia lub wieku mieszkańców miasta
      w oparciu o dane dotyczące zameldowanych osób pod konkretnymi adresami),

    • zalecana możliwość prezentacji wyników analiz (także statystycznych) atrybutów opisowych w postaci wykresów i zestawień w kontekście mapy (na jej tle),

    • możliwość prezentacji wyników analiz (także statystycznych) w postaci raportów, np. w postaci wykresów kołowych, słupkowych, liniowych, itp.. w kontekście mapy (na jej tle),

Oferowane rozwiązanie ma zapewnić możliwość stosowania analiz prostych i złożonych do dowolnych warstw danych, a nie tylko do kilku wybranych.



Nie może być limitów na ilość analizowanych danych. Zamawiający wymaga sprawnego działania aplikacji
w różnych skalach, w tym na poziomie dzielnic (np. pokaż w dzielnicy X działki, które nie są zdefiniowane
w systemie podatkowym) czy nawet całego miasta (np. zaznacz w m.p.z.p. obszary o przeznaczeniu MN do których nie dochodzi wodociąg).
Formularze analiz powinny być generowane automatycznie na podstawie danych opisowych danej warstwy i uprawnień użytkownika.
Aplikacja analiz przestrzennych i sieciowych ma również umożliwiać wyświetlanie wyniku w postaci formularza HTML oraz wydrukowanie wywołanej mapy lub jej fragmentu wraz z raportem zawierającym listę wyselekcjonowanych w ramach analizy przestrzennej obiektów wraz z ich atrybutami opisowymi. Drukowanie ma być możliwe w skali dobranej automatycznie przez system (w zależności od wybranego formatu papieru), jak i w skali wskazanej przez użytkownika.
Zaleca się, żeby aplikacja analiz przestrzennych i sieciowych wykorzystywała w miarę możliwości bogaty zestaw funkcji analitycznych i wyszukujących dostępnych w Oracle Spatial.
Wymagane jest, aby w stosunku do wszystkich analiz możliwa była ich realizacja na wielu tabelach/mapach/warstwach jednocześnie (np.: znajdź wszystkie działki ewidencyjne, których właścicielem jest Miasto Rybnik, powierzchnia jest nie mniejsza niż 1 ha oraz leżące w obszarze określonego m.p.z.p.).
Operacje wykonywania analiz mają być zapisywane w logu systemu (w tym informacja kto i kiedy wywołał analizę, jaka to była analiza i jakie były założone kryteria jej działania).
Pełna funkcjonalność analityczna systemu dostępna ma być z poziomu środowiska okna mapy, jako interfejsu dostępu użytkownika zaimplementowanego w standardowej przeglądarce WWW.
System pozwalać ma na detaliczne przyznawanie użytkownikom uprawnień do poszczególnych narzędzi opisywanej aplikacji.

Aplikacja wyszukiwania i raportowania
Aplikacja wyszukiwania i raportowania stanowić ma zbiór dedykowanych narzędzi informatycznych umożliwiających sprawne poruszanie się po zasobach systemu RSIP w zakresie danych opisowych lub opisowych atrybutów obiektów przestrzennych. Dotyczy to w szczególności obiektów nie posiadających reprezentacji graficznej (geometrii), na przykład obiektów bazy PESEL, czy informacji z systemu DDM.
Wyszukiwanie obiektów ma następować w dwóch zasadniczych trybach: proste poprzez automatycznie tworzone formatki (format XML/XSL, XForms lub równoważny) oraz zaawansowane poprzez zdefiniowane przez administratora formatki mające charakter graficznego SQL-a i umożliwiające budowanie złożonych zapytań do bazy danych poprzez wybór atrybutów podlegających analizie oraz ograniczających je parametrów.
System ma umożliwiać dowolne formatowanie okienek narzędzi wyszukiwania/raportowania w zakresie rozmieszczenia pól i ich opisów, typu używanych czcionek, itp. za pomocą dostarczonego przez Wykonawcę generatora graficznego.
Forma i dostępny zakres analizowanych atrybutów ma być adekwatny do wybranej do analizy grupy obiektów (np.: z tabeli osób zameldowanych w mieście, czy spośród obiektów wybranej warstwy tematycznej) oraz ich typu (dane tylko opisowe, dane graficzno-opisowe). W przypadku, gdy jakaś grupa obiektów posiada relację do innej grupy, aplikacja ma umożliwiać wyszukiwanie obiektów również poprzez wykorzystanie tej relacji.
W formatkach wyszukiwania prostego użytkownik musi mieć możliwość wykonywania następujących czynności (w zależności od uprawnień):

  • przeglądanie wyniku,

  • sortowanie po dowolnym polu,

  • grupowania po dowolnej wartości,

  • wprowadzanie dodatkowych warunków filtrujących przeglądany wynik,

  • przechodzenie do wybranych obiektów na mapie,

  • możliwość wyboru jednego bądź wielu pozycji z wyniku wyszukiwania/filtrowania,

  • przechodzenia do edycji wybranego atrybutu opisowego obiektu w aplikacji obsługi danych fakultatywnych,

  • bezpośrednie wyświetlanie dowolnych zdefiniowanych raportów dla wybranych pozycji z wyniku wyszukiwania/filtrowania - bez konieczności przechodzenia do mapy,

  • wydrukowania wyniku wyszukiwania/filtrowania,

  • wyszukiwanie szybkie – po podstawowych polach opisowych (administrator ma mieć możliwość zdefiniowania tych pól dla każdej warstwy oddzielnie),

  • wyszukiwanie pełne – po wszystkich możliwych polach,

  • możliwość stosowania jednolitego znaku zastępującego dowolną część zawartości pola (znak “*”),

  • domyślne wyszukiwanie danych warunkiem LIKE, bez względu na wielkość liter,

  • pokazywanie (zbliżanie do) wyszukanego obiektu/obiektów na mapie,

  • po selekcji wskazanych obiektów z listy wynikowej wyszukiwania obiekty te mają się podświetlić na mapie, ma nastąpić zbliżenie do nich, jeżeli wcześniej nie była załączona warstwa z danymi – ma się załączyć dana warstwa, jeżeli dany obiekt składa się z kilku elementów graficznych, na mapie należy zaznaczyć/podświetlić wszystkie (np. jedna ulica może składać z kilku odcinków poprzecinanych rondami),

  • formatka musi się automatycznie dostosować do przeszukiwanej warstwy/zakresu danych, tj. zaktualizować rozmiar/rozmieszczenie pól itp.,

  • dane opisowe bez geometrii mają być oznaczane na liście wynikowej (np. kolorem lub symbolem; dotyczy np. słowników, niezależnych danych opisowych),

  • dane geometryczne bez opisów mają być oznaczane na liście wynikowej (np. kolorem lub symbolem; dotyczy np. punktów adresowych które mają zdefiniowaną geometrię, ale nie mają podłączonej ulicy i nr domu),

  • rozróżnienie na liście wynikowej danych przestrzennych i opisowych,

  • przełączanie listy wynikowej z widoku tabeli na widok formularza,

  • możliwość definiowania niezależnych list wyszukiwania (np. lista ulic, lista urzędów, lista szkół; po wybraniu elementu z listy ma on być zlokalizowany na mapie),

  • możliwość definiowania oddzielnego zestaw pól wyszukiwania/wynikowych dla każdej grupy użytkowników oddzielnie.


W formatkach wyszukiwania zaawansowanego użytkownik musi dodatkowo mieć możliwość
(w zależności od uprawnień):


  • zadawania zapytań SQL za pomocą “kreatora zapytań SQL”,

  • stosowania listy wyboru dla: warunków, źródeł danych, pól danych,

  • tworzenia zapytań złożonych z wielu warunków typu "where",

  • możliwość zadawania zapytania do wielu warstw tematycznych jednocześnie (w tym: wyszukiwanie obiektów w ramach jednej warstwy poprzez odwołanie się do informacji zawartych na innej warstwie lub w innej bazie danych, przeszukiwanie danych opisowych wskazanych warstw w poszukiwaniu zadanej frazy),

  • “ręcznego” pisania zapytania/warunku typu "where".

Wykonawca ma w pełni wdrożyć (w tym nadać uprawnienia użytkownikom) narzędzia do wyszukiwania,


w wyniku czego użytkownik ma mieć możliwość wyszukiwania prostego i zaawansowanego dla każdej zdefiniowanej warstwy i każdego zdefiniowanego źródła danych (w zależności od nadanych uprawnień).

Wykonawca ma także zdefiniować listy wyszukiwania dla maksymalnie 50 warstw.

Niezależnie Zamawiający ma mieć możliwość samodzielnego zarządzania/rozwoju/modyfikacji systemu wyszukiwania przez dodawanie nowych warstw i odpowiednie ustawiane dla nich parametrów wyszukiwania.
Wymagana jest możliwość generowania dwóch rodzajów raportów:


  • prostych zestawień tabelarycznych w postaci tabel/formularzy HTML,

  • zaawansowanych wielostronicowych raportów zawierających zagnieżdżone tabele z rozwijanymi szczegółowymi atrybutami obiektów (dopuszcza się możliwość wykorzystania zewnętrznego oprogramowania specjalistycznego, np. typu Crystal Reports - Zamawiający użytkuje już to oprogramowanie w innych systemach, nie posiada jednak wolnych licencji).

Zamawiający wymaga, aby za pomocą dostarczonych narzędzi była możliwość zdefiniowania raportów
o takim stopniu złożoności jak „białe i żółte karty zabytków” czy też „karty pomników przyrody” (raporty wielostronicowe z wykorzystaniem zdjęć, z dokładnie zdefiniowanym rozkładem pól danych itp.).
Prawa do poszczególnych raportów mają być definiowane oddzielnie.
W zakresie raportów zaawansowanych Wykonawca ma zaproponować i dostarczyć wyżej wymienione oprogramowanie specjalistyczne w wersji i z licencją umożliwiającą realizację co najmniej 25 jednoczesnych zapytań od różnych użytkowników łącznie (dla Intranetu - 10, Ekstranetu- 10, Internetu - 5) oraz wykonać jego instalację, konfigurację i integrację z systemem RSIP.
Wszystkie narzędzia wyszukiwania i raportów muszą być definiowalne przez administratora (raporty proste w zakresie danych, a zaawansowane w zakresie danych i wyglądu), w tym w zakresie praw dostępu do nich przez poszczególnych użytkowników oraz z możliwością tworzenia nowych raportów.

Dlatego też konfiguracja zarówno formatek wyszukiwania jak i definicje samych raportów zapisane powinny być


w ramach konfiguracji systemu RSIP (podsystemu administracji, ewentualnie w dedykowanym module zarządzania raportami).
Opracowane przez Wykonawcę narzędzia wyszukiwania i raportowania mają być jednolite dla całego systemu RSIP, bez względu na rodzaj i format analizowanych danych, rodzaj użytkowników, źródło pochodzenia danych.
Niedopuszczalne jest, aby końcowe nazwy/definicje formatek były zaszyte (wkompilowane) w kod aplikacji/systemu.
System ma generować raporty zarówno dla pojedynczych jak i wielu wybranych obiektów (w procesie wyszukiwania lub selekcji na mapie) oraz ma umożliwiać wyszukiwanie i raportowanie dowolnej liczby obiektów (np. raport demograficzny dla danej dzielnicy z rozbiciem na punkty adresowe, raport działek będących własnością Skarbu Państwa z całego miasta) z dowolnej ilości warstw tematycznych.
W raportach mogą występować zarówno dane pochodzące bezpośrednio z tabel opisowych jak i dane wstępnie przetworzone przy generowaniu raportu (np. powierzchnia działki obliczana „w locie”).
Zamawiający traktuje wydruki mapy jako formę raportu.
Wyniki raportów/wydruków mają być prezentowane w poniższy sposób (w zależności od nadanych praw):

  • przeglądania na ekranie,

  • drukowanie,

  • zapisywanie do pliku (eksport) do wybranych formatów (Microsoft Word, Microsoft Excel, PDF).

Zaleca się także, aby możliwe było przy wydruku przeformatowanie mapy wyświetlonej, np.: ze skali ekranowej 1:100 000 na drukowane arkusze w skali 1:1000.


Dane do drukarki mają być wysyłane w rozdzielczości umożliwiającej wyraźny, czytelny wydruk (dotyczy zarówno danych opisowych, mapowych jak i rastrowych).
Operacje wywoływania narzędzi wyszukiwania i raportowania mają być zapisywane w logu systemu
(w tym informacja, kto i kiedy wywołał narzędzie wyszukiwania, jakie to było narzędzie i jakie były założone kryteria jego działania).
Wywołanie narzędzi wyszukiwania i raportowania ma być także możliwe z poziomu interfejsu dostępu użytkownika do okna mapy w oparciu o dokonaną tam selekcję obiektów narzędziami obsługi mapy.
Niezależnie od raportów opartych na wyszukanych danych, aplikacja ma zawierać również narzędzia do generowania predefiniowanych statystyk, dedykowanych poszczególnym grupom użytkowników (Wydziałom UMR, JM i SP).
Znaczna różnorodność użytkowników systemu RSIP wymaga, aby istniała możliwość detalicznego przydzielania dla każdego z nich uprawnień do poszczególnych narzędzi aplikacji wyszukiwania
i raportowania oddzielnie
.
Aplikacja ma być wyposażona w narzędzia konfiguracyjne, umożliwiające administratorom definiowanie oraz elastyczną zmianę struktury i zakresu formatek wyszukiwania oraz raportów, ich rozszerzanie o nowe parametry oraz dodawanie nowych, wraz z pojawiającymi się nowymi potrzebami użytkowników oraz nowymi danymi w RSIP.

Zamawiający ma mieć możliwość dowolnego zarządzania/modyfikacji i rozbudowy zakresu i ilości raportów samodzielnie bez konieczności pośrednictwa Wykonawcy lub osób/firm trzecich.
W zakresie realizacji wydruków/raportów podsystem ma posiadać następujące funkcjonalności:

  • na każdym raporcie/wydruku wygenerowanym w Intranecie i Ekstranecie mają być umieszczone:

    • mapa widoczna w oknie mapy przeglądarki/treść raportu,

    • znak wodny,

    • pełna data i godzina wydruku,

    • użytkownik generujący wydruk/raport,

    • automatyczny identyfikator wydruku/raportu,

    • legenda (opcjonalnie, na żądanie użytkownika),

    • skala liniowa (opcjonalnie, na żądanie użytkownika),

    • współrzędne (opcjonalnie, na żądanie użytkownika),

    • kierunek N (opcjonalnie, na żądanie użytkownika),

    • tytuł definiowany przez użytkownika (opcjonalnie, na żądanie użytkownika),

  • na każdym raporcie/wydruku wygenerowanym w Internecie mają być umieszczone:

    • mapa widoczna w oknie mapy przeglądarki/treść raportu,

    • znak wodny,

    • data i godzina wydruku,

    • automatyczny identyfikator wydruku,

    • legenda (opcjonalnie, na żądanie użytkownika),

    • kierunek N (opcjonalnie, na żądanie użytkownika),

    • tytuł definiowany przez użytkownika (opcjonalnie, na żądanie użytkownika),

  • znak wodny ma być automatycznie drukowany na każdym raporcie/wydruku pochodzącym z systemu, niezależnie od zastosowanej drukarki (laserowa, atramentowa),

  • użytkownik nie może usunąć znaku wodnego,

  • każdy raport/wydruk ma być automatycznie ewidencjonowany (ma mieć swój jednoznaczny identyfikator, który będzie rozróżnialny dla interfejsu użytkowników Intranetu/Extranetu/Internetu),

  • operacje generowania raportu/wydruku mają być zapisywane w logu systemu (w tym informacja kto
    i kiedy wywołał raport/wydruk, rodzaj raportu/wydruku, jaki był obszar wydruku - poprzez współrzędne naroży, zakres danych opisowych, lista drukowanych warstw, identyfikator wydruku);

  • zasadnicza treść wydruku (tabela z danymi z raportu, mapa) maj zajmować możliwie największą część kartki wydruku,

  • wydruki mapy wykonywane w Internecie mają być bez zachowania skali,

  • wydruki mapy w Intranecie i Ekstranecie mają być z/lub bez skali – według praw i potrzeb użytkownika.

Poza dostarczeniem aplikacji do raportowania Wykonawca ma opracować i wdrożyć (wraz


z konfiguracją i nadaniem praw użytkownikom)
:

- standardowe raporty proste dla danych mapowych/opisowych z każdej zdefiniowanej w systemie warstwy mapowej;

- standardowe raporty wydruku mapy (plan miasta na stronach internetowych, mapa dla UMR, mapa dla JM, mapa dla SP);

- zaawansowane raporty na potrzeby Wydziału Architektury UMR;

- zaawansowane raporty na potrzeby Wydziału Ekologii;

- zaawansowane raporty na potrzeby Miejskiego Konserwatora Zabytków;

- indywidualne raporty zaawansowane dla max. 2,5% zdefiniowanych w systemie warstw mapowych;

- raporty administracyjne: max. 10 prostych i 5 zaawansowanch.


Wytyczne do zaawansowanych raportów na potrzeby Wydziału Architektury:

- wyrys w skali z MPZP dla działki/działek:

Wydruk – poza standardowymi elementami raportu - ma zawierać wydruk działki/działek skali, w jakiej został opracowany dany plan zagospodarowania. Wydruk ma także obejmować strefę wokół zaznaczonej działki/dziełek o określanej przez użytkownika szerokości. Na wydruku mają być widoczne: działki, numery działek, budynki, osie drogi z nazwami, punkty adresowe, właściwy MPZP;



- przeznaczenie działki w MPZP:

Wydruk ma zawierać – poza standardowymi elementami raportu – fragmenty tekstu uchwały dla danego MPZP odnoszącego się do zaznaczonej działki/działek oraz fragmenty tekstu uchwały mające znaczenie ogólne; przed wygenerowaniem wydruku użytkownik ma otrzymać zestawienie pośrednie z listą wszystkich przeznaczeń dla danej działki; użytkownik ma mieć możliwość wyłączenia wybranych przez siebie przeznaczeń z końcowego raportu/wydruku;

- raporty opisujące przeznaczenie w MPZP muszą uwzględniać wszystkie MPZP posiadane przez Zamawiającego oraz umożliwić w przyszłości dodawanie nowych;

- na dzień dzisiejszy Zamawiający posiada 20 planów, a do końca 2010 planuje się zatwierdzić kolejne 26;

- Zamawiający wymaga, aby analiza tekstów uchwał w zakresie wytycznych dla poszczególnych przeznaczeń terenu była realizowana w tabelach zawierających wiersze z polami typu nazwa_planu, przeznaczenie_w_planie, fragment_ tekstu_uchwały_dla danego_przeznaczenia.

- Zamawiający wymaga, aby zastosowany sposób generowania w/w raportów umożliwiał bezproblemowe dodawanie nowych planów i weryfikację/korektę wcześniejszych ustawień.



Wytyczne do zaawansowanych raportów na potrzeby Wydziału Ekologii:

- karta ewidencyjna pomnika przyrody ożywionej:

Karta ma zawierać następujące dane: tytuł, nazwę polską/łacińską, obwód, wysokość, położenie geograficzne, przynależność administracyjną, dokładną lokalizację, właściciela posesji, zarządcę posesji, charakterystykę pni, charakterystykę korony, wymagane zabiegi konserwatorskie, datę pomiaru, dane dendrologa.

Karta ma mieć postać wydruku na formacie A4 (układ pionowy).
Wytyczne do zaawansowanych raportów na potrzeby Miejskiego Konserwatora Zabytków:

- karta ewidencyjna zabytku oraz skrócona karta ewidencyjna zabytku:

Karty mają mieć zawartość i wygląd Zgodnie z Rozporządzeniem Ministra Kultury z dnia 14 maja 2004 r.


w sprawie prowadzenia rejestru zabytków, Dz. U. Z dnia 02 czerwca 2004 r., nr 124, poz. 1305.

Nie może być limitów na ilość przeszukiwanych/raportowanych danych. Zamawiający wymaga sprawnego działania aplikacji w różnych skalach, w tym na poziomie dzielnic (np. wyszukaj w dzielnicy X działki, które nie są zdefiniowane w systemie podatkowym) czy nawet całego miasta (np. wyświetl listę budynków mieszkalnych, które stoją poza strefami MN zdefiniowanymi w m.p.z.p.).
Szczegółowy układ i zawartość poszczególnych raportów będzie określana na etapie Projektu technicznego wdrożenia.


Aplikacja portal edukacyjny (e-Learning)
Portal edukacyjny ma być miejscem umożliwiającym wszystkim użytkownikom systemu stały trening praktycznych umiejętności posługiwania się RSIP oraz dostęp do banku wiedzy o systemie. Nie będzie więc stanowił on aplikacji merytorycznej RSIP sensu "stricto".

Portal może mieć charakter na przykład rozbudowanego, interaktywnego systemu pomocy lub interaktywnego kursu posługiwania się systemem, uzupełniony o mechanizmy autotestów, jako narzędzi stałego podnoszenia swojej sprawności w posługiwaniu się systemem.



Wykonawca ma przygotować dwie wersje zawartości portalu edukacyjnego:

  • pełną, dedykowaną użytkownikom zarejestrowanym (z UMR, JM i SP) i opracowaną tylko w języku polskim i zawierającą:

    • materiały kursowe uwzględniające wszystkie dostępne w systemie grupy funkcjonalności użytkowych (w tym m.in.: wyszukiwanie zaawansowane, zaawansowane raportowanie, obsługa metadanych, obsługa edycji danych, dostosowywanie systemu do swoich potrzeb, wyszukiwanie SQL wraz z podstawowymi informacjami na temat zawartości bazy danych systemu),

    • testy sprawdzające wiedzę oraz umiejętności posługiwania się tymi grupami funkcjonalności systemu,

    • zindywidualizowaną postać testów dla różnych grup użytkowników (pracownicy, kadra kierownicza, administratorzy i technicy),

    • elektroniczną wersję dokumentacji systemu (instrukcja obsługi systemu odpowiadająca przekazanej
      w formie papierowej wraz z systemem) podzieloną na działy (dedykowane różnym rodzajom użytkowników i różnym stopniom zaawansowania materiału) oraz wyświetlaną w oknie przeglądarki WWW,

  • uproszczoną, dedykowanym użytkownikom publicznym i opracowaną zarówno w języku polskim,
    jak i w języku angielskim
    (z możliwością dodawania w przyszłości kolejnych wersji) i zawierającą:

    • materiały kursowe dotyczące podstawowych zasad oraz sposobów korzystania z ogólnodostępnej (publicznej) części RSIP (w tym m.in.: zawartość systemu, poruszanie się w systemie, nawigacja na mapie, proste wyszukiwanie, proste raporty, podstawowa obsługa metadanych),

    • jeden zbiorczy test sprawdzający wiedzę na temat RSIP i umiejętności posługiwania się nim,

Ma być możliwość tworzenia i dodawania samodzielnie przez Zamawiającego kolejnych wersji językowych.

Ma być możliwość tworzenia i uzupełniania/aktualizacji samodzielnie przez Zamawiającego nowych materiałów szkoleniowych/edukacyjnych.
Kurs powinien obejmować:

  • zapoznanie użytkownika z daną funkcjonalnością (materiał teoretyczny oraz animowana demonstracja działania systemu, jeżeli wymaga tego temat lekcji),

  • pytania testowe sprawdzające pozyskaną wiedzę,

  • prezentację wyniku testu (podanie uzyskanej punktacji oraz pytań, na które zostały udzielone błędne odpowiedzi).


W przypadku nie zaliczenia kursu, użytkownik ma mieć możliwość cofnięcia się do dowolnej lekcji z danego kursu i powtórzenia w całości testów.

Użytkownik ma mieć także możliwość samodzielnego wyboru kursu, z jakim chce się zapoznać.


Portal edukacyjny ma być obsługiwany przez przeglądarkę internetową i wywoływany z podsystemu publikacji danych. Ma on być zintegrowany z systemem logowania (dot. użytkowników zarejestrowanych) oraz zapisywać statystyki z postępów nauki poszczególnych użytkowników (w tym: kto i kiedy przechodził danych kurs, kiedy rozwiązywał testy i ile zdobył w nich punktów, kiedy zaliczył/zdawał poszczególne testy).




Pobieranie 3.6 Mb.

Share with your friends:
1   ...   5   6   7   8   9   10   11   12   ...   22




©operacji.org 2020
wyślij wiadomość

    Strona główna