str.52-88 - BIP Urząd Miasta Ruda Śląska

Transkrypt

Projekt „Budowa Publicznego Systemu Informacji Przestrzennej Miasta Ruda Śląska”
Załącznik nr 6
„Przegląd technologii – komponentów”
wyłącznie
na potrzeby określenia typu składowych produktów i
ich orientacyjnego, adekwatnego poziomu kosztów
zakupu (produktu lub usługi) celem przeprowadzenia
analizy technicznej
Projekt „Budowa Publicznego Systemu Informacji
Przestrzennej Miasta Ruda Śląska”
Lipiec, sierpień 2009 rok
(wersja 2008 po aktualizacji)
52
1 Koncepcja systemu
1.1 Wizja systemu
Publiczny System Informacji Przestrzennej Miasta Ruda Śląska (PSIP) jako system
informatyczny Urzędu Miasta Ruda Śląska stanowić będzie część systemu
informacyjnego Miasta Ruda Śląska.
Zadaniem systemu PSIP będzie wspomaganie realizacji zadań
prowadzonych przez Urząd Miasta w zakresie gospodarki przestrzennej.
Miasta
Zakres funkcjonalny systemu będzie pokrywał w maksymalnie możliwym stopniu
odpowiednio zakresy zadań i kompetencji Miasta.
Kluczowym zadaniem systemu będzie dostarczenie technologicznego wsparcia dla
realizacji administracyjnych procesów decyzyjnych i planistycznych1 między
innymi przez gromadzenie i przetwarzanie danych przestrzennych i opisowych
związanych z gospodarką przestrzenną miasta.
1.2 Cele i zakres systemu
Na podstawie zidentyfikowanych uwarunkowań otoczenia projektu określono dla
Publicznego Systemu Informacji Przestrzennej Miasta Ruda Śląska (PSIP)
następujące cele operacyjne:
•
wspomaganie procesu planowania przestrzennego,
•
wspomaganie procesów decyzyjnych,
•
wspomaganie procesów inwestycyjnych,
•
wspomaganie systemu budżetowego gminy,
•
umożliwienie racjonalnej gospodarki mieniem komunalnym,
•
usprawnienie obsługi interesantów,
•
wspomaganie pozostałych zadań gminy (urzędu gminy) związanych z
zarządzaniem lub lokalizowaniem obiektów, zdarzeń, czynności w obszarze
administracyjnym gminy.
Powyższe cele operacyjne definiują zasadniczy zakres funkcjonalny systemu PSIP.
1 Zakres funkcji systemu w odniesieniu do zadań zawierać będzie tzw. „Macierz zadań - modułów - i
funkcji” będąca ostatecznie przedmiotem prac Wykonawcy systemu a zawarta w Projekcie
Organizacyjno – Technicznym PSIP (POT)
53
1.3 Założenia koncepcji (wybrana opcja)
„Technicznym” zadaniem PSIP będzie gromadzenie, zarządzanie, przetwarzanie i
udostępnianie2 „informacji przestrzennej” dla wszystkich uprawnionych do tego
użytkowników systemu. Celem właściwej kategoryzacji funkcji dostępu do danych
wyróżnione zostaną dwie grupy użytkowników tj.:
•
użytkowników wewnętrznych, która stanowią pracownicy urzędu,
pracownicy jednostek organizacyjnych Miasta objętych zakresem
wdrożenia systemu oraz opcjonalnie inne uprawnione podmioty, jednostki
organizacyjne i osoby fizyczne, którym dostęp taki został formalnie
udostępniony,
•
użytkowników zewnętrznych, na którą składają się wszyscy spoza
pierwszej grupy użytkowników wewnętrznych, czyli osoby prawne
(instytucje i podmioty gospodarcze) i osoby fizyczne, a w szczególności
mieszkańcy Miasta.
Każda z ww. grup będzie posiadała odpowiednią hierarchię uprawnień, która
będzie przekładać się na perspektywę udostępnionych dla nich funkcji oraz danych.
Podstawą do budowy systemu będą dane baz danych Krajowego Systemu
Informacji o Terenie pochodzące z państwowego zasobu geodezyjnego i
kartograficznego (pzgik) prowadzone przez powiatowe i wojewódzkie ośrodki
dokumentacji geodezyjnej i kartograficznej (PODGiK, WODGiK), z których kluczową
rolę odgrywać będą dane ewidencji gruntów i budynków.
Rysunek 1 PSIP w relacji do KSIT
Bez względu na typ i zakres udostępnionych danych z pzgik, dane te nie będą
podlegały aktualizacji, lecz będą wyłącznie przetwarzane do postaci warstw
referencyjnych umożliwiających powiązanie3 z nimi obiektów z pozostałych
warstw informacyjnych systemu w zakresie:
2
udostępnianie rozumiane jest jako umożliwianie dostępu do wydzielonego, autoryzowanego
zakresu danych i funkcji systemu i/lub umożliwienie pobierania wydzielonej części danych
3
inaczej tworzenie geo-relacji w geobazie danych PSIP
54
•
planowania przestrzennego,
•
decyzji i postanowień4,
• istotnych obiektów i zdarzeń, w tym opcjonalnie dla zarządzania
kryzysowego,
• zarządzania mieniem komunalnym, ochrony środowiska i przyrody,
ochrony zabytków oraz dóbr kultury, ofert inwestycyjnych,
• innych danych i warstw informacyjnych systemu, które będą powstawały w
odpowiedzi na potrzeby i wymagania użytkowników.
Zakłada się, że aktualizowane dane z pzgik na potrzeby PSIP będą udostępniane
przez Służbę Geodezyjną i Kartograficzną (SGK) zgodnie z obowiązującymi w tym
zakresie regulacjami prawnymi oraz warunkami technicznymi. Udostępnienie
danych będzie polegało na przekazaniu przez właściwą jednostkę SGK tj. PODGiK,
WODGiK lub CODGiK kopii danych w obowiązującym lub uzgodnionym formacie
danych uwzględniającym istniejące uwarunkowania lokalnie (PODGiK). W
szczególności dotyczy to udostępniania danych ewidencji gruntów i budynków w
formacie SWDE. Częstotliwość oraz zakres udostępniania danych będzie zależeć od
warunków prawnych, organizacyjnych i technicznych zwartych w umowie na
udostępnianie danych pzgik na rzecz Miasta (PSIP).
Celem prowadzenia w PSIP różnych analiz przestrzennych obejmujących np.
analizy sytuacji gospodarczo – ekonomicznej zakłada się, że PSIP będzie posiadał
bezpośredni dostęp do kluczowych (numerycznych) rejestrów publicznych rejestrów ewidencyjnych. W szczególności dostęp ten dotyczy rejestru ewidencji
ludności (PESEL), oraz rejestrów ewidencji działalności gospodarczej, ewidencji
mienia komunalnego i rejestrów finansowo – księgowych prowadzonych w
systemach informatycznych Urzędu Miasta, co w szczególności dotyczy ewidencji
nieruchomości: mienia komunalnego, dzierżaw, użytkowania wieczystego
prowadzonych w systemie RATUSZ firmy OTAGO5.
Ze względu na uwarunkowania prawne oraz wymogi bezpieczeństwa
przetwarzania danych dostęp do rejestrów nie będzie oznaczał bezpośredniego,
fizycznego dostępu, lecz dostęp do „repliki” tego rejestru lub przygotowanego
dedykowanego i aktualizowanego widoku danych, stanowiącego określony wyciąg
danych z tego rejestru.
Przyjmuje się, że do opracowania i wdrożenia systemu wykorzystane zostaną w
większości gotowe i sprawdzone rozwiązania komercyjne oraz w ograniczonym
zakresie rozwiązania „Open Source”.
Wszystkie zastosowane rozwiązania będą spełniały wymagane przepisami prawa
standardy techniczne oraz w uzasadnionym (opcjonalnym) zakresie będą spełniały
również standardy ISO, OGC oraz zalecenia Dyrektywy INSPIRE.
Od strony funkcjonalnej PSIP umożliwi w zakresie minimum:
4
PSIP zostanie zintegrowany (połączony) z wdrażanym system obiegu dokumentów i spraw
5 System OTAGO jest sukcesywnie wdrażany w Urzędzie Miasta Ruda Śląska i zgodnie z
opracowanym planem wdrożenia na przełomie roku 2009 / 2010 oraz 2011 przedmiotowe
ewidencje powinny być już prowadzone w tym systemie
55
•
wygodne i uniwersalne odszukanie i uzyskanie bezpośrednich informacji
dotyczących wybranego miejsca w przestrzeni (obiektu) lub grupy
obiektów o wspólnych cechach, inaczej atrybutach zarówno opisowych jak
i przestrzennych (geograficznych)
•
kreowanie raportów analitycznych, syntetycznych, statystycznych
pozwalających na szybkie uzyskanie przetworzonej informacji wynikającej
z porównania określonego stanu obiektów i zjawisk związanych z
przestrzenią,
•
prowadzenie symulacji i modelowania zmian wartości obiektów w zakresie
ich atrybutów przestrzennych jak i opisowych,
•
proste, wręcz intuicyjne i łatwe w interpretacji przedstawianie informacji
przestrzennej,
•
wykonywanie szeregu dedykowanych analiz, raportów oraz zestawień,
które zostaną uszczegółowione na etapie implementacji systemu,
•
realizowanie szeregu specjalizowanych funkcji jak: wizualizacja 3D, analiz
przestrzennych i innych, zgodnie z zakresem zaimplementowanych i
dostępnych do tego celu narzędzi i danych przy wykorzystaniu
standardowego, specjalizowanego oprogramowania GIS,
•
prowadzenie historii zmian dla kluczowych warstw informacyjnych
systemu, takich jak np.: ewidencja gruntów.
Technologicznie PSIP będzie opierać się na następujących założeniach:
1. system będzie budowany w oparciu o standardowe, komercyjne
oprogramowanie narzędziowe GIS i wybrane komponenty oprogramowania
„Open Source” oraz dedykowane, aplikacje dziedzinowe, posiadające
jednorodny interfejs użytkownika6,
2. poza specjalizowanym oprogramowaniem narzędziowym GIS system zostanie
zaimplementowany jako zestaw aplikacji – głównie portalowych modułów
tematycznych,
3. do gromadzenia danych wykorzystana zostanie technologia relacyjnej bazy
danych przestrzennych zapewniająca gromadzenie i przetwarzanie danych
przestrzennych przez zaimplementowanie specjalizowanych reguł i funkcji
gromadzenia (zapisu) oraz wyszukiwania danych przestrzennych (indeksy
przestrzenne) z zapewnieniem reguł poprawności topologicznego zapisu
danych geometrycznych, możliwość wspólnego utrzymania danych opisowych i
geometrycznych oraz modelowanie danych w określonych grupach prostych i
złożonych obiektów przestrzennych (punkt, poligon, linia) – zalecanym
rozwiązaniem w tym zakresie może być technologia geobazy7 lub inna
równoważna technologia zapewniająca obsługę danych przestrzennych
zaimplementowana w systemach baz danych Oracle, DB2, MS SQL Server,
Informix, Postgress lub innych równoważnych,
6
zalecanym rozwiązaniem PSIP będzie tzw. „cienki klient” umożliwiający uruchomienie
dedykowanej aplikacji w oknie przeglądarki internetowej MS Explorer, FireFox, Mozilla w technologii
AJAX
7
technologia firmy ESRI Inc.
56
4. obsługę baz danych przestrzennych zapewnią specjalizowane serwery mapowe
(inaczej serwery aplikacji GIS) oraz inne dedykowane narzędzia do efektywnej
obsługi danych przestrzennych zapewniające wysoki stopień bezpieczeństwa,
skalowalności i wydajność budowanego systemu,
5. baza danych PSIP stanowić będzie repozytorium danych operacyjnych oraz
(niezmiennych, ale aktualizowanych) danych referencyjnych pochodzących
6. z różnych źródeł danych jak: dane państwowego zasobu geodezyjnego i
kartograficznego (pzgik) np. ewidencja gruntów i budynków, mapa zasadnicza,
mapa topograficzna, ortofotomapa; dane gminy: plany zagospodarowania
przestrzenne, rejestry przestrzenne wydanych decyzji, postanowień, inne,
7. architektura systemu będzie mieszana: klient – serwer dla implementowanych
w narzędziach desktop GIS analiz przestrzennych oraz zaawansowanych
funkcji edycji danych oraz trójwarstwowa z tzw. cienkim klientem i dostępem z
przeglądarki internetowej dla pozostałej części funkcjonalności systemu PSIP,
8. system będzie spełniał wymogi interoperacyjności i będzie udostępniał wiele
formatów wymiany danych, w tym format XML8, GML, ShapeFile, DGN,
9. docelowo system zostanie zintegrowany z innymi systemami informatycznymi
Miasta, a przede wszystkim z systemem obiegu dokumentów i spraw – SOD
SEKAP,
10. ze względu na uwarunkowania technologiczne system będzie pracował w
środowisku MS Windows Terminal Server,
11. powszechne udostępnianie publicznych danych w sieci Internet oraz
udostępnianie autoryzowanych danych lub usług WMS, WFS np. dla firm
branżowych będzie realizowane przez Internetowy portal mapowy danych
publicznych w ramach wydzielonej infrastruktury sprzętowo – programowej,
przekazanej w kolokację zewnętrznemu usługodawcy,
12. dostęp do metadanych systemu PSIP oraz wydzielonej części metadanych dla
danych pzgik będzie realizowany przez Internetowy portal metadanych
uruchomiony w ramach zewnętrznej infrastruktury systemowej w kolokacji.
8
prezentacja danych pochodzących z wydawanych dokumentów oraz toczących się spraw może
odbywać się poprzez wywołanie usługi prezentacji widoku dokumentu lub sprawy – powyższe nie
wyklucza przekazywania kluczowych danych wydanej decyzji lub pozwolenia
57
Rysunek 2 Wstępna architektura logiczna systemu
58
2 Dodatki merytoryczne
2.1 Dodatek nr 1. Koncepcja Lokalnego Centrum Przetwarzania Danych
(LCPD)
2.1.1 Wprowadzenie
Poniższe zapisy przedstawiają opis koncepcji infrastruktury sprzętowo –
systemowej zalecanej do prawidłowego funkcjonowania PSIP w tzw. Lokalnym
Centrum Przetwarzania Danych (LCPD).
Zaproponowana architektura techniczna centrum przetwarzania danych jest
„otwarta’ ale została technicznie ograniczona do wymagań PSIP i odnosi się do
wyłącznie do dwóch opcji realizacyjnych w zakresie budowy LCPD w dotyczących
zastosowania farmy serwerów sprzętowych na potrzeby funkcjonowania systemu:
1. zalecanej – polegającej na zastosowaniu technologii blade z wspólną
infrastrukturą montażowo - komunikacyjno – zarządczą (kompaktowy stelaż
montażowy ang. „chasies”),
2. „tradycyjnej” – opartej o standardowe serwery np. do montażu w szafie typu
RACK.
W każdej z ww. opcji możliwe jest skalowanie infrastruktury na potrzeby PSIP
poprzez rozbudowę liczby serwerów (lub procesorów) oraz skalowanie
pojemności dyskowej serwerów lub pojemności zastosowanej macierzy dyskowej
SAN9.
Ze względu na uwarunkowania związane z trudnością uruchomienia nowej
serwerowni do implementacji w ramach projektu wybrano opcję 2 w konfiguracji
sieci SAN.
2.1.2 Koncepcja
Kluczowym elementem centrum przetwarzania danych (Rysunek 3 Ogólna
architektura techniczna LCPD – podstawowe komponenty) będą macierze dyskowe
(oznaczenie 2 na rysunku) zapewniające bezpieczeństwo systemu z punktu
widzenia ochrony i dostępu do danych, jak również funkcjonowania „krytycznych”
aplikacji.
9
opcjonalnie LCPD może zostać wykorzystane do przetwarzania innych systemów
aplikacyjnych Beneficjenta
59
Macierze będą łączyły w sobie dwie podstawowe technologie: Storage Area
Network (oznaczenie 3a na rysunku) i Network Attached Storage (oznaczenie 3b na
rysunku).
Zadaniem technologii SAN będzie odciążenie sieci komputerowej Ethernet dzięki
zastosowaniu bardzo szybkiej i wydajnej warstwy transportowej opartej o
połączenie światłowodowe i dedykowane urządzenia aktywne - szybkie
przełączniki FC10 wykorzystujące protokół Fiber Channel (FC).
Rysunek 3 Ogólna architektura techniczna LCPD – podstawowe komponenty
W takiej konfiguracji zasoby dyskowe będą widziane przez system operacyjny jako
własne wolumeny danych, bez względu na to gdzie będą się fizycznie znajdować.
Zastosowanie macierzy dyskowych wyposażonych w interfejsy SAN i NAS umożliwi
wykorzystanie ich nie tylko jako zasobów PSIP, lecz również potencjalnie jako
zasobów innych systemów informatycznych np. dla serwera plików.
Spójność danych będzie zapewniona przede wszystkim na poziomie systemowym
przez wykorzystanie narzędzi i oprogramowania dostarczanego wraz z macierzą
oraz systemem zarządzania bazą danych.
10
Przełączniki FC mogą być łączone w różne topologie
60
Dane w LCPD będą kopiowane w technologii off-host11 z wykorzystaniem biblioteki
taśmowej zawierającej napędy taśmowe LTO412 (oznaczenie 1 na rysunku).
Dla farmy serwerów sprzętowych PSIP (5 technicznych serwerów oraz opcja jeden
serwer zarządzający) użyte zostaną nowe rozwiązania w technologii blade będącej
w zastosowaniu znaczących producentów serwerów sprzętowych IBM, HP, SUN
(http://blade.org, Blade Server Base Specifications, oznaczenie 4 na rysunku) lub
nowe technologiczne rozwiązania dla „standardowych” serwerów kasetowych
(zalecana obudowa typu ang. mount rack)
2.1.3 Opcja I - technologia blade
Podstawową cechą technologii blade jest prostota infrastruktury, kasetonowa
budowa i uwspólnienie oraz konsolidacja zasobów takich jak: pamięć masowa,
okablowanie, zasilanie, chłodzenie, moduły komunikacyjne, serwery. Wszystkie te
zasoby będą montowane we wspólnym stelażu13, który będzie posiadał
redundancję takich elementów jak zasilanie czy też chłodzenie (dostępną dla
wszystkich zainstalowanych kaset).
W rezultacie końcowym technologia blade może:
a) podnieś niezawodność pracy systemu jako całości, poprzez zmniejszenie ilość
komponentów, które mogą potencjalnie ulec awarii, uproszczenie czynności
związanych z instalacją, konfiguracją i zarządzaniem,
b) doprowadzić do zmniejszenia ilość pobieranej energii i wydzielanego ciepła co nie
pozostanie bez wpływu na koszty zakupu, instalacji i utrzymania systemu.
Opcjonalnie dzięki wdrożeniu dodatkowo mechanizmów witrualizacji możliwe
będzie wdrożenie tzw. separacji domen zarządzania, czyli doprowadzać do stanu w
którym dokonywane zmiany nie wymagają rekonfiguracji otoczenia sieciowego.
Natomiast, dzięki współpracy narzędzi programowych ze zintegrowanym
systemem zarządzania będzie możliwa zmiana środowiska operacyjnego w krótkim
czasie - przy minimalnym zaangażowaniu administratora.
Przy założeniu, że PSIP nie jest system krytycznym (z punktu widzenia
niezawodności), w którym dopuszczalne są czasowe niedostępność systemu
wskutek awarii będzie można użyć rozwiązania typu ‘kaseta Hot Spare’ zamiast
11 Technologia off-host pozwala na pełne wykorzystanie mocy obliczeniowej serwerów, a
zarazem odciąża stacje klienta
Pojemność taśm LTO 4 jest dwukrotnie większa niż LTO 3 i wynosi 800 GB, a maksymalny transfer
danych - 120 MB/s (oba parametry przed kompresją). Napędy i taśmy LTO 4 są kompatybilne wstecz.
Napędy LTO 4 mogą odczytywać dane z taśm LTO 2 i LTO 3, a także zapisywać dane na taśmach LTO 3.
Nowością w standardzie LTO 4 jest kodowanie danych w standardzie AES 256 na poziomie napędu. W
LTO 4, podobnie jak w napędach poprzedniej generacji, możliwy jest zapis danych w trybie tylko do
odczytu (Write-Once, Read-Many, WORM). Pojemniejsze i szybsze napędy umożliwiają uproszczenie
infrastruktury i tworzą zapas skalowalności na dłuższy okres. Ostatecznie jednak wydajność i
skalowalność rozwiązań backupowych nie zależy od wydajności pojedynczych napędów, lecz od
jakości projektu całego centrum danych, stąd zastosowanie technologii LTO4 znakomicie uzupełnia
się z technologią FiberChannel; Obecnie na rynku IT dostępne są już dostępne napędy typu LTO5
jednak ich cena jest trochę niewspółmierna do oferowanych parametrów technicznych
12
13
całość znajduje się w kompaktowym stelażu „chasies” - co eliminuje dużą ilość kabli
61
drogich (również wymagających przeszkolonych administratorów) rozwiązań
klastrowania systemu i aplikacji.
W macierzach dyskowych, oprócz danych dla aplikacji będą zlokalizowane obszary
zawierające tzw. „binarna”, czyli obrazy systemów operacyjnych rozpoznawane
jako dyski logiczne, nie fizyczne..
Serwery kasetowe (blade) będą skonfigurowane w sposób umożliwiający pracę
bezdyskową, a obrazy systemów operacyjnych będą ładowane i dostępne z
macierzy.
Generalnie taka konfiguracja zmniejszy ilość punktów awarii14 oraz umożliwi
automatyzację procesu przejęcia pracy przez kasety HotSpare (kaseta zastępująca
uszkodzoną jest ładowana obrazem jej systemu operacyjnego15).
Bezpieczeństwo całości systemu będzie zapewnione przez redundancję sprzętową
oraz zastosowanie mechanizmów niwelujących skutki ewentualnych awarii np.
oprogramowania do archiwizacji danych, które umożliwi zarządzanie tworzeniem
kopii danych (backupów) przy wykorzystaniu również oprogramowania
macierzowego np. typu SnapMirror.
Przed negatywnymi skutkami przerwy dostawy energii elektrycznej chronić będą
urządzenia UPS służące do awaryjnego podtrzymywania napięcia na czas
bezpiecznego, awaryjnego zamknięcia systemu minimum kilku – kilkunastu minut (
w przypadku Urzędu Miasta Ruda Śląska serwerownia jest podłączona do
centralnego systemu podtrzymania napięcia w tym przypadku nie są konieczne
dedykowane urządzenia UPS dla infrastruktury PSIP).
System zarządzania tak złożoną infrastrukturą stanowić będą dedykowane serwery
zarządzające16 i / lub oprogramowanie, które w zależności od dostępnych i
zakupionych opcji może umożliwiać:
14
•
zdalne instalowanie systemów operacyjnych
•
zdalne instalowanie aplikacji
•
prognozowanie powstawania „wąskich gardeł” w środowisku serwerowym,
aktywne ostrzeganie administratorów, automatyzacja działań korygujących
•
zarządzanie wirtualnymi i fizycznymi systemami z jednej konsoli
•
monitorowanie i sterowanie wszystkimi zasilaczami UPS w sieci
•
monitorowanie i graficzną prezentacja danych o przestojach i czasie pracy
systemów lub grup systemów zdalne zarządzanie przy wykorzystaniu
połączenia VPN np. dla świadczenia usług serwisowych przez Wykonawcę
PSIP
dyski są niewątpliwie najbardziej awaryjnymi elementami całego rozwiązania
Ilość miejsca na macierzy, niezbędna dla przechowywania obrazów systemów operacyjnych dla
kaset wynosi (n+1)*4GB, gdzie: n – ilość kaset w obudowie, 1 – serwer zarządzający, 4GB – średni
rozmiar obrazu systemu operacyjnego, zależy oczywiście od systemu i rozmiaru zainstalowanych
aplikacji
15
16 każdy z serwerów zarządzających będzie wyposażony w interfejsy FC, aby posiadać dostęp do
macierzy, do obszarów ładowania serwerów typu blade
62
Zastosowanie technologii blade pomimo być może większych kosztów zakupu
może realnie obniżyć koszty instalacji, a przede wszystkim może znacząco
zmniejszyć koszty wdrożenia i późniejszej eksploatacji systemu.
Rysunek 4 Przykładowa infrastruktura systemowa blade (SAN) dla LCPD
2.1.4 Opcja II - standardowe serwery sprzętowe
Budowa infrastruktury systemowej LCD na potrzeby PSIP w rozwiązaniu
„tradycyjnym” różnić się będzie od technologii blade wyłącznie zastosowaniem
innej grupy produktowej serwerów. Pozostałe proponowane rozwiązania
techniczne dotyczące zwiększenia bezpieczeństwa konfiguracji, możliwości
zarządzania czy tez administrowania są możliwe również do uzyskania dla
technologii „tradycyjnej” np. poprzez zastosowanie dodatkowych kart rozszerzeń
lub dedykowanego, specjalistycznego oprogramowania.
Zasadnicza różnicą w tej opcji jest konieczność wyposażenia każdego serwera
sprzętowego w urządzenia komunikacji sieciowej FC (karty dwuportowe) oraz
karty zarządzania, które w przypadku technologii blade zapewnia to obudowa
montażowa do serwerów kasetowych blade.
Szczegółowe parametry proponowanej infrastruktury zawiera przegląd
komponentów systemowych oraz poniższy rozdział Rozdz. 2.2 Dodatek nr 2.
Przykładowy dobór i skalowanie infrastruktury systemowej – serwery sprzętowe.
2.2 Dodatek nr 2. Przykładowy dobór i skalowanie infrastruktury
systemowej – serwery sprzętowe.
Ze względu na brak publikowanej dokumentacji dot. doboru infrastruktury
technicznej (architektury oraz sprzętu komputerowego) na potrzeby budowy
systemu informacji przestrzennej w ofercie dostawców takich jak: Bentely Inc.,
AutoDesk Inc, Intergraph Inc., MapInfo przykładową analizę dotyczącą doboru
63
parametrów infrastruktury przeprowadzono w oparciu o materiały techniczne
http://support.esri.com/index.cfm?fa=knowledgebase.gateway firmy ESRI Inc. pt.
„System Design Strategies” przyjmując, iż zeskalowanie tego typu sprzętu dla
każdej innej równoważnej technologii GIS o podobnym stopniu złożoności
technicznej oraz spełniającego wymagania krytyczne wobec systemu PSIP tj.
wsparcie środowiska terminal serwer – tutaj MS Windows Terminal Server (MS
WTS) będzie adekwatne do propozycji rozwiązań i zaawansowanej technologii GIS
firmy ESRI Inc.
Należy zaznaczyć, iż technologia GIS, która będzie rozważana do zastosowania do
implementacji systemu PSIP przy ww. uwarunkowaniach nie powinna zawierać
jakichkolwiek zastrzeżeń, wyłączeń, ograniczeń co do wsparcia środowiska
systemowego MS Windows Terminal Server oraz powinna zawierać jednoznacznie
zapisy potwierdzające wsparcie tej technologii, w tym formalne dopuszczenie
użytkowania danego oprogramowania dla takiej konfiguracji systemowej w zapisach
licencji tzw. EULA ang. End User License Agreement – warunków licencyjnych dla
końcowego użytkownika.
Z punktu widzenia realizacji usług związanych z publikacją oraz edycją danych
przestrzennych w sieci Internet / intranet przy zastosowaniu wielodostępnego
systemu usług portalowych technologia ESRI Inc. lub inna równoważna może
zawierać kilka obszarów funkcjonalnych (obszarów usług):
•
wielodostępną edycję map17,
•
wielodostępny przegląd map,
•
gromadzenie i wyszukiwanie danych atrybutowych i przestrzennych
(obsługa bazy danych)
•
obsługę serwisu Web (serwer WWW)
•
obsługę renderowania – przygotowania obrazu mapy do publikacji.
W przypadku Beneficjenta ze względu na przyjęte założenie separacji obsługi
środowiska wewnętrznego (Intranet) i zewnętrznego (Internet) przypisanie ww.
usług do infrastruktury sprzętowej może wyglądać następująco:
dla sieci Intranet:
1. Serwer mapowy wielodostępnej edycji map,
2. Serwer mapowy wielodostępnego przeglądu map,
3. Serwer bazy danych,
4. Serwer aplikacji Web (serwer WWW),
5. Serwer mapowy renderowanie map,
dla sieci Internet (infrastruktura do kolokacji)
6. Serwer wielodostępnego przeglądu map,
17 Wyróżnienie usług edycji map dla serwera mapowego w przypadku technologii ESRI
wiąże z zaleceniami dotyczącymi zwiększenia zasobów infrastruktury celem uzyskania
wyższej sprawności budowanego systemu dotyczy to skalowania parametrów dla usługi
Server Object Container SOC
64
7. Serwer bazy danych,
8. Serwer aplikacji Web (serwer WWW) oraz prezentacji – renderowania map.
2.2.1 Dobór parametrów technicznych serwerów sprzętowych na potrzeby usług
przetwarzania danych przestrzennych
Doboru konfiguracji podstawowych parametrów serwerów sprzętowych, w tym
określenia wstępnych parametrów technicznych oraz ich szacunkowej ceny
dokonano na podstawie:
•
publikacji „System Design Strategies” i zawartych w niej zaleceń oraz
wyników testów wydajności serwerów wskaźnik SPECrate_int2006 dla
przykładowych konfiguracji oraz kryteriów doboru (liczba użytkowników,
liczba wyświetleń map na minutę) -,
•
wyników testów SPECrate_int2006 publikowanych na stronie SPEC
Standard Performance Evaluation Corporation http://www.spec.org
http://www.spec.org/cpu2006/results/rint2006.html,
•
dostępnych w sieci Internet ofert handlowych i technicznych oraz
publikowanych list cenowych producentów oraz dostawców sprzętu
komputerowego.(ceny podawane są w wartości netto bez podatku VAT).
Dobór przeprowadzono dla obu konfiguracji: infrastruktury systemowej
LCPD w sieci wewnętrznej Intranet oraz dla infrastruktury na potrzeby
kolokacji dla sieci Internet przyjmując, iż docelowo system PSIP obsłuży co
najmniej 300 użytkowników w sieci wewnętrznej tj. 200-250 użytkowników
jednoczesnych oraz minimum 200 użytkowników jednoczesnych w sieci
Internet.
2.2.1.1
Sieć wewnętrzną
Beneficjenta)
Intranet
(infrastruktura
wewnętrzna
organizacji
Założenia:
1. Liczba użytkowników (w początkowym okresie wdrożenia systemu):
•
do przeglądu map 150-200 jednoczesnych użytkowników
•
do „prostej” edycji w ramach funkcji portalu mapowego np. rejestracja
decyzji – 50 jednoczesnych użytkowników
2. Liczba wyświetleń na jednego użytkownika:
•
w trybie edycji nie więcej niż do 6 map na minutę,
•
w trybie przeglądu map nie więcej niż 6-8 map na minutę,
3. Implementacja Systemu w architekturze trójwarstwowej, w której co najmniej
funkcje gromadzenia, przetwarzania i prezentacji danych będę wspieranie
przez dedykowane serwery sprzętowe, co może wskazywać na zastosowanie 45 dedykowanych serwerów takich jak:
•
Serwer mapowy wielodostępnej edycji map,
•
Serwer mapowy wielodostępnego przeglądu map,
65
•
Serwer bazy danych,
•
Serwer aplikacji Web (serwer WWW),
•
Serwer mapowy renderowanie map,
4. Implementacja koncepcji Lokalnego Centrum Przetwarzania Danych (LCPD) w
oparciu o sieć SAN oraz zastosowanie standardowych serwerów wymaga aby
każdy z serwerów był wyposażony w:
•
jeden „startowy” dysk twardy18 ,
•
dwuportową kartę światłowodową FC (ang. Fibre Chanel) zapewniającą
dostęp do dwóch przełączników FC zgodnie z koncepcją techniczną LCPD.
Zgodnie z zaleceniami „System Design Strategies” przyjmuje się, że serwer
sprzętowy powinien posiadać minimum 2 GB RAM na każdy rdzeń procesora.
Ww. założenia są wspólne dla każdego dedykowanego serwera usług.
2.2.1.1.1
Serwer bazy danych
Liczba użytkowników 250 na którą składa się: 200 użytkowników w funkcji
przeglądu map oraz 50 w funkcji edycji map. Dla ww. warunków na podstawie
„System Design Strategies” rys. 9-17 otrzymuje się współczynnik wydajności
SPECrate_int2006 na poziomie 68-70 pkt.
Uwaga: ze względu na uwarunkowania licencjonowania np. bazy danych Oracle
http://www.oracle.com/corporate/license/olsa-pl-v061807.pdf oraz ze względu na
minimalizację kosztów zakupu licencji np. Oracle SE oraz SE One licencja, która liczna
jest na 1 procesor (jedno zajęte gniazdo) przyjmuje się, że dobór sprzętu dokonuje się
dla serwerów 1 procesorowych.
Przykładowe konfiguracje.
HP ProLiant DL160 G5p19 (73.2 pkt. w teście SPECrate_int2006) - 19 296,70 PLN;
Procesor Intel Xeon Quad-Core X5482 3.20GHz, 1600MHz FSB; pamięć RAM 4x4GB;
opcjonalnie napęd DVD-ROM IDE 8x typu slim lub napęd CD-ROM IDE 24x typu
slim; kontroler dysków HBA HP SC40Ge (RAID 0, 1); obudowa 1U stelażowa, 1
zasilacz 650W z PFC (korekcją współczynnika mocy); wbudowane dwie gigabitowe
karty sieciowe NC320i PCle; dysk twardy 146GB SAS SFF; dwuportowa karta FC
4Gb.
IBM System x3250 M220 (76.5 pkt. w teście SPECrate_int2006) - 15 086,72 PLN;
Procesor Intel Xeon Quad Core X3370 3.00GHz 1333MHz FSB; 16GB pamięci RAM;
zintegrowany interfejs sieciowy Gigabit Ethernet; zasilacz 351W; obudowa
stelażowa 1U; dysk twardy SAS 146GB; dwuportowa karta FC 4Gb; 3 lata gwarancji.
18
nie jest to wymaganie krytyczne bowiem możliwe jest takie skonfigurowanie macierzy, iż
ładowanie systemu operacyjnego na danym serwerze może następować z partycji dysku
logicznego z macierzy
19 Linia serwerów G5 jest linią produkcyjną zastępowaną przez serwery G6 jednak ze
względu na fakt, iż nie są jeszcze publikowane testy dla wszystkich głównych konfiguracji
serwerów G6 wskazywane są konfiguracje dla serwerów G5 publikowane przez Standard
Performance Evaluation Corporation (SPEC)
20
M2 - nowa linia technologicznie bardzo zaawansowanych i wydajnych serwerów IBM
66
Uwaga w wynikach testów „System Design Strategies” wskazano, iż testy byłoy
głównie prowadzone dla konfiguracji powyżej 8 rdzeni.
2.2.1.1.2
Serwer mapowy wielodostępnej edycji map
Liczba użytkowników 50. Wyświetlanie nie więcej niż do 6 map na minutę, co daje
łącznie cykl ok. 300 krotnego wyświetlenia mapy na minutę w skali globalnej. Dla
ww. warunków oraz przy założeniu funkcjonowania portalu mapowego dla klienta
„grubego” „AJAX Standard” na podstawie „System Design Strategies” rys. 9-32
otrzymuje się współczynnik wydajności SPECrate_int2006 na poziomie ok. 72 pkt.
HP ProLiant DL380 G5 (ok. 78 pkt. konfiguracja podobna)- 23 290,00 PLN;
Procesor Intel Xeon Quad Core X5470 3.33GHz 1333MHz FSB; pamięć RAM 8GB
(2x4GB); kontroler dysków HP Smart Array P400/512MB BBWC (RAID
0/1/1+0/5/6), 1 dysk twardy 146GB SAS SFF; dwie wbudowane karty sieciowe
NC373i z mechanizmem TCP/IP Offload i obsługą technologii Accelerated iSCSI
(zapewnianą przez opcjonalny zestaw licencyjny); dwuportowa karta FC 4Gb;
1 zasilacz 800W, możliwość podłączenia opcjonalnego redundantnego; opcjonalny
napęd optyczny; obudowa stelażowa 2U.
Dell PowerEdge R200 (76 pkt. w teście SPECrate_int2006) - 11 998,00 PLN;
Procesor Intel Xeon Quad Core X3360 2,83Ghz 1333MHz FSB; 8GB (2x4GB) pamięci
RAM DDR2 800MHz; kontroler dysków SAS 6iR Internal RAID Controller, dysk
twardy SAS 146GB 3.5” 15K RPM; dwuportowa, serwerowa karta sieciowa Gigabit
Ethernet Intel PRO 1000PT; napęd optyczny SATA DVD-ROM; dwuportowa karta
FC 4Gb; trzyletnia gwarancja.
2.2.1.1.3
Serwer mapowy wielodostępnego przeglądu map
Liczba użytkowników 200. Odświetlanie nie więcej niż do 8 -9 map na minutę, co
daje łącznie cykl ok. 1600-1800 krotnego wyświetlenia mapy na minutę w skali
globalnej. Dla ww. warunków oraz przy założeniu zastosowania „cienkiego klienta”
i technologii AJAX na podstawie „System Design Strategies” rys. 9-32 otrzymuje się
współczynnik wydajności SPECrate_int2006 na poziomie ok. 110-114 pkt.
HP ProLiant DL380 G5 (113 pkt. w teście SPECrate_int2006) - 28 308,64 PLN;
2 procesory Intel Xeon Quad Core X5460 3.16GHz, 1333MHz FSB; pamięć RAM
16GB; kontroler dysków HP SmartArray P400/512MB BBWC (RAID 0/1/1+0/5/6),
dysk twardy 146GB SAS SFF; napęd optyczny DVD-ROM/CD-RW IDE; obudowa
stelażowa 2U; dwie wbudowane gigabitowe karty sieciowe NC373i z mechanizmem
TCP/IP Offload i obsługą technologii Accelerated iSCSI zapewnianą przez
opcjonalny zestaw licencyjny; zasilacz 800W, opcjonalny podłączany podczas pracy
redundantny; dwuportowa karta FC 4Gb; 3 lata gwarancji.
IBM System x3650 M2 (126 pkt. w teście SPECrate_int2006) - 19 418,00 PLN
2 procesory Intel Xeon Quad Core E5504 2GHz; pamięć RAM 16GB (możliwość
rozszerzenia do 128GB); napęd optyczny SATA DVD/CD-RW combo; dwuportowa
wbudowana karta sieciowa Gigabit Ethernet Controller (Broadcom 5709S); dysk
twardy 146GB SAS; dwuportowa karta FC 4Gb; 3 lata gwarancji.
2.2.1.1.4
Serwer serwer mapowy renderowanie map
67
Liczba użytkowników 250. Odświetlanie nie więcej niż do 6-8 map na minutę, co
daje łącznie cykl ok. 2000 krotnego wyświetlenia mapy na minutę w skali globalnej.
Dla ww. warunków oraz przy założeniu zastosowania „cienkiego klienta” i
technologii AJAX na podstawie „System Design Strategies” rys. 9-33 otrzymuje się
współczynnik wydajności SPECrate_int2006 na poziomie od ok. 75-76 pkt. (testy
dla serwer o pojemności RAM 2 GB).
HP ProLiant DL320 G5p (78.7 pkt. w teście SPECrate_int2006) - 11 665,00 PLN;
Procesor Intel Xeon Quad-Core X3370 3.00GHz; 8GB RAM; kontroler Intel 82801IR
Integrated Serial ATA Host Controller, dysk twardy SATA 500GB; opcjonalny napęd
optyczny; odbudowa stelażowa 1U; dwuportowy gigabitowy interfejs sieciowy
NC326i; zasilacz 400W; dwuportowa karta FC 4Gb.
IBM System x3650 M2 (126 pkt. w teście SPECrate_int2006) - 19 418,00 PLN;
2 procesory Intel Xeon Quad Core E5504 2GHz; pamięć RAM 16GB (możliwość
rozszerzenia do 128GB); napęd optyczny SATA DVD/CD-RW combo; dwuportowa
wbudowana karta sieciowa Gigabit Ethernet Controller (Broadcom 5709S); dysk
twardy 146GB SAS; dwuportowa karta FC 4Gb; 3 lata gwarancji.
Dell PowerEdge R200 (76 pkt. w teście SPECrate_int2006) - 11 998,00 PLN;
Procesor Intel Xeon Quad Core X3360 2,83Ghz 1333MHz FSB; 8GB (2x4GB) pamięci
RAM DDR2 800MHz; kontroler dysków SAS 6iR Internal RAID Controller, dysk
twardy SAS 146GB 3.5” 15K RPM; dwuportowa, serwerowa karta sieciowa Gigabit
Ethernet Intel PRO 1000PT; napęd optyczny SATA DVD-ROM; dwuportowa karta
FC 4Gb; trzyletnia gwarancja.
2.2.1.1.5
Serwer aplikacji Web (serwer WWW)
Funkcje serwera WWW może pełnić ten sam serwer sprzętowy, który został
przeznaczony do usług serwera mapowego do rendrowania map lub można
zastosować dedykowany serwer o parametrach SPECrate_int2006 na poziomie ok.
70 pkt.
2.2.1.2
Sieć Internet
Założenia:
Podstawą do szacunków liczby użytkowników oraz związanych z tym odsłon
portalu mapowego systemu PSIP były statystyki informacyjnego portalu miejskiego
dla miasta Ruda Śląska z których wynika, iż średnio dzienne następuje około 15 do
25 tys. odsłon dziennych portalu21.
Odnosząc powyższe dane do planowanego wdrożenia portalu mapowego, który
może stanowić dość interesujące źródło informacji można oszacować, iż w
początkowym okresie wdrożenia systemu „zainteresowanie danymi mapowymi”
może generować ruch nie większy niż 1200 -1800 wyświetleń map na minutę – co
wynika z założenia dostępu do portalu około 200 użytkowników jednoczesnych i 6
-9 wyświetleń map na minutę w trybie przeglądu.
21
http://silnet.pl/p,s,2767.html - http://silnet.pl/obrazki/cms/2745.zalaczniki.pdf
68
Zgodnie wcześniejszą dyskusją techniczną proponowana konfiguracja systemu
PSIP w sieci Internet może przedstawiać się następująco:
•
Serwer bazy danych (minimum 8 dysków twardych dla konfiguracji RAID 5,
6, 10)
•
Serwer mapowy wielodostępnego przeglądu map (2-4 dyski twarde),
•
Serwer aplikacji Web (serwer WWW) łączący również usługi serwera
mapowego do renderowanie map (2 dyski twarde).
Należy zaznaczyć, iż w tym przypadku dopuszczalna może być zarówno architektura
dwuwarstwowa jak i trójwarstwowa – wybór rozwiązania leżeć będzie w gestii
Wykonawcy systemu PSIP.
Konfiguracja infrastruktury sprzętowej na potrzeby systemu w sieci Internet nie
zakłada implementacji sieci SAN a tym samym każdy z serwerów musi posiadać
własne zasoby dyskowe.
Zgodnie z zaleceniami „System Design Strategies” przyjmuje się, że serwer
sprzętowy powinien posiadać minimum 2 GB RAM na każdy rdzeń procesora.
Ww. założenia są wspólne dla każdego dedykowanego serwera usług.
2.2.1.2.1
Serwer bazy danych
Dla ww. warunków na podstawie „System Design Strategies” rys. 9-17 otrzymuje
się współczynnik wydajności SPECrate_int2006 na poziomie 55-60 pkt.
Uwaga: ze względu na uwarunkowania licencjonowania np. bazy danych Oracle
http://www.oracle.com/corporate/license/olsa-pl-v061807.pdf oraz ze względu na
minimalizację kosztów zakupu licencji np. Oracle SE oraz SE One licencja, która
liczona jest na 1 procesor (jedno zajęte gniazdo) przyjmuje się, że dobór sprzętu
dokonuje się dla serwerów 1 procesorowych.
ProLiant DL380 G5 (79.6 pkt. w teście SPECrate_int2006) - 27 895,00 PLN;
2 procesory Intel Xeon Quad Core X5355 2,66 GHz; 16GB RAM (możliwość
rozszerzenia do 64GB); kontroler dysków HP Smart Array P400/256MB (RAID
0/1/1+0/5); 8 dysków twardych 146GB SAS SFF; opcjonalny napęd optyczny;
obudowa 2U stelażowa; dwie gigabitowe karty sieciowe NC373i z mechanizmem
TCP/IP Offload i obsługą technologii Accelerated iSCSI (zapewnianą przez
opcjonalny zestaw licencyjny); zasilacz 800W, opcjonalny zasilacz nadmiarowy
podłączany podczas pracy; 3 lata gwarancji.
IBM System x3650 (67.4 pkt. w teście SPECrate_int2006) - 23 901,88 PLN
Procesor Xeon E5335 2,00GHz; pamięć RAM 16GB (możliwość rozszerzenia do
48GB w 12 gniazdach DIMM), kontroler dysków twardych ServeRAID 8K-I (RAID
0/1/1+0), 8 dysków 146GB SAS; obudowa stelażowa 2U; 3 lata gwarancji.
HP ProLiant DL380 G5 (113 pkt. w teście SPECrate_int2006) - 25 997,00 PLN;
2 procesory Intel Xeon Quad Core X5460 3.16GHz, 1333MHz FSB; pamięć RAM
16GB; kontroler dysków HP SmartArray P400/512MB BBWC (RAID 0/1/1+0/5/6),
8 dysków twardych 146GB SAS SFF; napęd optyczny DVD-ROM/CD-RW IDE;
obudowa stelażowa 2U; dwie wbudowane gigabitowe karty sieciowe NC373i z
mechanizmem TCP/IP Offload i obsługą technologii Accelerated iSCSI zapewnianą
przez opcjonalny zestaw licencyjny; zasilacz 800W, opcjonalny podłączany podczas
69
pracy redundantny; 3 lata gwarancji. Serwer powinien posiadać co najmniej 8
dysków i możliwość implementacji RAID 5,6,10.
2.2.1.2.2
Serwer mapowy wielodostępnego przeglądu map
współczynnik wydajności SPECrate_int2006 na poziomie ok. 110-114 pkt.
ProLiant DL360 G5 (114 pkt. w teście SPECrate_int2006) - 27 491,50 PLN
2 procesory Intel Xeon Quad Core X5460 3.16GHz, 16GB pamięci (możliwość
rozszerzenia do maksymalnie 64GB); kontroler dysków HP Smart Array
P400i/256MB BBWC (RAID 0/1/1+0/5/6), 4 dyski twarde 146GB SAS SFF; napęd
optyczny combo DVD/CD-RW typu slimline, opcjonalny napęd dyskietek; obudowa
1U stelażowa; dwie wbudowane karty gigabitowe karty sieciowe NC373i z
mechanizmem TCP/IP Offload i obsługą technologii Accelerated iSCSI zapewnianą
przez opcjonalny zestaw licencyjny; zasilacz 700W (opcjonalna nadmiarowość typu
1+1); 3 lata gwarancji.
IBM System x3550 M2 (132 pkt. w teście SPECrate_int2006) - 21 195,75 PLN
2 procesory Intel Xeon Quad Core L5506 2.13 GHz; 16GB RAM (możliwość
rozszerzenia do 32GB); zintegrowany kontroler SAS, 4 dyski twarde 146GB SAS;
napęd optyczny DVD/CD-RW; zintegrowana gigabitowa karta sieciowa; obudowa
stelażowa 1U, zasilacz 670W; 3 lata gwarancji.
2.2.1.2.3
Serwer mapowy renderowanie map oraz serwer WWW
współczynnik wydajności SPECrate_int2006 na poziomie od 75-76 pkt.
ProLiant DL320 G5p (78.7 w teście SPECrate_int2006) - 7 215,37 PLN
Procesor Intel Xeon Quad Core X3370 3.00 GHz; 8GB pamięci RAM; kontroler
dysków Intel 82801 IR Integrated Serial ATA Host Controler, 2 dyski SATA 250GB;
obudowa 1U stelażowa; wbudowany dwuportowy adapter serwera NC326i;
zasilacz 400W;3 lata gwarancji.
IBM System x3250 M2 (76.5 pkt. w teście SPECrate_int2006) - 9 512,72
Procesor Intel Xeon Quad Core X3370 3.00GHz 1333MHz FSB; 8GB pamięci RAM;
zintegrowany interfejs sieciowy Gigabit Ethernet; 2 dyski twarde 146GB SAS;
zasilacz 351W; 3 lata gwarancji; obudowa stelażowa 1U
ProLiant DL380 G5 (79.6 pkt. w teście SPECrate_int2006) - 21 733,00 PLN
2 procesory Intel Xeon Quad Core X5355 2,66 GHz 16GB RAM (możliwość
rozszerzenia do 64GB); kontroler dysków HP Smart Array P400/256MB (RAID
0/1/1+0/5), 2 dyski twarde 146GB SAS SFF; opcjonalny napęd optyczny; obudowa
2U stelażowa; dwie gigabitowe karty sieciowe NC373i z mechanizmem TCP/IP
Offload i obsługą technologii Accelerated iSCSI (zapewnianą przez opcjonalny
zestaw licencyjny); zasilacz 800W, opcjonalny zasilacz nadmiarowy podłączany
podczas pracy; 3 lata gwarancji.
70
2.3 Dodatek nr 3. Uszczegółowienie kluczowych rozwiązań PSIP
Poniższe zapisy przedstawiają opis wymagań wobec dwóch kluczowych rozwiązań
PSIP: intra – internetowego portalu mapowego oraz portalu metadanych oraz
wybranej grupy modułów tematycznych systemu.
2.3.1 Portal mapowy intranetowy i Internetowy
Zadaniem portalu mapowego PSIP będzie publikowanie w sieci intranet oraz
Internet map generowanych na podstawie zasobów przestrzennych Bazy Danych
PSIP (BD PSIP).
Opracowany portal mapowy będzie:
1. posiadać funkcjonalność: nawigacyjną na mapie - powiększanie, pomniejszanie,
przesuwanie mapy, pomiar powierzchni różnych obiektów występujących na
mapie w postaci poligonów (np. budynków, działek), wielosegmentowy pomiar
odległości, selekcję obiektów przez: zaznaczanie / selekcję obiektów linią lub
poligonem, zaznaczanie / selekcję jednego lub wielu obiektów przez wskazanie
ich kursorem, ustawienia skali,
2. umożliwiać udostępnianie, publikowanie i prezentowanie informacji opisowej i
geometrycznej, włącznie z danymi ewidencyjnymi w formie pełnej oraz w
różnych układach i kompozycjach tabelarycznych, z uwzględnieniem
uprawnień użytkownika,
3. posiadać zaawansowane narzędzia do wydruków w zakresie:
•
drukowania widocznego obszaru mapy wraz z legendą i podkładem mapy z
podaną skalą oraz cechami identyfikującymi użytkownika, który dokonuje
wydruku, (kto kiedy skąd),
•
drukowania obrazów w wysokiej rozdzielczości przez zaznaczenie obszaru
do drukowania z zadaną skalą, gdzie wraz z zaznaczeniem powinny
wyświetlać się parametry wielkości drukowanej mapy oraz skala,
•
zapisu wydruku w formacie pliku do formatu MS Word (DOC) lub w
standardzie Adobe Acrobat (PDF).
4. zawierać funkcje identyfikacji obiektów na mapie, przy czym poza
podstawowym odczytaniem informacji o obiekcie portal powinien być zdolny do
odczytania informacji skojarzonych z tabel będących w relacji z obiektem
podstawowym; odczyt danych z tabel skojarzonych powinien być
implementowany z uwzględnieniem weryfikacji uprawnień użytkownika do
danych oraz z uwzględnieniem prezentacji wielopoziomowej relacji w bazie
danych,
5. posiadać podstawowe narzędzia do wyszukiwania klas obiektów jak np.:
adresów, działek, osób, instytucji poprzez wskazanie na mapie lub wpisanie
ręcznie danych tak, aby utworzyć ich listę i według niej wykonać wyszukiwanie
oraz narzędzia do uniwersalnego wyszukiwania zapewniające:
•
budowę atrybutowych warunków zapytania z wykorzystaniem składni
języka SQL,
71
•
budowę przestrzennych warunków zapytania z wykorzystaniem selekcji
międzywarstwowej / buforowania,
•
możliwość parametryzacji warunków atrybutowych dla wartości typu
string, int i date: podczas wykonania zapytania użytkownik jest
monitowany o podanie parametru lub wybranie go spośród wartości
słownikowych,
•
budowę zapytania poprzez wykorzystanie relacji bazy (wynikiem będą
rekordy będące w wybranej relacji z wynikiem poprzedniego kroku);
operacja ta wykluczy możliwość wykorzystania w następnych krokach
selekcji międzywarstwowej / buforowania,
•
możliwość zapisania sparametryzowanego narzędzia do wyszukiwania we
własnym profilu i jego ponownego wykorzystania.
6. umożliwiać zapisywanie aktywnej sesji użytkownika oraz jego ustawień (opcja
wyłącznie dla portalu intranetowego), w tym z zapamiętaniem aktualnego
widoku mapy wraz z zapisaniem informacji uzupełniających (nazwa serwisu,
rozmiar okna, wybrane obiekty),
7. prezentować zawartość tematyczną układu warstw danego serwisu mapowego
w postaci drzewa z podziałem na pogrupowane tematycznie warstwy, z
możliwością zwijania i rozwijania danej warstwy oraz włączania / wyłączania
warstw na drzewie, jaki i z uaktywnianiem wybranej warstwy,
8. obsługiwać metadane w uzgodnionym standardzie z rozszerzeniem
standardowego zakresu informacji metadanych dostępnych w strukturach bazy,
9. generować raporty tak, aby:
•
z poziomu aplikacji intranetowej możliwe było wyselekcjonowanie do nich
obiektów poprzez wskazanie ich na wybranej warstwie
lub
wyselekcjonowanie w oparciu o atrybuty opisowe,
•
zapewnić
możliwość
tworzenia
raportów
wielopoziomowych,
wykorzystujących dane będące w relacji z obiektami zaznaczonymi na
mapie lub wyszukanymi (o ile takie relacje istnieją w bazie),
•
użytkownik miał możliwość konfigurowania raportów przez wybranie
wskazanych pól atrybutowych oraz ustalenia ich kolejności,
•
raporty były generowane na szablonach z informacją o czasie ich
przygotowania, źródle pochodzenia, aktualności danych oraz wykonującym
raport,
•
użytkownik mógł zapisać w swoim profilu skonfigurowany szablon raportu
w zakresie wybranych pól, ich kolejności oraz danych pochodzących z tabel
będących w relacji.
10.umożliwiać w każdym z serwisów tematycznych edytowanie atrybutów
opisowych, przy stosownie skonfigurowanych uprawnieniach.
W trybie pracy portalu intranetowego zapewniona będzie ochrona danych
osobowych zgodnie z ustawą o ochronie danych osobowych przez
zaimplementowanie reguł dostępu do danych wyłącznie dla uprawnionych
użytkowników, rejestrowanie dostępu do danych osobowych. Zakłada się, że portal
będzie posiadał opcje działania w dwóch trybach tzw. serwisu dynamicznego, czyli
generującego kolejne widoki mapy na „żądanie” klienta (przeglądarki) oraz w
72
trybie serwisu z buforem map, inaczej „cache’em, który powinien przyspieszyć
działanie portalu22.
Dla obsługi i prezentacji rejestrów przestrzennych portal będzie zapewniał:
•
prostą edycję danych geometrycznych w portalu,
•
prowadzenie statystyk, zawierających między innymi rejestrowanie
sposobu i częstości wykorzystania portalu,
•
publikowanie i wyszukiwanie metadanych23,
•
udostępnianie danych z modelu 3D (bez wymogu instalowania
jakiegokolwiek dodatkowego kodu w formie apletów, wtyczek).
2.3.2 Portal metadanych
Zadaniem portalu24 metadanych będzie obsługa metadanych PSIP.
Zgodnie z założeniami koncepcji systemu portal metadanych będzie dostępny
wyłącznie w sieci Internet.
Portal zostanie opracowany zgodnie z zaleceniami Dyrektywy INSPIRE w zakresie
wymagań dotyczących otwartości i interoperacyjności danych oraz usług, tak aby
docelowo udostępnić zbiór usług sieciowych umożliwiających dostęp i
publikowanie danych systemu również przez inne serwery mapowe z
wykorzystaniem usług OGC WMS.
Technicznie obsługa portalu sprowadzać się będzie do obsługi i nawigacji
pomiędzy dwoma głównymi oknami, oknem katalogu metadanych z opcjami
wyszukiwania i podglądu danych oraz oknem podglądu mapy umożliwiającym
pełną wizualizację danych przestrzennych o funkcjonalności tożsamej z
funkcjonalnością portalu PSIP.
Opracowane rozwiązanie będzie umożliwiać:
•
katalogowanie informacji o zasobach przez import opisu zasobów
przestrzennych w formacie XML, w tym z geobazy,
•
skanowanie oraz katalogowanie informacji o zasobach przez import opisu
metadanych z zarejestrowanych - wskazanych serwerów z wykorzystaniem
mechanizmów Open Archive Initiative Protocol for Metadata Harvesting
(OAI-PMH) lub Web Accessible Folders celem pobrania plików XML z
metadanymi (opcja w sieci Internet),
22
Powyższe oznacza, że na serwerze aplikacji GIS powinien być generowany (i tam
przechowywany) obraz mapy w różnych predefiniowanych skalach mapowych, a obsługa
mapy po stronie klienta powinna polegać na prezentacji obrazu mapy pochodzącej z
generowania na serwerze i w zależności od potrzeby klienta (przeglądarki) powinny być
przesyłane do niego odpowiednie bloki uzupełniające mapę np. w przypadku jej
przesuwania
23
Rozwiązanie w tym zakresie może stanowić odrębny portal mapowy przeznaczony
wyłącznie do obsługi metadanych edytowanych i ładowanych do systemu PSIP za pomocą
standardowego oprogramowania GIS lub dedykowanego edytora metadanych
24
inaczej metaportal
73
•
wyszukiwanie zasobów przestrzennych bazy danych PSIP w oparciu o
wprowadzone kryteria atrybutowe, przestrzenne, tematyczne oraz czasowe
stanowiące atrybuty metadanych systemu (tzw. przeszukiwanie katalogu
metadanych),
•
sortowanie wyników wyszukiwania, włącznie z ich zapisaniem do pliku
oraz wydrukiem,
•
wyświetlenie mapy dla wybranych zasobów przestrzennych, w tym
zasobów spoza zakresu PSIP a dostępnych przez OGC WMS,
•
obsługę / nawigowanie po mapie w zakresie funkcji minimum: powiększ,
pomniejsz, przesuń, poprzedni zasięg mapy, pełny zasięg mapy,
włącz/wyłącz legendę mapy.
Portal metadanych będzie spełniać normy: ISO19115 / ISO19119 Aplication Profile
for CSW 2.0 (odpowiednik OpenGIS® Catalogue Service Implementation
Specification), ISO 19115:2003 / 2006 Metadata (PN-EN ISO 19115:2005), ISO
19119:2005 Services (PN-EN ISO 19119:2006), ISO/TS 19139:2007 Metadata-XML
schema implementation.
2.3.3 Moduły tematyczne
2.3.3.1
Moduł Centralnego Administratora (MCA)
Zadaniem modułu będzie dostarczenie narzędzi technicznych do zarządzania
system PSIP w formie jednolitego modułu lub zintegrowanych ze sobą narzędzi
„administratora” posiadających strukturę hierarchiczną.
MCA będzie służył do zarządzania dla poszczególnych modułów aplikacyjnych oraz
komponentów systemu: serwera bazodanowego i serwerów mapowych oraz
innych komponentów wskazanych na etapie opracowania Projektu Organizacyjno –
Technicznego (POT).
Opracowane rozwiązanie powinno umożliwić między innymi:
•
definiowanie ról oraz nadawanie uprawnień użytkownikom,
•
zarządzanie usługami relacji: użytkownik – dane – funkcje (usługi) w
ramach co najmniej schematów bazy danych (grup warstw informacyjnych
systemu),
•
zarządzanie dostępem do funkcji w poszczególnych modułach, a w
przypadku portalu mapowego do poziomu serwisów mapowych,
•
konfigurowanie warstw w wybranym serwisie lub module (kompozycje
mapowe), przez dodanie / usunięcie / modyfikację warstw danych,
określenie ich atrybutów i sposobu prezentacji oraz określenie reguł
kontroli i aktualizacji danych,
•
konfigurowanie parametrów historii,
•
konfigurowanie wersjonowania obiektów,
•
nadawanie uprawnień
atrybutowych),
do
edytowania
danych
(geometrycznych
74
i
2.3.3.2
•
konfigurowanie uprawnień użytkownika na podstawie usługi katalogowej
serwera LDAP lub serwera katalogowego DNS (zgodnie z POT),
•
personalizację ustawień lokalnych użytkownika.
Moduł Adresowy (MA)
Zgodnie z przyjętymi założeniami organizacyjnymi prowadzenie numeracji
porządkowej nieruchomości na podstawie Rozporządzenia Ministra Infrastruktury
z dnia 28 października 2004 r. w sprawie numeracji porządkowej nieruchomości
(Dz. U. z 2004 r. Nr 234 poz. 2432) będzie realizowane w systemie STRATEG w
PODGiK.
Dane o numeracji porządkowej nieruchomości i powiązanych z nią obiektach
(działka, budynek, oś ulicy, nazwa ulicy) będę pozyskiwane do PSIP w formie
importu danych warstwy adresowej EWMAPA / ADRESY.
Niemniej jednak na potrzeby funkcjonowania systemu PSIP opracowany będzie
Moduł Adresowy, który dodatkowo będzie w sobie łączył standardowe narzędzia
geokodowania zawarte w wybranym środowisku technicznym oprogramowania
narzędziowego Desktop GIS.
Moduł Adresowy powinien umożliwić co najmniej:
25
•
prowadzenie słownika ulic wg kilku systemów zapisu: GUS, TERYT, PESEL,
nazwa pełna zgodna z uchwałą rady miasta25, nazwa skrócona, nazwa
zwyczajowa,
•
tworzenie i edytowanie obiektów warstwy adresowej wraz z ich atrybutami
– dotyczy to takich obiektów adresowych jak: punkty adresowe (numeracje
porządkowe nieruchomości), osie ulic, odcinki ulic, zakresy adresowe
(parzyste, nieparzyste), strefy (rejony statystyczne, rejony wyborcze,
osiedla, obszary adresowe wg kodów pocztowych oraz inne strefy – maks.
do 20 stref podziału obszarowego),
•
tworzenie warstwy punktów adresowych poprzez wstawianie i modyfikację
obiektów punktów adresowych o ustalonej geometrii oraz łączenie ich z
obiektami słownikowymi osi dróg (w ograniczonym zakresie, tak aby
utrzymać spójność danych w PODGiK i BD PSIP),
•
opcjonalnie rejestrowanie danych z wniosków podziałowych, scaleń oraz
innych dokumentów dających podstawy prawne do wprowadzenia zmian w
zakresie prowadzonego rejestru punktów adresowych, a w szczególności
łączenie atrybutów punktu adresowego z danymi z wniosku w sprawie
zgłoszenia zmiany nazwy ulicy na podstawie uchwały Rady Miasta lub z
wniosku o nadaniu numeru dla nieruchomości (integracja z SEOD SEKAP),
•
prezentację warstwy punktów adresowych zgodnie z
określonymi w POT (np. zgodnie z instrukcją geodezyjną K-1),
•
prowadzenie historii zmian nazw ulic, placów oraz odtworzenie stanu
adresowej na określony dzień,
warunkami
Zakłada się, że jest to treść zgodna z zapisem w systemie STARTEG w PODGiK
75
•
udostępnienie dedykowanych analiz przestrzennych w ilości 10
dedykowanych analiz i raportów o zakresie uzgodnionym na etapie
opracowania POT.
W celu weryfikacji danych funkcje modułu MA będzie uzupełnione w intranetowym
portalu mapowym o funkcje wprowadzania notatek / komentarzy do
poszczególnych obiektów przestrzennych, a w szczególności do obiektów warstwy
adresowej, tak aby udostępnić wprowadzenie do danego obiektu notatki /
komentarza w formie tekstu lub załącznika graficznego oraz umożliwić
raportowanie uwag dla określonego wybranego zakresu danych.
2.3.3.3
Moduł Ewidencji Dróg (MED)
Zadaniem modułu Ewidencja Dróg będzie prowadzenie rejestru ewidencji dróg
powiatowych zgodnie z obowiązującymi w tym zakresie przepisami prawa, a w
szczególności z:
•
Rozporządzeniu Ministra Infrastruktury z dnia 16 lutego 2005r. (Dz. U. Nr 67
poz. 582) 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.
•
Rozporządzeniu Ministra Infrastruktury z dnia 23 września 2003 r. w sprawie
szczegółowych warunków zarządzania ruchem na drogach oraz wykonywania
nadzoru nad tym zarządzaniem / Dz. U. nr 177, poz. 1729 /
Opracowane rozwiązanie powinno między innymi:
1. umożliwić rejestrację danych o drogach, obiektach inżynierskich,
oznakowaniu, infrastrukturze drogowej w oparciu o zbudowany system
referencyjny – lokalny zawierający bazę obiektów: punktów węzłowych,
odcinków międzywęzłowych, numerów oraz kategorii i nazw
poszczególnych ulic,
2. umożliwiać prowadzenie ewidencji zgodnie z wytycznymi zawartymi w
Rozporządzeniu MTiGM w sprawie zasad numeracji i ewidencjonowania
dróg i obiektów inżynierskich, oznakowania, infrastruktury tramwajowej z
dnia 25.04.2005 r. z uwzględnieniem podziału administracyjnego,
3. zapewnić raporty: książkę drogi, dziennik objazdu dróg, wykaz dróg, mapę
techniczno - eksploatacyjną dróg, książkę obiektu mostowego, kartę
obiektu mostowego, wykaz obiektów mostowych,
4. umożliwiać graficzną ilustrację danych wykonanej mapy referencyjnej oraz
wszystkich elementów znajdujących się w pasie drogowym a
wprowadzanych w kolejnych etapach zakładania ewidencji,
5. umożliwiać współpracę z danymi wektorowymi jak i rastrowymi,
6. zapewnić przeglądanie oraz edycję obiektów map mapy eksploatacyjnej (w
zakresie danych graficznych i opisowych),
7. posiadać systemu autoryzacji dostępu do wybranego, ograniczonego zbioru
danych oraz zabezpieczenia przed dostępem do danych osób
nieuprawnionych,
76
8. zapewnić pełną integrację graficznej bazy danych z atrybutami opisowymi
(zmiany dokonane w graficznej bazie muszą mieć odzwierciedlenie w bazie
opisowej i na odwrót), w tym również przez rejestrowanie danych w jednej,
relacyjno - obiektowej bazie danych,
9. zapewniać utworzenie ewidencji w zakresie rejestracji i prezentacji
rodzajów nawierzchni jezdni, chodników i krawężników oraz innych
powierzchni pasa drogowego, automatyczne przenoszenie danych o
drogach do tabel zgodnych z rozporządzeniem, drukowanie map w
formatach znormalizowanych i nieznormalizowanych,
10. umożliwiać rejestrację parametrów dotyczących oceny stanu nawierzchni,
11. zapewnić zestaw bibliotek zawierających aktualnie obowiązujące znaki
drogowe poziome i pionowe oraz narzędzia do ich modyfikacji i tworzenia
nowych,
12. zapewnić wprowadzanie danych o zdarzeniach występujących w pasie
drogowym z zachowaniem topologii na oddzielne warstwy tematyczne
według ustalonego podziału rzeczowego: osie dróg wraz z ich nazwami,
numerami i kilometrażem, krawędzie jezdni, chodniki, zjazdy, pasy zieleni,
drzewa i krzewy, oznakowanie pionowe, oznakowanie poziome,
sygnalizacja świetlna, urządzenia bezpieczeństwa ruchu, włazy studni
kanalizacyjnych, wpusty uliczne, odwodnienie pasa drogowego (rowy
przydrożne, przepusty), słupy energetyczne, oświetleniowe, telefoniczne,
obiekty inżynierskie, torowiska, podstacje trakcyjne, zwrotnice, sieć
trakcyjna, inne zgodnie z POT,
13. umożliwić: dokonywanie wyceny majątku drogowego, dokonywanie oceny
stanu technicznego nawierzchni jezdni i chodników, bazując na danych o
sieci dróg wprowadzonych w części ewidencyjnej systemu,
ewidencjonowanie i monitorowanie remontów bieżących i kapitalnych,
rejestrowanie zdarzeń na drodze (w tym zdarzeń związanych z
utrzymaniem bezpieczeństwa na drodze np. wypadków drogowych),
uzgodnienia, rozkopy, rejestrację dowolnych innych obiektów
zlokalizowanych w terenie i podlegających administracji drogowej - typu
reklama, dzierżawa, zajęcie pasa drogowego, przejazdy nienormatywne itp.
14. zapewnić taką organizację danych aby informacje opisowe przypisane
danym obiektom na mapach numerycznych mogły być udostępnione
równolegle z ich przeglądaniem w warstwie graficznej,
15. zapewnić organizację danych zgodną z rozporządzeniem, w tym:
•
drogę w programie opisywać muszą min. następujące parametry: kategoria,
klasa, funkcja, kilometr początkowy i końcowy, skrzyżowań,
•
odcinek drogi reprezentowany powinien być graficznie jako łamana a węzły
powinny być wyznaczone przez: granice jednostek administracji
państwowej, skrzyżowania, zmiany nazwy ulic, zmiany ilości jezdni, obiekty
mostowe, przejazdy kolejowe – przy czym dla każdego typu odcinka należy
wprowadzić dane: numer drogi i numer kolejny w drodze, klasa drogi,
nazwa jednostki administracyjnej, ilość jezdni, kilometr początkowy i
końcowy.
77
16. umożliwić przypisywanie do zdarzeń informacje opisujące tak aby były
powiązane w sposób jednoznaczny z odcinkiem i drogą – przy czym
wstępnie zakłada się następujący podział na grupy zdarzeń i zdarzenia
(ostateczny określi – potwierdzi POT):
•
drogi: jezdnie chodniki, krawężniki pobocza, pasy bezpieczeństwa, ścieżki
rowerowe, zieleńce
•
obiekty inżynierskie: mosty, wiadukty, estakady, tunele, przejścia
podziemne, przepusty, mury oporowe, ekrany,
•
oznakowanie: znaki pionowe, poziome,
•
elementy bezpieczeństwa ruchu: bariery, separatory, systemy informacyjne,
•
sygnalizacja świetlna: opis pionowy i poziomy,
•
infrastruktura tramwajowa: torowiska, sieć trakcyjna, zwrotnice, podstacje
trakcyjne,
•
elementy w zarządach innych jednostkach: przejazdy kolejowe,
•
utrzymanie zimowe: standard zimowego utrzymania dla poszczególnych
ulic.
17. zapewnić dla każdego zdarzenia następujące informacje: punkt początkowy
i końcowy, typ zdarzenia (opis techniczny), wycena, położenie, szerokość,
powierzchnia, uwagi itp.,
18. umożliwić rejestrację dokumentacji fotograficznej z inwentaryzacji sieci
dróg z interwałem nie mniejszym niż 5m oraz z minimalną rozdzielczość
zdjęć to 1024x768, przy zapewnieniu rejestracji zdarzeń drogowych w
kierunku wzdłuż i w kierunku prostopadłym do jazdy pojazdu
rejestrującego,
19. zapewnić podgląd modelu cyfrowego pasa drogowego wygenerowanego
technologią naziemnego mobilnego skaningu laserowego, który powinien
zawierać model: zadrzewienia w pasie drogowym oraz model zabudowy i
przeszkód w obrębie pasa drogowego.
Zakres informacyjny i funkcjonalny modułu będzie zgodny z obowiązującym w tym
zakresie rozporządzeniem przy czym nie będzie obowiązkowe generowanie przekroju
drogi, który zgodnie z przyjętymi ustaleniami będzie wprowadzany do systemu na
podstawie dokumentacji technicznej dróg (szkiców), co stanowić będzie specyficzne
„uproszczenie” funkcjonalności modułu w zakresie prowadzenia mapy technicznoeksploatacyjna dróg. Dane referencje warstw geometrycznych dróg (mapy
zasadniczej) oraz linii rozgraniczających (planu miejscowego) moduł będzie pobierał
z bazy danych PSIP.
2.3.3.4
Moduł Rejestru Planu (MRP)
Moduł Rejestru Planu (MRP) wspomagać będzie prowadzenie rejestru planów
uchwalonych, w opracowaniu oraz uchylonych.
Dane do rejestru stanowić będą dane z migracji danych z planów uchylonych i
nieobowiązujących za okresy minione (rysunek planu, zasięg planu, treść uchwały,
78
akty zmieniające)26 oraz załadowane dane obowiązującego miejscowego planu
zagospodarowania przestrzennego – jest to obecnie jeden plan dla całego obszaru
miasta.
Oprócz danych określonych przez obowiązujące przepisy Ustawy z dnia 27 marca
2003 r. o planowaniu i zagospodarowaniu przestrzennym oraz Rozporządzenie
Ministra Infrastruktury z dnia 26 sierpnia 2003 r. w sprawie wymaganego zakresu
projektu miejscowego planu zagospodarowania przestrzennego rejestr planu
zawierać będzie również tzw. warstwę informacyjną planu dla obowiązujących
mpzp, która stanowić będzie podstawę do prowadzenia analiz przestrzennych GIS
w środowisku oprogramowania narzędziowego Desktop GIS celem wyszukiwania,
wyboru obszarów spełniających zadane kryteria.
Warstwa informacyjna planu będzie budowana na podstawie danych z warstw
przeznaczenia terenów, wskaźników zabudowy oraz innych cech planu mających
swoje odwzorowanie przestrzenne, a określonych na etapie opracowania POT.
Dla obsługi warstwy informacyjnej konieczne będzie opracowanie narzędzi do jej
tworzenia i aktualizacji oraz dedykowanych prostych raportów analiz
przestrzennych w narzędziach Desktop GIS.
Dane rejestru planu pochodzić będą z SEOD SEKAP (jeżeli ten obszar będzie objęty
wdrożeniem SEOD) lub wprowadzane będą do bazy danych PSIP (BD PSIP) za
pomocą prostego edytora w części opisowej (daty zdarzeń związanych z procesem
planistycznym np. data uchwały o przystąpieniu, data wyłożenia planu, data
uchwalenia, treści, uchwał, inne) oraz dedykowanych narzędzi modułu lub pakietu
Desktop GIS w zakresie związanym z rejestrowaniem oraz edycją treści
geometrycznej planu: zasięg, rysunek planu (raster), wektorowe warstwy planu,
dane archiwalne, dane opracowania fizjograficznego, inne.
Związane z wdrożeniem modułu MRP kwestie wprowadzenia systematyki zapisu i
prezentacji planu („standaryzacji planu”) zostaną opracowane i określone jako
wytyczne dla wykonawców planów podczas prac Wykonawcy projektu PSIP na
etapie opracowania POT.
Przyjmuje się, że rejestr planu (w części graficznej oraz opisowej) będzie pozwalał
na:
•
dodanie nowego planu – zdefiniowanie zasięgu planu (funkcja własna lub
funkcje oprogramowania narzędziowego, standardowego GIS),
•
załadowanie planu do bazy danych przez załadowanie rysunku planu:
grupy rastrów planów składających się na jeden plan (funkcja własna lub
funkcje oprogramowania narzędziowego, standardowego GIS),
•
dodanie wniosku o wszczęcie lub zmianę planu w zakresie graficznym i
atrybutowym,
•
rejestrowanie uchwał oraz zmian prawnych – uchwały zmieniające/inne
(ładowanie – zapisanie treści uchwały w formacie PDF lub innym
uzgodnionym formacie np. HTML, DOC),
•
rejestrowanie pojawiających się wniosków/opinii i uzgodnień do planu
26
Pozostałe treści do rejestru planu muszą być wprowadzone ręcznie przez użytkowników
modułu – pracowników WAU
79
2.3.3.5
•
wyszukiwanie zarejestrowanych wniosków/opinii/uzgodnień,
•
wyszukiwanie danych związanych z wybranym planem.
•
raportowanie z bazy danych o wnioskach zarówno w relacji do wybranego
planu jak i do zaznaczonego obszaru miasta (bufor),
•
tryb edycji geometrycznej danych.
Moduł Wypisu i Wyrysu z Planu (MWWP)
Moduł Wypisu i Wyrysu z Planu stanowić będzie odrębny, dedykowany moduł
aplikacyjny lub konfigurowalną funkcje portalu mapowego. Zadaniem modułu
będzie wspomaganie procedury wydania informacji o przeznaczeniu terenu
(wypisu i wyrysu z planu zagospodarowania przestrzennego).
Dane do wypisu i wyrysu moduł będzie pobierał z BD PSIP z rejestru planów na
podstawie parametrów wejściowych, które mogą stanowić: nazwa – identyfikator
plan, obszar, data wydania informacji „na dzień obowiązywania”.
Podstawą do wydania informacji o przeznaczeniu terenu będą odpowiednio
przygotowane usystematyzowane dane odnoszące się do rysunku graficznego
planu oraz treści uchwały27.
2.3.3.6
Moduł Rejestrów Graficznych Decyzji (MRGD)
Moduł Rejestrów Graficznych Decyzji administracyjnych, postanowień, wniosków
oraz innych skategoryzowanych dokumentów (MRGD) np. pozwolenia na budowę,
warunki zabudowy, ustalenie lokalizacji inwestycji celu publicznego, zajętość pasa
drogowego, wniosku o zmianę planu, inne – stanowić będzie moduł służący do
rejestrowanie dokumentu decyzji administracyjnej w formie tzw. graficznego
rejestru decyzji – rejestru łączącego decyzje z określoną dla nich przedmiotowo
grupą obiektów przestrzennych.
Istotą tego rozwiązania będzie łączenie informacji atrybutowej (opisowej), których
źródłem jest system elektronicznego obiegu dokumentów (SEOD SEKAP) z
informacją przestrzenną, tak aby utworzyć graficzny (przestrzenny) rejestr decyzji,
postanowień lub wniosków dla danej kategorii sprawy zgodnie z kategoryzacją
JRWA. W tym celu na etapie opracowania POT zostanie określony dokładnie zakres
informacyjny oraz struktury danych dla rejestrów graficznych oraz podział na
warstwy informacyjne zgodnie z podziałem i kategoryzacją spraw wg JRWA.
Opracowane rozwiązanie musi być na tyle „otwarte” aby, umożliwić prowadzenie
rejestrów graficznych poprzez:
1. automatyczne ich tworzenie przez łącznie atrybutów danej skategoryzowanej
sprawy z wybraną cechą identyfikacji przestrzennej: danymi adresowymi,
danymi identyfikacyjnymi nieruchomości (numery działek ewidencyjnych,
27 Dane dotyczące planu rysunku oraz uchwały muszą być wcześniej przygotowane i
powinny stanowić rysunek w formie zgodnej z rysunkiem planu uchwalonego (raster –
skan) oraz tekst uchwały poddany procesowi podzielenia na określone paragrafy, akapity
odpowiednie do struktury i zakresu merytorycznego uchwały (treści planu), tak aby ułatwić
półautomatyczny wybór określonego zakresu uchwały do wypisu
80
numery budynków), wybranymi atrybutami cech identyfikacji przestrzennej
jak np.: nazwa ulicy lub innymi uzgodnionymi w POT cechami przestrzennymi,
2. tworzenie relacji poprzez identyfikowanie „obiektów geometrycznych” przez
ich wskazanie lub powiązanie graficzne przy wykorzystaniu prostych narzędzi
edycyjnych na warstwach informacyjnych PSIP i połączenie z daną sprawą
(decyzja, postanowienie, wniosek).
W zakresie edycji i rejestrowania decyzji, moduł powinien umożliwić:
2.3.3.6.1
•
wyszukiwanie i wybór zarejestrowanych i niezarejestrowanych decyzji,
wniosków, opinii, uzgodnień w SEOD,
•
wyszukiwanie i wybór „obiektów przestrzennych”28 takich jak adres, numer
działki, inne,
•
dodanie decyzji, pozwolenia,
graficznym jak i atrybutowym,
•
łączenie z innymi rejestrami o ile zachodzi bezpośrednia zależność,
•
wydruk wyrysu z mapy zawierającego obszar danego graficznego rejestru
decyzji,
•
wyszukiwanie informacji zgromadzonych w bazie decyzji, wraz z
możliwością ich klasyfikowania (m.in. po typach decyzji, rejestrów), w tym
wyszukiwanie przez funkcje bufora przestrzennego,
•
tworzeniu zestawień i raportów z poszczególnych rejestrów, w tym
raportów tekstowych z załącznikami mapowymi oraz tabelarycznymi
atrybutów opisowych,
•
wprowadzanie / edycję danych dla poszczególnych pozycji rejestru o dane
konieczne do prawidłowego przetwarzania rejestru a niepochodzące z
SEOD,
•
łączenie i edycję tworzonego lub modyfikowanego rejestru z wskazaną dla
niego warstwą referencyjną.
postanowienia,
wniosku
w
zakresie
Metoda integracji PSIP z SEOD SEKAP oraz modułami systemu OTAGO
Integracja PSIP z EOD będzie odbywać się z wykorzystaniem metody wymiany
komunikatów z wykorzystaniem technologii SOAP lub mechanizmów POST i GET
protokołu HTTP. Usługi zostaną zdefiniowane i udostępnione przez SEOD i będą
pokrywać następujące czynności: podaj teczkę, podaj zbiór teczek, podaj decyzję,
podaj zbiór decyzji, zapisz teczkę, zapisz decyzję.
Parametrem usług będzie min. kod JRWA, kod sprawy, „teczka”, „decyzja” o
strukturze określonej przez SEOD i zgodnej z zakresem informacyjnym dokumentu
elektronicznego. Wyróżnikiem czy dana sprawa / decyzja została obsłużona /
zarejestrowana w PSIP będą: „data obsługi - rejestrowania w PSIP”, (opcjonalnie
zgodnie z POT) plik z wygenerowanym „obrazem mapy” z zarejestrowaną decyzją,
wydanym wypisem, wyrysem, inne – plik ten stanowić będzie załącznik do „teczki”
danej sprawy. „Wiedza” nt. kategoryzacji spraw wg JRWA na te, które podlegają
obsłudze przez PSIP może być definiowana po stronie SEOD lub PSIP.
28
Ostateczny zakres obiektów przestrzennych zostanie określony na etapie opracowanie
Projektu Szczegółowego
81
PSIP powinien zapewnić prowadzenie rejestrów graficznych poprzez:
•
automatyczne ich tworzenie poprzez funkcje łączenia atrybutów danej
skategoryzowanej sprawy z wybraną cechą identyfikacji przestrzennej:
danymi adresowymi, danymi identyfikacyjnymi nieruchomości (numery
działek ewidencyjnych, numery budynków), wybranymi atrybutami cech
identyfikacji przestrzennej jak np.: nazwa ulicy lub innymi cechami
przestrzennymi uzgodnionymi na etapie tzw. Projektu Organizacyjno –
Technicznego (POT),
•
tworzenie relacji dla „obiektów geometrycznych” przez ich wskazanie lub
powiązanie graficzne przy wykorzystaniu prostych narzędzi edycyjnych na
warstwach informacyjnych PSIP i połączenie z daną sprawą („teczką”,
„decyzją” … postanowieniem, wnioskiem).
Zakłada się, że proces obsługi / rejestracji będzie na tyle uogólniony, że dla
określonej grupy „rejestracji”:
•
nie będzie wymagany czynny udział operatora (użytkownika) w procesie
„łączenia” (geokodowania) danej kategorii spraw / zdarzeń z
reprezentującym ją obiektem: punktowo – obszarowym (np. adres - punkt
adresowy), liniowym (np. ulica - oś ulicy), obszarowym (np. numer lub
numery działek ewidencyjnych – poligony działek ewidencyjnych),
•
wymagana będzie czynność operatora bowiem powstające powiązanie nie
jest jednoznaczne i wymaga ingerencji operatora po to, aby zarejestrować
sprawę / zdarzenie np. przez „ręczne” wkreślenie obiektu lub wybranie
obiektu / grupy obiektów geometrycznych i powiązanie ich ze sprawą
(decyzją).
Ponadto, przyjmuje się, że dane rejestru przestrzennego pochodzić będą wyłącznie
z SEOD (zakres informacyjny), a po stronie PSIP nastąpi wyłącznie przypisywanie
cechy „przestrzennej” dla danego obiektu / zdarzenia i zwrotne wypełnienie
„treści” dla „teczki” („data obsługi - rejestrowania w PSIP”, „obraz mapy).
Dla użytkownika obu systemów SEOD, PSIP powinno być możliwe obustronne
„przejście” i zaprezentowanie istniejącej relacji przez wywoływanie odpowiednio
linku do usługi prezentacji mapy w PSIP i przywiązanych do nich dokumentów
(„teczki”) lub na odwrót wybór dokumentu w EOD i wizualizację danej sprawy na
mapie po stronie PSIP.
2.3.3.7
Moduł Ofert Inwestycyjnych (MOI)
Moduł publikowania ofert inwestycyjnych miasta umożliwi wspomaganie procesu
opracowania i publikowania ofert inwestycyjnych związanych ze sprzedażą lub
dzierżawą nieruchomości komunalnych. Moduł umożliwi co najmniej:
•
opracowanie bazy szablonów ofert inwestycyjnych
•
automatyczne pobranie i konfigurowanie „obrazu” kompozycji mapowej
reprezentującej obiekt oferty z BD PSIP,
•
wstępne oszacowanie wartości oferty na podstawie wskazanych przez
operatora argumentów zgodnie z algorytmem budowy stref cenności
nieruchomości miasta,
82
•
2.3.3.8
automatyczne przeniesienie oferty do serwisu intranetowego oraz
wygenerowanie pliku eksportu (oferty) do serwisu internetowego
(będącego w kolokacji zewnętrznego usługodawcy).
Moduł Rejestru Zabytków (MRZ)
Moduł rejestru zabytków umożliwi prowadzenia rejestru i kart zabytków oraz
wykopalisk archeologicznych jako warstwy informacyjnej systemu tzw.
„przestrzennego rejestru zabytków” zgodnego co do zakresu i treści z zakresem
rejestru zabytków, który jest prowadzony przez Prezydenta Miasta Ruda Śląska na
podstawie zawartego porozumienia z Wojewódzkim Konserwatorem Zabytków.
Dane „przestrzennego rejestru zabytków” stanowić będą dane poddane migracji z
baz danych rejestru zabytków prowadzonych obecnie w bazie MS Access. Dane te
zostaną rozszerzone o materiały informacyjne w formie zdjęć, opracowań,
ekspertyz lub innych dokumentów w formatach JPG, DOC, RTF.
Źródłem danych do „przestrzennego rejestru zabytków” będą dane z SEOD SEKAP
(jeżeli ten obszar będzie objęty wdrożeniem SEOD) lub dane bezpośrednio
wprowadzane do bazy danych PSIP (BD SIP) za pomocą prostego edytora dla części
opisowej danych związanych z wydaniem lub aktualizacją karty zabytku lub
wydaniem dla tego zakresu określonej decyzji lub postanowienia.
Do przypisania lub aktualizacji danych przestrzennych rejestru zabytków
wykorzystane zostaną te same narzędzia co do usług związanych z rejestrowaniem
graficznym decyzji.
2.3.3.9
Moduł Ogólny (MO)
Zadaniem modułu ogólnego będzie prowadzenie warstw informacyjnych obiektów
lub zdarzeń przestrzennych, cechujących się niewielkim ilościowo zakresem
informacyjnym opisującym dany obiekt lub zdarzenie.
Opracowany moduł umożliwi prowadzenie prostej edycji obiektów przestrzennych
w zakresie informacji atrybutowej. Natomiast nie będzie zawierał funkcji edycji
geometrycznej obiektów przyjmując, że atrybuty geometryczne obiektów będą
edytowane np. poza PSIP i będę pozyskiwane z źródłowych baz danych np. treść
mapy zasadniczej z PODGiK budynki, działki ewidencyjne, studnie, inne.
Zatem, zadaniem modułu będzie wyłącznie aktualizacja wartości opisowych w
skategoryzowanym i dokładnie określonym dla danego obiektu zakresie atrybutów
np.: data zdarzenia, identyfikator obiektu, nazwa opisowa, inne.
Przypisywany zakres atrybutów do danego obiektu będzie predefiniowany
(parametryzowany) przez użytkownika (administratora systemu) przy
wykorzystaniu możliwości technicznych Modułu Centralnego Administratora oraz
opisanych przez Wykonawcę procedur związanych np. z zakładaniem tabel, relacji
dla „zdarzeń przestrzennych” dla danego obiektu.
83
Zakres i sposób parametryzacji musi zostać zaproponowany i zaakceptowany przez
Beneficjenta na etapie opracowania POT29.
2.3.3.10
Moduł Zarządzania Kryzysowego (MZK)
Moduł Zarządzania Kryzysowego obejmować będzie funkcje prowadzenia mapy
zagrożeń bezpieczeństwa publicznego w zakresie: obiektów ewidencji
hydrotechnicznej: przepompownie wody, rowy odwadniające i opaskowe, inne,
ewidencji obiektów dla potrzeb doraźnej ewakuacji ludności w czasie zdarzeń
kryzysowych: autobusy, minibusy, samochody ciężarowe połączonej z ewidencją
działalności gospodarczej, inne.
Funkcje modułu będą zgodne z zakresem podstawowym funkcji Modułu Ogólnego i
zostaną rozszerzone o zakres minimum 10 dedykowanych raportów / funkcji /
analiz przestrzennych określonych na etapie opracowania Projektu Organizacyjno
– Technicznego (POT) o złożoności zbliżonej do wykonania raportu mającego na
celu:
2.3.3.11
•
wybór grupy obiektów na podstawie analizy przestrzennej danych
wektorowych (np. bufor) i / lub rastrowych (np. trasowanie) w połączeniu
z kryteriami atrybutowymi,
•
opracowanie dla wybranej grupy obiektów raportu o predefiniowanym
(przez użytkownika) układzie kolumnowym reprezentacji graficznej
raportu z funkcjami arytmetycznymi przeliczenia wartości atrybutowych
poszczególnych kolumn
•
zaprezentowanie wybranej grupy obiektów na predefiniowanej kompozycji
mapowej (łączącej w sobie dane wektorowe, rastrowe z różnym
współczynnikiem przezroczystości) różnej od kompozycji mapowej
stanowiącej wynik prezentacji tych samych danych w kompozycji mapowej
na ekranie terminala.
Moduł Ochrony Środowiska (MOŚ)
Moduł Ochrony Środowiska obejmować będzie funkcje prowadzenia mapy ochrony
środowiska w zakresie takich obiektów i zdarzeń jak: strefy osiadania („mapy
osiadania”), zakłady utylizacji, wysypiska śmieci, miejsca gromadzenia odpadów,
inne, w tym opcjonalnie szkody górnicze – jeżeli zostanie to potwierdzone na etapie
opracowania Projektu Organizacyjno – Technicznego (POT).
Jeżeli opracowanie takiego rozwiązania okaże się, złożone technicznie
Beneficjent może zaakceptować również rozwiązanie alternatywne polegające na
opracowaniu szablonu aplikacji z pełną dokumentacją techniczną, dla której to
Wykonawca przekaże jemu pełne prawa autorskie do utworu, na wszystkich polach
eksploatacji tak, aby umożliwić swobodne wykorzystanie rozwiązania zgodnie z
powyższymi wymaganiami do rozbudowy i rozwoju systemu
29
84
– Technicznego (POT) o złożoności określonej w sposób tożsamy jak dla modułu
MKZ.
Dane dotyczące obiektów i zdarzeń będą mogły pochodzić z rejestru wydawanych
decyzji, postanowień SEOD SEKAP.
2.3.3.12
Moduł Ochrony Zdrowia (MOZ)
Moduł Ochrony Zdrowia obejmować będzie funkcje prowadzenia obiektów
związanych z ochroną zdrowia takie jak: szpitale publiczne / niepubliczne –
prywatne, inne ośrodki ochrony zdrowia, apteki, ambulatoria, inne obiekty
związane z ewidencją prowadzoną przez NFOZ.
MKZ.
2.3.3.13
Moduł Ewidencji Szkół (MES)
Moduł Ewidencji Szkół obejmować będzie funkcje prowadzenia obiektów
związanych z edukacją i szkolnictwem takie jak: szkoły podstawowe, gimnazja,
licea, szkoły wyższe, przedszkola, strefy demograficzne, inne.
MKZ.
2.3.3.14
Moduł Rejestru Nieruchomości (MRN)
Moduł Rejestru Nieruchomości obejmować będzie funkcje podglądu i dostępu dla
innych modułów PSIP tzw. „rejestru nieruchomości”, który będzie tożsamy co do
zakresu i aktualności z ewidencją nieruchomości mienia komunalnego, rejestrem
dzierżaw i wieczystego użytkowania oraz ewidencję nieruchomości Skarbu
Państwa. Rejestr ten będzie powstawał na podstawie mechanizmu replikowania
lub import ww. danych z baz danych systemu STARTEG.
Moduł MRN nie będzie służył do prowadzenia rejestru nieruchomości w żadnym
ww. zakresie przedmiotowym. Jego zadaniem będzie wyłącznie (nieograniczone
licencyjnie) zapewnienie dostępu do aktualnej „repliki danych ewidencji
nieruchomości”.
2.3.3.15
Moduł Stref Cenności (MSC)
Moduł Stref Cenności będzie służył do generowania stref cenności na podstawie
danych pochodzących z rejestru cen i wartości nieruchomości (RCiWN) z ewidencji
gruntów i budynków lub własnych baz BD PSIP zawierających zarejestrowane
85
transakcje na podstawie aktów notarialnych i wycen rzeczoznawców (operatów
szacunkowych).
Zakres minimalny informacji w zakresie wyceny obejmować będzie: dane obiektu
podlegającego wycenie oraz dane obiektów reprezentatywnych w zakresie
podmiotowym dot. właściciela / władającego, dane przedmiotowe: nr –
identyfikator nieruchomości, adres, cena średnia za 1m2 wielkość współczynnika
korygującego z protokołu, powierzchnia lub inne cechy obiektu – nieruchomości,
wartość - wynik szacowania: cena łączna oraz cena średnia za 1m2.
Moduł będzie posiadał możliwości słownikowania / parametryzacji obiektów
związanych z transakcją: typ transakcji, lista rzeczoznawców, lista notariuszy,
obręby i ulic. Ponadto, na etapie edycji danych będzie możliwe weryfikowanie i
„podpowiadanie” zapisów dzięki bezpośredniemu wykorzystaniu aktualnie
obowiązującego „rejestru nieruchomości”.
Algorytm generowania stref cenności zostanie ostatecznie zaprojektowany i
uzgodniony podczas opracowania Projektu Organizacyjno – Technicznego (POT) i
zgodnie z wcześniejszymi ustaleniami będzie uwzględniać w zakresie relacji
obiektów następujące kryteria:
•
przeznaczenie terenu w planie zagospodarowania przestrzennego,
•
sąsiedztwo,
•
stopień uzbrojenia terenu w infrastrukturę techniczną,
•
dostęp do środków komunikacji,
•
położenie (w stosunku do centrów miejskich),
•
warunki gruntowo – wodne,
•
zobowiązanie służebności gruntowej.
Dla każdego ww. kryterium w POT będą określone jednoznaczne warunki danego
kryterium oraz zakres przyjmowanych dyskretnych wartości dla wyliczania
wartości wynikowych algorytmu.
2.3.3.16
Moduł Opłaty Adjacenckiej i Planistycznej (MOA)
Moduł Opłaty Adjacenckiej będzie rejestrować wymiar opłaty adjacenckiej z tytułu
podziałów nieruchomości lub przeprowadzenia inwestycji infrastrukturalnych.
Dane do wyliczeń podstawy wymiaru będą pochodzić z rejestru wydawanych
decyzji, postanowień SEOD SEKAP dla wniosków podziałowych oraz z określonej
kategorii dokumentów informacyjnych związanych z inwestycją infrastrukturalną.
Na podstawie wygenerowanych w PSIP stref cenności moduł będzie umożliwiał
również przeprowadzenie analizy opłacalności naliczenia opłat adiacenckich.
Dla opłaty planistycznej moduł będzie liczył i rejestrował wymiar opłaty na
podstawie stref opłat planistycznych określonych w planie zagospodarowania
przestrzennego (wymóg jednoznacznego określenia w zapisach uchwały wysokości
opłat w treści związanej z danym ustaleniem lub w zapisach dla danej kategorii
przeznaczenia terenu).
86
2.3.3.17
Moduł importu / eksportu danych
Moduł importu / eksportu danych udostępni minimum dwie podstawowe funkcje
(mechanizmy):
1. importu danych pochodzących z baz danych Krajowego Systemu Informacji o
Terenie (KPSIP) wchodzących w zakres państwowego zasobu geodezyjnego i
kartograficznego (pzgik) i udostępnianych przez Powiatowy Ośrodek
Dokumentacji Geodezyjnej i Kartograficznej (PODGiK) Miasta Ruda Śląska
2. eksportu danych do internetowego portalu mapowego (zgodnie z zakresem
określonym w POT) oraz eksportu w standardowych formatach wybranego
środowiska technologicznego pakietu Desktop GIS
Zakres mechanizmów importu obejmuje co najmniej import danych:
•
ewidencji gruntów i budynków w formacie SWDE,
•
punktów adresowych oraz osi ulic,
•
treści mapy zasadniczej w lokalnym, równoważnym dla formatu SWING-2
formacie wymiany danych systemu EWMAPA lub w formie odczytu w trybie
„native” bezpośrednio z tablic bazy danych programu EWMAPA.
Należy zaznaczyć, że lokalny format przekazywania danych treści mapy zasadniczej
może służyć również do przekazywania danych ewidencji gruntów i budynków w
zakresie treści geometrycznej. Obie funkcje importu danych w formacie SWDE oraz
dla mapy zasadniczej powinny zapewniać historię aktualizacji danych z
możliwością archiwizowania stanu sprzed zmiany, czyli sprzed aktualizacji.
Wszystkie mechanizmy importu tj. SWDE / mapa zasadnicza / dane adresowe
powinny zapewnić:
•
funkcje dwuetapowego ładowania danych, najpierw do geobazy lokalnej a
następnie do bazy danych systemu BD SIP,
•
funkcje wyboru zapisywanie znacznika wersji danych - minimum data
eksportu danych z PODGiK, data ładowania, inne,
•
opcje historycznego archiwizowania wersji importu / eksportu danych na
określony dzień, włącznie z opcją wyboru wersji i możliwością odtworzenia
stanu na określony dzień,
•
opcje wsadowej
danych,
•
zlokalizowanie całości obsługi w formie „elementu” panelu administratora
w Module Administrator,
•
opcje raportowania błędów oraz wyników funkcji importu do pliku typu
log,
•
wykonywanie importu danych niezależnie dla części opisowej i / lub części
geometrycznej dla danych ewidencyjnych,
•
opcję odczytu danych ewidencji gruntów w formacie „różnicowym”
wyłącznie zmian (opcja jako zamiennik wykonania opcji tworzenia różnicy
przez mechanizmy importu),
•
funkcje kontroli danych w zakresie składniowym oraz semantycznym –
minimum weryfikowanie topologii zapisu obiektów do BD PSIP.
lub interaktywnej implementacji wykonania importu
87
2.3.3.18
Moduł Obsługi Metadanych
Moduł obsługi metadanych udostępni funkcje związane z obsługą określonego dla
baz danych PSIP profilu metadanych oraz wybranej części profilu metadanych dla
danych pzgik stanowiących warstwy referencyjne systemu, które będą mogły
podlegać dalszemu udostępnieniu np. po ich przetworzeniu lub udostępnieniu
przez Służbę Geodezyjna i Kartograficzną (PODGiK) w postaci pierwotnej z zasobu
użytkowego.
Ładowanie i edycja metadanych będzie realizowane przy wykorzystaniu
standardowych licencji Desktop GIS oraz dedykowanego edytora metadanych
(Modułu Obsługi Metadanych) zgodnie z profilem metadanych.
Kluczowym zadaniem Wykonawcy przekładającym się na zakres wsparcia po
stronie Modułu Obsługi Metadanych będzie zapewnienie technologicznej,
automatycznej lub półautomatycznej linii aktualizacji i prowadzenia metadanych
systemu w bazie PSIP oraz w katalogu metadanych, który będzie podlegał
publikacji przez dedykowany portal metadanych PSIP.
Metadane zostaną założone przez Zamawiającego w zakresie zgodnym z
opracowanym Projektem Organizacyjno – Technicznym i / lub Projektem
Szczegółowym (zgodnie z normą ISO 19115), przy czym przyjmuje się, że w
początkowym okresie wdrożenia systemu metadane będą zawierały ograniczoną
liczbę cech np. nie więcej niż 20 oraz ograniczoną hierarchię - liczę poziomów,
zgodnie z przyjętym lub opracowanym profilem metadanych.
88

str.52-88 - BIP Urząd Miasta Ruda Śląska

Transkrypt

Podobne dokumenty

Linde Gaz Polska Sp. z o. o

Towarzystwo Przyjaciół Dzieci OM Ruda Śląska zaprasza dzieci w

Dzielnica Liczba rodzin objętych pomocą MOPS z uwagi na

PINB 1 Zawiadomienie o rozpoczęciu budowy

Dzielnica Liczba rodzin objętych pomocą MOPS z uwagi na

Załącznik mapowy nr2

Gdzie szukać pomocy? Przydatne adresy i telefony